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. > 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. > 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. 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. > > Of course, writing such a module as an architecture dependent zsh > > script *is* a hack, but that's the user's problem (i.e. mine), not > > fvwm's. > > It is if the users complain that they want the same facility for bash > :) I believe we can't have yet a third mechanism :P By the way, there's another problem with the supposed solution using FvwmCommandS: You need a dedicated pipe for every module, because the pipe mechanism isn't safe. If multiple modules write to the pipe at the same time, the commands may mix (the atomic write size guaranteed by POSIX is either 256 or 512 bytes). So if the user calls FvwmCommand while the module sends commands to fvwm, the result may be undefined. FvwmConsole actually has this problem when pasting many large commands into the FvwmConsole window. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
