On 2/10/06, Dominik Vogt <[EMAIL PROTECTED]> wrote: > 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.
Now I see your point. I agree, module aliases shouldn't disturb the command line. The envvar is a possible solution. Another one is making the alias mecanism _entirely_ a part of the fvwm core. Since the communication channel is "point-to-point", a module wouldn't even need to know its own name, at least now. Aliases were useful when the config file parsing was done by the module itself. Now fvwm feeds the module with only global configs or its own configs (the filter being supplied by the module). So if you define an alias to a module inside the core, fvwm (core) would know it and would translate the module's requests to the aliased lines. >>>>> For instance (using your example syntax): 1 - We call "Module FvwmPager --alias foobar" 2 - FvwmPager will name itself FvwmPager and would request the *FvwmPager lines. 3 - fvwm knows that this instance of FvwmPager is aliased as "foobar" and would search for the *foobar lines. 4 - fvwm then sends the *foobar lines to the module, but translated to *FvwmPager. >>>>> Then we have two options: - Modules don't pass a matching string to fvwm and fvwm is entirely responsible of the module's aliases. - Modules continue to pass the matching string and fvwm translates it if an alias is defined in the core. Option 1 would be the cleanest, making the modules entirely alias-independent (probably the best solution for fvwm-3.0) Option 2 would allow for the current alias mecanisms to continue to work, but would be less efficient than option 1. > > 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 said that because changing the alias interface would be impossible without braking the existing configs. I'm getting the "don't change that, it would brake.." all the time. I suggested a branch because it would allow us to play with the code without the the fear of breakage. It doesn't save work, but it would bring some peace to this, before everybody agrees on the changes. > > > > 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. > I see what you mean. My suggestion above would be for using only the 1st and the 3rd mecanisms, with the advantage that it would be completely transparent to the modules. Eventually 3rd parties would use the 1st, as it would definitelly save them work. > > > > > > 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. > Cheers Renato Caldas
