On 09 Feb 2006 22:24:44 +0100, Dominik Vogt wrote: > > Hm, what about passing the module alias as an environment > variable? It's ugly, but we're already doing it with > FVWM_VISUALID and FVWM_COLORMAP. An FVWM_MODULE_ALIAS wouldn't > do further harm. > > However, this doesn't solve the syntax issue on the fvwm side. > What can we do about invocations like "FvwmButtons ColourTable" > (right from my config file)?
Well, one of the option is to add a new command, "ModuleAlias ColourTable FvwmButtons [usual args without alias]" and pass an alias to modules (preferably in non-user arguments, and not using environment variable). Another option is to implement a powerful option parser, like it is done in perllib, and have a C equivalent of declaration of all options in the module, like: "-c|--color" => "string", "-q|--quiet" => "none", the first non-option argument may be considered alias, like it is done now, but more accurately. This all may be done more or less transparently in the module library, because the module should supply the option spec, and then the alias name is sent back to the core. And the third option is not to change anything before 2.6.0. The heuristics works pretty well for the cases where aliases are used. I don't see any good reason to start to rework all modules now, risking to lose compatibility and insert new bugs, when we are in the freeze. > Class (6) modules are broken at the moment, i.e. it's not possible to > kill them with "KillModule Modulename" because their argument is > interpreted as an alias name. FvwmScript is not really broken. It is intended that the parameter works like an alias, although there is no separate config for such aliases. In any case, modules invoked as "Module FvwmScript MyConfig" may be killed using "KillModule FvwmScript MyConfig", even if MyConfig is a full file path, but usually it is something like "FvwmScript-WidgetDemo". > Perl have the alias name at the end of their option Well, the alias may as well come before the options or in the middle, in any perl-based modules that ask for EnableAlias and EnableOptions. And, as I said previously, the alias name does not conflict with the options, because the options may be automatically parsed accourdingly to the spec _anywhere_ on the command line and then are removed from the arguments. I say this not to suggest that the alias _should_ be allowed to come before or in the middle of the options, but that it is not a problem for a proper option parser, configured to treat all "-" words specially. > Any ideas for a clean interface that breaks only configs that are > really weird? The module interface should be redesigned. Together with the module syntaxes. We may do it cleanly in 2.7 or 2.9 versions. The compatibility may be slightly broken then. I strongly prefer, however, to release 2.6 first, before any changes in the module interface. Regards, Mikhael.
