On 22:24 Thu 09 Feb , Dominik Vogt 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.
>
> 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?
How about factoring the alias mechanism away from the module alias?
You could have a command:
AliasModule module-name alias [ alias ... ]
This way instead of writing
DestroyModuleConfig MonitorPanel: *
*MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock')
# ...
AddToFunc StartFunction
+ I Module FvwmButtons MonitorPanel
You'd write
AliasModule FvwmButtons MonitorPanel
DestroyModuleConfig MonitorPanel
*MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock')
# ...
AddToFunc StartFunction
+ I Module MonitorPanel
Which seems a little clearer.
That way we get to remove the alias from the module arguments, we can
deprecate the old usage, and third party modules don't have to use it.
For the module side of the operation, I'd pass it in the environment as
already suggested. We get a migration path to a cleaner syntax, and we
don't have to break anything.
Just a thought...
Nick
--
Don't let THEM immanentize the Eschaton!
