On 8/16/07, Dominik Vogt <[EMAIL PROTECTED]> wrote: > On Thu, Aug 16, 2007 at 07:06:13PM +0100, seventh guardian wrote: > > On 8/16/07, Dominik Vogt <[EMAIL PROTECTED]> wrote: > > > On Thu, Aug 16, 2007 at 11:14:58AM +0200, Dominik Vogt wrote: > > > By the way, I really don't understand why anybody considers > > > ListenOnlyModules a hack. Isn't it perfectly acceptable to write > > > a module that does not want to take any input? Why is it bad if > > > fvwm deos not send messages to certain modules? > > > > A couple of reasons for it to be within my definition of "hack": > > > > 1. Modules are supposed to work following a set of rules, and > > ListenOnly modules break that set of rules. It may also prevent some > > future beneficial changes to the module communication because > > ListenOnly modules wouldn't work anymore. > > I really can't think of an interface change that breaks external > ListenOnlyModules but keeps external input/output moudles intact.
It's not a matter of not breaking something, it's a matter of not being able to fix ListenOnly modules. For instance changing from pipes to other mechanism (like xorg's ICE, as proposed some time ago). > > 2. It is a particular scratch for a particular itch: it is only useful > > for zsh. Perl modules work with the perl fvwm lib, C modules should > > work with the (hypothetical) C fvwm lib. Other shell's can't work with > > this mechanism, so some other mechanism must be devised for them. > > That is simply not true. There's nothing zsh-specific about the > module mechanism. I used zsh because it has a lot of features > that helped implementing the module (i.e. built in datetime and > select functions). The module communication works with any shell > that has a decent printf command or any other scripting or > programming language that is capable of writing binary output to a > given file descriptor. > It's really not true, my fault. I've just managed to send something to fvwm from a bash script (it didn't work for some reason, but fvwm did complain about receiving bad data). > > So what I propose is kind of a "universal scratch" for that same itch, > > applied to all shells. It isn't working as supposed yet, but once it > > is it makes no sense to support the two "scratches". > > Well, if there's a different way to have a light weight, output > only module without starting another process that's fine. If it > does not involve writing the code to receive messages, even > better. However, that functionality is already written in a clean > and simple way. The only difference between a normal and a > ListenOnlyModule is that fvwm does not expect the module to take > any input. This could have been done as options to the module > command too, but that's only a matter of syntax. 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. > 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. 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. 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. Cheers, Renato
