On 2/11/06, Mikhael Goikhman [EMAIL PROTECTED] wrote:
On 10 Feb 2006 16:48:49 +, Mikhael Goikhman wrote:
On 10 Feb 2006 08:25:41 +, Nick Fortune wrote:
You'd write
AliasModule FvwmButtons MonitorPanel
DestroyModuleConfig MonitorPanel
*MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock')
# ...
AddToFunc StartFunction
+ I Module MonitorPanel
This is an option to consider, before redesigning the module interface.
However, this syntax will require 2 lines for launching every module,
AliasModule and Module, instead of just Module. And we also need
UnaliasModule. I.e. now the user should predeclare all module instances
he wants to use. I should rething this idea first before agreeing or
disagreeing with it.
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
*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?