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(). 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. 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)"), 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. 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. 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.. PS: there's a real bug on top of all this text ;) Renato Caldas
