On 2/4/06, Mikhael Goikhman <[EMAIL PROTECTED]> wrote: > 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.
Yes, but as I found in the source code, modules distinguish them by looking for the "*FvwmMyname" string instead of just the asterisk. I don't know about perl, but c modules usually do that. In this case it would be as easy to look for just for "FvwmMyname", without needing either the asterisked string or calling CatString3. > 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. I guess you're right. Breaking compatibility now would be a waste of time, since it's going to be redesigned again for 2.6.. So we're back to the issue of using CatString3 or not..
