Subject: FVWM: Configuration file feature

From: Uwe Pross <[email-masked]>
Date: Thu, 21 Aug 2003 16:45:30 +0200

Hi there,

I just wondered if fvwm would be able to write its actual
configuration to a configuration file which can be read at
the next start. All function, menu and module definition
should be included.

Would it be possible to implement such a feature? Where
would be the constraints?

Regards, Uwe
-- 
  ,_,   For personal reply/mail put "fvwm"
 (O,O)  in the subject.
 (   )  Otherwise I won't receive our mail.
--"-"----------------------------------------
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Uwe Pross <[email-masked]>
Date: Thu, 21 Aug 2003 16:51:54 +0200

Hi there,

> would be the constraints?

s/constraints/limits/

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 21 Aug 2003 17:02:47 +0200

> would be the constraints?

Currently, it's nigh impossible.

Bye

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Thu, 21 Aug 2003 17:13:21 +0200

Hi there,

On 21 Aug 2003 at 15:53:53 +0100, Thomas Adam wrote:

> How do you mean? Most of what FVWM reads on invocation is
> all it needs to operate, and anything that changes isn't
> really fvwm specific, but more application specific.

I meant its actual settings like MenuStyle, environment
variables, function and menu definitions, key bindings,
module settings ... All this belongs to the actual
configuration.

> You'll have to add it in manually. How is fvwm to know
> what has/has not changed?

Well, I don't mind what has changed I just want the actual
settings.

Regards, Uwe

---

From: Thomas Adam <[email-masked]>
Date: Thu, 21 Aug 2003 15:53:53 +0100 (BST)

> would be the constraints?

Uwe,

How do you mean? Most of what FVWM reads on invocation is all it needs to
operate, and anything that changes isn't really fvwm specific, but more
application specific.

You'll have to add it in manually. How is fvwm to know what has/has not
changed?

Have you looked at the man pages for FvwmSave and FvwmSaveDesk?

Or am I totally off track?

-- Thomas Adam

=====
Thomas Adam

"The Linux Weekend Mechanic" -- www.linuxgazette.com

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

---

From: Uwe Pross <[email-masked]>
Date: Thu, 21 Aug 2003 18:10:45 +0200

Hi there,

> Currently, it's nigh impossible.

Mmh, that's what I had feared. Function and menu
definitions are converted to internal pointer structures
from which the settings can not be derived?

Well, sometimes I think about a configuration tool for
fvwm. The best would be to make it running with fvwm, e.g.
tcl-tk or similar which issues fvwm-commands and pipes them
to FvwmCommand. In that case fvwm should be able to save
its own configuration.

Regards, Uwe

---

From: Dan Espen <[email-masked]>
Date: Thu, 21 Aug 2003 12:49:33 -0400

> to FvwmCommand. In that case fvwm should be able to save

I think it would be possible to write functions to print
out some of the internal structures in close to their original
form, but I don't think its necessary or even desirable.

If you have a config tool and you feed its output into fvwm,
why not edit that output file and feed it to fvwm again?

I have to tool like that for my menu of rxvt's to remote systems
and it works fine.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Uwe Pross <[email-masked]>
Date: Thu, 21 Aug 2003 21:16:20 +0200

Hi there,

On 21 Aug 2003 at 12:49:33 -0400, Dan Espen wrote:

> out some of the internal structures in close to their
> original form, but I don't think its necessary or even
> desirable.
> 
> If you have a config tool and you feed its output into
> fvwm, why not edit that output file and feed it to fvwm
> again?

I think it might lead to consistence problems if a
config tool does not get feedback from fvwm. Having fvwm
writing its config ensures a config file which represents
the actual state. Further the config tool could be
initialized by fvwm and does not need to read the config
file which ensures that both fvwm and the config tool are in
the same state.

Regards, Uwe