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: > > > > On 2/9/06, Dominik Vogt <[EMAIL PROTECTED]> wrote: > > > > > On Wed, Feb 08, 2006 at 02:05:14PM +0000, seventh guardian wrote: > > > > > I've committed the patch to CVS (and removed the FARGS macro from > > > > > FvwmConsole). For further patches, please always add a list of > > > > > modified functions to the ChangeLog after the name of the .c file. > > > > > This simplifies maintenance enormously. > > > > > > > > > > > > > Here goes a second patch. > > > > > > > > I've added the list of modified functions after the file name, except > > > > for the main function. I followed the style of some of your entries in > > > > the changelogs, hope I've done it ok. > > > > > > Actually, its not my personal style but what xemacs (and emacs?) > > > generate when you move the cursor into a function and the press > > > ctrl-x 4 a. (Unfortunately more recent versions of xemacs changed > > > the style of the function list which makes it more difficult to > > > grep through it. > > > > > > > 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" ? Using an evironment var for the alias would break third party modules, unless we also provide it via command args. 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? > * 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.. > * Event > > Can be invoked as one of > > Event > Event -audio > Event alias Is the -audio option used at all? 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? > * 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. 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.. > > 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. > > > > 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
