On 8/18/07, Dominik Vogt <[EMAIL PROTECTED]> wrote: > 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. >
I was thinking about modules as .so libraries.. But there's ICE, dbus, etc.. > > > 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. Yes, but that's the user's problem :) The difference is that the user can set them manually, whereas in case of ListenOnly modules he can't. I'm personally using the acpid daemon that passes events to user defined shell scripts. So it's fairly easy to configure the daemon to use the correct fifo. > 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. Well, that does sound like a job for a module. Maybe we are missing something like a FvwmClock (or FvwmTimer or FvwmTicks or something like that).. Cheers, Renato
