Subject: FVWM: restarting modules

From: [email-masked] (Pete Siemsen)
Date: Wed, 6 Dec 1995 14:40:14 -0700 (MST)

I'm going through the ENUCFE (Endless New User Configuration File
Editing) phase with Fvwm 2.0.39.  To facilitate playing with modules,
I added functions like this to my .fvwmrc file:

AddToFunc RestartFvwmButtons
+ "I" KillModule FvwmButtons
+ "I" Module FvwmButtons

...which I call from a menu.  The intention was to be able to play
with config lines for a module and restart just the module, instead of
restarting Fvwm.

It doesn't work.  Even though the above function kills off the current
FvwmButtons process and replaces it with a new one, the new one uses
the old process's configuration.  Restarting fvwm itself *does* make
the new configuration lines "take".

The FvwmButtons man page says

   "During initialization, FvwmButtons will search for a
    configuration file....  The configuration file will be the one
    which fvwm used during its initialization."

Actually, no file is involved at all.  It might be better to say

   "During initialization, FvwmButtons asks fvwm for a configuration.
    Fvwm responds with the contents of the configuration file that was
    read by fvwm when fvwm was started."

This applies to the other modules too.

--
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: [email-masked] (Todd Fries)
Date: Thu, 7 Dec 1995 03:04:18 -0600 (CST)

> the new configuration lines "take".

Hrm, this sounds like rather strange behavior.  What I do is create

~/.fvwm (a subdir)
~/.fvwm/fvwmrc
~/.fvwm/fvwm-styles
~/.fvwm/fvwm-menus
~/.fvwm/fvwm-modules

... etc ...

in fvwm-menus I have the following menu:

AddToMenu ReReadIt "*fvwm.xpm*" Title
+ "&Key bindings" Read /home/todd/.fvwm/fvwm-keys
+ "&Mouse bindings" Read /home/todd/.fvwm/fvwm-mouse
+ "M&odules" Read /home/todd/.fvwm/fvwm-modules
+ "&Paths" Read /home/todd/.fvwm/fvwm-paths
+ "&Styles" Read /home/todd/.fvwm/fvwm-style

Which you could easily adapt to be:

AddToFunc RestartFvwmButtons
+ "I" KillModule FvwmButtons
+ "I" Read /wherever/your/rcfile/for/goodstuffis
+ "I" Module FvwmButtons

I separated the files out, as I found that reading
them all isn't really necessary, and things like
re-reading all of the menus w/out putting
'DestroyMenu' infront of each menuname created
interestingly doubled-menus and functions that
would do things twice...

-- 
Todd [email-masked]
http://www.cs.umr.edu/~tfries
--
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: Peter Funk <[email-masked]>
Date: Thu, 7 Dec 1995 08:12:44 +0100 (MEZ)

[...Killing and restarting modules only after .fvwmrc changes...]
ps> ...which I call from a menu.  The intention was to be able to play
ps> with config lines for a module and restart just the module, instead of
ps> restarting Fvwm.
ps> 
ps> It doesn't work.  Even though the above function kills off the current
ps> FvwmButtons process and replaces it with a new one, the new one uses
ps> the old process's configuration.  Restarting fvwm itself *does* make
ps> the new configuration lines "take".
ps> 
ps> The FvwmButtons man page says
ps> 
ps>    "During initialization, FvwmButtons will search for a
ps>     configuration file....  The configuration file will be the one
ps>     which fvwm used during its initialization."
ps> 
ps> Actually, no file is involved at all.  It might be better to say
ps> 
ps>    "During initialization, FvwmButtons asks fvwm for a configuration.
ps>     Fvwm responds with the contents of the configuration file that was
ps>     read by fvwm when fvwm was started."

If this is so, this behaviour must have been changed anywhere between version
1.24r to 2.0.x, where the 'GoodStuff'-Module (ancestor of FvwmButtons)
accesses the .fvwmrc file directly, so that a shutdown and restart
of 'GoodStuff' allone will reflect new button definitions in .fvwmrc.

I don't have 2.0.x yet, so it would be kind, if someone could verify
Petes observations.

Regards, Peter
-=-=-
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany
office: +49 421 2041925 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
--
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: [email-masked] (Robert Nation 885-9815)
Date: Fri, 8 Dec 95 09:05:23 EST

>I don't have 2.0.x yet, so it would be kind, if someone could verify

This is all correct, in fvwm-1.xx GoodStuff got the name of a file to read 
from fvwm, and then read it. In fvwm-2.xx FvwmButtons (and other modules)
ask fvwm for the configuration to use. This is because the new configuration
stuff allows you to:
1. Have multiple config files
2. Have configuration entered from the keyboard via FvwmTalk

Unfortunately, you can't enter module configuration from the keyboard 
(I actually am not sure why this is the case.)

Rob

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 8 Dec 1995 08:56:50 -0500

>>>>> "Peter" == Peter Funk <[email-masked]> writes:

Peter> If this is so, this behaviour must have been changed anywhere
Peter> between version 1.24r to 2.0.x, where the 'GoodStuff'-Module
Peter> (ancestor of FvwmButtons) accesses the .fvwmrc file directly,
Peter> so that a shutdown and restart of 'GoodStuff' allone will
Peter> reflect new button definitions in .fvwmrc.

Peter> I don't have 2.0.x yet, so it would be kind, if someone could
Peter> verify Petes observations.

That is the case.  Fvwm reads the config files, and the modules get
their config info from fvwm.  The reason being that this is the only
way for modules to deal w/ m4 and cpp preprocessing cleanly.

Granted, if you don't use these (which I don't) then the advantage of
just being able to restart a module and pick up it's new config is
lost.

On the TO-DO list I have plans to update the FvwmTalk module to be
able to accept module config info, which will help here (you can make
small changes on the fly quickly that way).

Or you can put the module config info in a separate file and use the
'Read <file>' command to load the changes without restarting fvwm.

Chuck

---

From: Aaron <[email-masked]>
Date: Fri, 8 Dec 1995 08:40:41 -0500 (EST)

> I don't have 2.0.x yet, so it would be kind, if someone could verify

i recently moved to 2.0.x and that is the only feature that i mourn.
i have had to restart fvwm to get the new Buttons config to stick.

but i dont change it much so i may live...

---

From: [email-masked]
Date: Mon, 11 Dec 1995 14:07:06 +0100 (MET)

> 'Read <file>' command to load the changes without restarting fvwm.

I have observed that this is not true.  If you "Read" a changed
config file, the previously set options aren't reset to the defaults.

In case of FvwmButtons this is a desaster, because after rereading the
config file you will get a button bar that is twice as big, because
every button from the new configuration is ADDED to the old configu-
ration.  Nothing but a restart of Fvwm helps then.

I just tested it to be sure, and guess what I am gonna do next?
Yep, I have to restart fvwm, to get my original button bar back. :-(

Ciao,
 Andy.
___________________________________________________________________________
  Andy Spiegl, Institute for Applied Mathematics
  University of Technology, Muenchen, Germany
  E-Mail: [email-masked]
  http://www.appl-math.tu-muenchen.de/~spiegl/

Above all else - sky.