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.
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!
* OldDebug
Can be invoked as one of
OldDebug
OldDebug alias
OldDebug -v
OldDebug -v alias
OldDebug alias -v
YUCK!
* Event
Can be invoked as one of
Event
Event -audio
Event alias
* 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 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.
> > > 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
