On 11 Feb 2006 02:08:55 +0000, seventh guardian wrote:
>
> On 2/11/06, Mikhael Goikhman <[EMAIL PROTECTED]> wrote:
> >
> > Another serious problem with this suggestion is that now we start to
> > manipulate with strings like "ColourTable" or "MonitorPanel" and have no
> > any idea whether they are actually FvwmButtons, FvwmForm, FvwmScript,
> > FvwmGtk or maybe even FvwmEvent. And these are very different modules
> > with different configuration syntaxes and command line options.
> >
> > Several years ago I had and still have the following idea in mind, that
> > seems to solve all problems. However it applies a restriction on the
> > module alias name. And this is its only drawback.
> >
> > The alias name (or more correctly the module id) is anything that is
> > <modulename>-<subname>. I.e. FvwmScript-ClockMonitor or FvwmForm-Talk.
> > Now, a module should receive <subname> and not <alias> as we know it.
> >
> > Then this module id is used everywhere straightforwardly:
> >
> > Module FvwmButtons-Monitor -g 240x360
> > KillModule FvwmButtons-Monitor
> > SendToModule FvwmButtons-Monitor PressButton 2
> > DestroyModuleConfig FvwmButtons-Monitor
> > *FvwmButtons-Monitor: Colorset 1
> >
> > I think, this syntax is pretty clean and self-descriptive. If a module
> > does not accept multiple instances, then it may still be accessible as
> > FvwmBanner (with no <subname> needed).
> >
> > The FvwmForm and FvwmScript configurations shipped with fvwm already
> > follow this naming scheme. As well as all modules in fvwm-themes.
> >
> > I currently don't see a better solution for module ids.
>
> I like the idea, and it's definitely as clean as it can be. Also,
> aliases are exclusive to the configuration, and not visible in daily
> use. So there's really no drawback.
>
> I have one question though: how is this meant to be aplied? Is it pre-
> or post-2.6?
If I wanted to have this in 2.6, I would add this into todo-2.6 long ago.
We did a huge work for 2.6, it is a time to freeze all and release it.
Theoretically, it is possible to implement the support for this syntax
now, without changing any module code (that may be done after 2.6). But
first, an agreement that this is the ultimate module syntax is needed.
The changes needed to support this syntax in addition to the current one
(remember, we should not break any user configuration) are very small:
* DestroyModuleConfig, to imply ": *" when the argument contains dash
* KillModule, to translate argument with dash into 2 arguments
* Module, to translate argument with dash into 2 arguments
(and use this argument as alias, no heuristics is needed)
So, as a transition, if the module is invoked as <modulename>-<subname>,
this module id is added before the user args, i.e. in argv[6]. This
will not break any modules that already use this naming convension in
fvwm and fvwm-themes, so we may replace "FvwmForm FvwmForm-Talk" with
just "FvwmForm-Talk" in our configurations, as in the final syntax.
After 2.6, the quoted syntax may become the only syntax for modules if
there is an agreement. And all modules should be rewritten to receive the
subname (or the full alias) in one or another way, probably in argv[6],
since we change the module protocol and may make the user args be passed
starting from argv[7]. Or maybe we decide then that the module does not
need to know its names, because it requests all needed config from fvwm
accourding to type (module name specific, id specific, or both) and not
accourding to name. The future implementation details are not important.
I don't care whether the minor transitional changes to these 3 commands
are applied before 2.6, or we only implement the final solution in 2.9.
But I care that we don't start to rewrite any module now and add bugs
and breakages.
Regards,
Mikhael.
