On Wed, Feb 01, 2006 at 02:58:27PM +0000, seventh guardian wrote: > Hi. > > First of all, there's a minor bug in libs/Module.h: the funcion > SendFinishedStartupNotification() is declared twice (on lines 147 and > 166). > > With that asside, I'm writing a module for Fvwm to support the xorg's > Xevie extension. I really don't like to reinvent the wheel, so I'm > creating it inside the building tree, using Module.h and other helping > libs. (that's the reason why I found that bug). > > I also found that there's a nice parsing function which is rarely used > by any of the other modules, ParseModuleArgs().
Actually it is not used at all. > It returns a struct > with the module args, including the two communication pipes. The > problem here is that the structure itself is "strange" to use, because > the other all the other functions genericaly require a pipe array, > fd*, with the first element as transmit pipe and the other as a > receive. So there are two alternatives here. Um, I can't think of any function that needs a pipe array in any module or the module library. Can you give examples? > Either to ALLWAYS pass > them the to_fvwm pipe, which works because of their order in the > struct (but makes the code a little cryptic, like "Receive(to_fvwm)"), There is no guarantee that this works. > or to copy them to an array fd[2], which uses twice as much memory > (not a real problem most of the times, but definitelly a bug). > With that said, my suggestion is this: to use a struct to store the > interface data (file descriptors, name, etc) and to make the functions > use that struct instead of the particular elements. But ParseModuleArgs already allows this. It parses the module arguments and passes back a structure that contains the number and an array of options not yet parsed. It's easy to write more parsing functions with this information, but it's actually not a very good idea because modules should be configured by the config file, not the command line (with some exceptions). > That way more > helper functions would come up, such as a function that requests the > config info and calls a user defined parsing function to handle the > lines as they come up. Or a function to wait on the pipe for packets > and also passing them to a user defined parsing function. Having a > struct instead of scatered global vars makes that task easyer, as they > are all passed at once inside the struct. > > Also, that way if someday (fvwm 3 maybe?) the module interface > changes, the modules themseves woudn't need to change that much. The module packet interface changes once in a while, but I don't see the command line changing anytime soon. > It > woudn't be that difficult to change the current modules to use the new > functions. Besides, all already compiled modules would work without > any change, and unofficial ones would compile perfectly as long as > they don't use the new Module.h. Also there could be an "adaptation > time" where both libs were supplied.. > > Those were my thoughts. Please comment.. Streamlining the module interface code is definitely worthwhile. It's just that there are so many modules and so much work to do. The first step would be to just *use* ParseModuleArguments everywhere (without breaking all the existing code). Any further changes can be made after that. I'm open to any patches. > PS: there's a real bug on top of all this text ;) Hint: Write two mails for two different topics to minimize the risk the bad issue is forgotten. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
