On Fri, Aug 17, 2007 at 09:22:44PM +0100, seventh guardian wrote: > I don't like ListenOnly modules because it's dependent on how modules > talk with fvwm at present. I'd really prefer a mechanism that can't > cripple us in the future. And IMHO the best way to do it is to have a > module doing the interface. It may not be as light as directly talking > to fvwm, but it's not much heavier. And it will eventually be replaced > by the todo-3.0 proposed socket mechanism.
Well, the pipe-mechanism has one big advantage: Modules get a SIGPIPE when whem dies and are killed automatically. That's not trivial to do with sockets. > > Note that the module interface never prevented anybody from > > writing a module in any scripting language. It's easy to do and I > > actually did it years ago when I learend about the module > > interface. It's just easier to do with ListenOnlöyModules. > > It's only easier for that particular itch. ListenOnly modules require > the script to receive the file descriptors from fvwm. Yes, sure. But every module now and in the future has to be informed about the communication channel to fvwm by fvwm itself. Otherwise the modules would have to have an (error prone) guessing algorithm to determine the channel. I an FvwmCommand-like mechanism is only good for interactive user input, not for general scripting. > Imagine for > instance that I write a script for the acpi daemon to send commands to > fvwm on acpi events. ListenOnly modules simply won't do because it > requires fvwm to start the daemon to give it the file descriptors. But then you have to tell the demon how to contact fvwm. It's not possible to write a demon that can always detect which channels to use to talk with fvwm unless there is some central configuration repository. It can not even guess the display fvwm is running on. Personally I often have fvwm running on up to three "displays": :0.0 - My normal display :1.0 - Display for debugging a second fvwm :3.0 - Display for xnest running remote applications All three fvwms spawn a separate shell script module and I never have to worry about running too many or too few modules. > On the other hand, a fifo will work for all the script situations I > can imagine and with almost no extra weight. > There's a thin line between something that "cooperates" with fvwm and > something that sends it commands. I'd prefer not to mix both because > the purposes are different. In this particular case, my script is actually an extension of FvwmButton's funtionality: it updates some button titles periodically. Strictly speaking it should even be spawned by a particular instance of FvwmButtons. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
