On 04 Feb 2006 22:49:00 +, seventh guardian wrote:
I'm changing the official modules to use the new ParseModuleArgs
function, and I have a question regarding the module Alias argument.
Is it in fact a protocol standard or is it something some modules use?
This is not currently the standard. Each module deals with this on its
own, because they all have their own syntaxes. Moreover, fvwm itself has
a heuristic to try and extract an alias from the module invocation line
(to be used in SendModule and others). This does not work in 100% of
cases. For this to work in all cases, the alias should be explicitly
visible in the syntax (using some convention or a special ModuleAlias
command, the details are not important now), and the module protocol
should have explicit support for aliases.
I say that because some modules do use the argv[6] as an alias, but
others get the name by other means from the args. Like FvwmButtons,
which assumes the first unmarked argument as an alias. This is not
necessarilly argv[6].
So the question is, do we want a real protocol extension for this or
just a common thing. It makes no sense to use ParseModuleArgs unless
it does simplify the module. I can change FvwmButtons to use argv[6]
as an alias right now. But there would need to be an updating of the
manual, and maybe lots of people would need to change their configs..
No, users should not be required to change their configs any time soon.
Can we please suspend this discussion until 2.9 (pre 3.0) branch is open.
I have a lot to say on this topic. But this is really not the time to
redesign the module protocol. I may also suggest to suspend your
ParseModuleArgs work because of this, as you say yourself.
There are old fvwm-workers threads discussing the issue (including
module aliases), but I don't have urls to these discussions right now.
If you want some reading on automatical parsing of module args and the
alias, run fvwm-perllib man FVWM::Module and read about new
constructor, including its parameters EnableAlias and EnableOptions.
Regards,
Mikhael.
