On 04 Feb 2006 16:56:47 +0000, seventh guardian wrote: > > > > existing structure only stores the name, and not the asterisk. Of > > > course we could use the existing char* MyName, but that would defeat > > > the whole purpose of using the ModuleArgs struct. > > > > > > I wonder if we need the asterisk in the first place. Wouldn't it be > > > easyer "new-code-wise" to use only the name for pattern matching? It > > > could be stripped off by fvwm or simply not used in the config files. > > > > > > (since this is only experimental code we are allowed to forget > > > backward compatibility issues) > > > > Eventually you have to deal with compatibility. > > Yes, but unless there's a reason for the use of the asterisk, it is > cleaner not to have it. Configuration keywords are changing all the > time, it won't be that difficult to strip the * from the config files.
Here you speak about the fvwm configuration. You can't omit the asterisk without inventing a new syntax that does not conflict with the syntax of fvwm commands and functions. I see no problem in the asterisks syntax, it seems to be more optimal than other possible syntaxes for module configs. > By the way, anyone knows why is the asterisk there for? Here I suppose you ask about the asterisk sent in M_CONFIG_INFO packets. I suggest you to learn the fvwm-to-module protocol more in depth. You may run FvwmGtkDebug or FvwmDebug to see what is sent by fvwm to a module on its Send_ConfigInfo request. You may discover that the asterisk is needed to distinguish from other M_CONFIG_INFO packets that carry a non module configuration. BTW, perllib solves this by having two tracker types, GlobalConfig and ModuleConfig, so a module in perl has a nice API. Redesigning the module protocol may be fine in the future, but this would mean much larger changes than you think. A good suggestion may be, for example, to add a new module packet MX_MODULE_CONFIG carrying the configuration line without the leading "*FvwmModule: ", and not just omitting an asterisk, as you suggest. Please do not break any compatibility right now. Let's not forget, we are in the freeze before 2.6.0. Regards, Mikhael.
