On Thu, Feb 09, 2006 at 11:25:42PM +0000, seventh guardian wrote: > On 2/9/06, Dominik Vogt <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 09, 2006 at 04:08:00PM +0000, seventh guardian wrote: > > > On 2/9/06, Dominik Vogt <[EMAIL PROTECTED]> wrote: > > > > On Thu, Feb 09, 2006 at 03:32:44PM +0000, seventh guardian wrote: [snip] > > > > > As you said once, the command line syntax isn't going to change that > > > > > much, even for 3.0. But even so, some coding styles make it difficult > > > > > to use properly the ParseModuleArgs (or functions alike) regarding the > > > > > module aliases. I wonder if there could be fixed a standard for > > > > > aliases. I mean a true standard that modules using aliases should > > > > > follow. The argv[6] rule would be ok, but it would break some config > > > > > files. Obviosly some kind of wrapper could be used to avoid those > > > > > breakings, like in FvwmRearrange. I wonder what you think about this. > > > > > > > > The one problem with that approach is that such a change would > > > > break all third-party modules. > > > > > > > > > > Hum, you're right. What about making the change only for official > > > modules, those using Module.h? > > > > 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. > > > > Do you mean something like "Module ALIAS=mypager FvwmPager" ?
No, I don't know how to handle the command line yet, but maybe FvwmPager --alias foobar ... which would be recognized and handled by the fvwm core, or perhaps a separate ModuleAlias command, but that might be confusing, as many people don't use the Module command at all. But that was not my point. I was talking about a way to pass the alias to the module without putting it on the command line args of the module. The envvar allows to provide the module with an alias without disturbing its command line. > Using an evironment var for the alias would break third party modules, > unless we also provide it via command args. No, it wouldn't because aliases are not an official part of the module interface, as far as I know. The module classes (1) to (6) could easily be adapted to that logic without touching the way they interpret their arguments. > Even discarding that, > wouldn't it need major changes in the way fvwm interprets the config > file? > > > 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)? > > > > Okay, let's see how big the mess is: > > > > 1) Modules that currently support the syntax "modulename [alias]" > > without further command line args: > > > > Animate, CommandS, Form, Gtk, IconBox, TaskBar > > > > 2) Modules which do not accept any command line options, icluding > > aliases: > > > > Backer, DragWell, Ident, Proxy, Save, SaveDesk, Scroll, > > Theme, Wharf > > > > 3) Modules which do not have any config lines: > > > > Auto, Save, SaveDesk > > > > 4) Modules which only accept command line options beginning with > > '-': > > > > Console, Debug, GtkDebug, Rearrange, Tabs > > > > 5) Modules which accept a list of '-' options followed by a single > > argument that does not begin with '-' (and is not an alias): > > > > Cpp, M4 > > > > 6) Modules that accept a single non-alias argument: > > > > Banner, Script > > > > 7) Weird cases: > > > > * Buttons > > > > Possible arguments are ['-'options] [alias] [cfgfile] > > > > Iterates over its arguments. For each argument it checks if > > it's an option with '-' first. If not (or the same option > > was encountered earlier), it's taken as the alias. If the > > alias is already define, it's taken as the cfgfile. If the > > cfgfile is already defined, it's ignored. > > > > YUCK! > > Mikhael is going to clean this one up. Maybe it could be redesigned, who > knows? The question is: Does anyone rely on that strange parsing rules? > > * OldDebug > > > > Can be invoked as one of > > > > OldDebug > > OldDebug alias > > OldDebug -v > > OldDebug -v alias > > OldDebug alias -v > > > > YUCK! > > OldDebug doesn't even compile anymore, and no one complained. I > believe it may be removed from the building tree.. Fine. > > * Event > > > > Can be invoked as one of > > > > Event > > Event -audio > > Event alias > > Is the -audio option used at all? Yes! FvwmEvent is installed as "FvwmEvent" and symlinked as "FvwmAudio". > I believe not, but I may be wrong.. > Even so, it only supports only either -audio or an alias, so I believe > it's broken. > > As a side note, the module does two distinct things, so shouldn't it > be splitt up into FvwmEvent and FvwmAudio? Is the Audio part used > anyway? The -audio option and invoking it as "FvwmAudio" is the result or merging the old FvwmAudio module back into FvwmEvent. It was once split from FvwmEvent (I think) and shared most of the code. Probably FvwmAudio did not support module aliases, so there is no mode to have both. > > * IconMan > > > > Can be invoked as > > > > IconMan > > IconMan alias > > IconMan transient > > IconMan -transient > > IconMan transient alias > > IconMan -transient alias > > > > * Pager > > > > Same as IconMan, but may be followed by one or two desk > > numbers or asterisks. > > > > * Perl > > > > Can be invoked as > > > > Perl ['-'options] [alias] > > > > * WindowMenu > > > > Takes options without a '-' prefix but no alias. > > > > * WindowList > > > > Same as IconMan. > > > > Classes (2) and (3) are no problem at all while (1), (4) and (5) > > are relatively easy to cope with. 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. > > > > WindowMenu, Tabs and Perl are new in 2.5.x, so we can change their > > interface without worrying about incompatibilities. > > > > Event and Perl have the alias name at the end of their option > > > > Any ideas for a clean interface that breaks only configs that are > > really weird? > > I don't think that is possible at all. My only idea regarding that > would be to unify things and use a wrapper for compatibility's sake. A compatibility wrapper for WindowList, Pager, IconMan and Event isn't too difficult. > Or supplying a script/programm to adapt automatically the config files > to an eventual new design. > > Now after giving it a better thought, wouldn't it be better to branch > fvwm at this point? We could eventually merge them right before 2.6.. Branch to do what? Frankly, I don't believe in the benefit of branches. In the end they usually cause more work that they save you. > > > I don't know if third party modules use > > > Module.h, but they will break anyway if that file changes.. > > > > Module.h is not part of the external interface, so we don't need > > to care about modules using it. > > > > Ok, that makes things easier. The eventual "standard" for the alias > could be just an "agreement", in that third parties are encouraged to > use it but not forced to. Of course modules in the official tree > should use it. Yes. Note that it's relatively easy to keep all three alias mechanisms, one implemented purely by the fvwm core, the current heuristics and the private implementations of some of the modules, but it would be so much cleaner to drop all but the first one. > > > > > Without a proper standard, some modules using ParseModuleArgs won't be > > > > > as clean as they should be. I'm skipping them for now, wainting for a > > > > > definite solution. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
