Hello Dominik - Regarding the clean-up patch I posted: Given the way you illustrate going from one window manager to another (with the xinitrc), it's clear that you'd want it to be optional, or don't include it at all. Indeed you can do almost the same thing from the xinitrc, but it is considerably more complex that way ...
|That patch may cause a lot of trouble if X does not exit when fvwm |does. For example, I often have these two lines near the end of my |.xinitrc: | | # start fvwm without any config file | fvwm2 -f /dev/null | # fall back to normal config file after exiting | fvwm2 Well, the behavior would be all processes launched by the first fvwm2 would be cleaned up before the second fvwm2 starts. Maybe not what you wanted, but note that things do work fine if fvwm2 is used to restart itself or another window manager instead. |Also, this fails miserably if you restart fvwm in the mean time |since the new fvwm process does not become the parent of the Actually it does work. When you restart, fvwm2 exec()'s itself or a new window manager. Either way, its PID stays the same and all windows launched since the beginning of the session remain child processes (which are reached by the kill(0, ...)). The whole concept isn't even that non-standard. If you launch a bunch of stuff from a terminal and then close that window, all the processes in the group see a SIGHUP too. (So it's not a wrong or bad way to shut down programs. They all expect it, or they will detach from the terminal so they won't see this signal.) The feature just brings that simple but effective concept for terminal sessions up to a window session. |windows. Neither does it help if windows are started from outside |of fvwm, e.g. from .xinitrc. Why don't you simply do this in The way our xinitrc's are set up, it does. The last thing xinitrc does is "exec fvwm2". fvwm2 nicely inherits any clients already started by the xinitrc. |.xinitrc? For example, since netscape often hangs, I have | | killall -15 netscape That would kill a netscape I have running on another X-Terminal in another room. Not good. And some of our machines don't have killall. But even with grep/awk junk in our scripts, the list was getting rather long, and I was tired of seeing half logged out X-Terminals in our computer room. kill(0, SIGHUP) was a much easier fix. Hey, how about a simple "exec fvwm2 -cleanup ..." usage? That would make it obvious within the script where fvwm2 is invoked, and where it matters, what behavior required. Default behavior unchanged. Seem like a good idea? Be seeing you, - Sidik P.S.: We also use fvwm on some very tight, embedded systems where having the xinitrc be able to turn into the window manager with an exec is both clean and wise to conserve memory/resources. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
