On 8/8/06, Thomas Adam <[EMAIL PROTECTED]> wrote:
On Tue, 8 Aug 2006 16:18:41 +0100
"seventh guardian" <[EMAIL PROTECTED]> wrote:
> On 8/8/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
> > > > > As a way to provide backward compatibility and minimizing the
> > > > > effects of the above VISIBLE changes there could be provided a
> > > > > command that the modules could use to request an alias. This way
> > > > > the module would parse the command line alias options and request
> > > > > the attribution of an alias. So old configs would still work
> > > > > properly!! :)
> > > >
> > > > Strange thing now looking through module_interface.c: there is already
> > > > a string array called pipeAlias!! Is it possible that the
> > > > infrastructure is already there??
> > >
> > > YES! Strangely enough, the infrastructure is there!! You can actually
> > > send commands to specific aliased modules! Just use the module alias
> > > instead of the name, and voila!
> > >
> > > Except pipeAlias is never properly written. It seems that someone
> > > started the job but didn't get to finish it.
> >
> > The code is as good as it could be at the time Mikhael wrote it.
> > It's not much more than a hack that tries to guess whether the
> > first argument of a module was intended to be an alias (i.e. not an
> > option etc.). It fails in a number of cases, but we can not do much
> > better without rewriting the interface of some modules.
>
> So what could be the solution to the initial problem without any kind
> of rewrite?
There isn't, I'm afraid. I can perfectly understand and see the logic behind
why the flags should be sent in the packet information -- however in order
Should they? I don't agree. The modules shouldn't have to deal with
fvwm's internals. The module interface should be as clean as
possible.. As Dominik said, it is a hack.
for there to be a solution to what you're proposing, it is going to mean a
rewrite most likely. This was discussed here on this list a few months ago.
If you like I will dig through the on-line archives for you.
> > Well, shouldn't we try to stabilise 2.5.x now, release it an then think
> > about big changes in the module interface?
>
> Yes.. But we are constantly facing problems that would either be
> solved by some kind of rewrite or by hacks..
>
> 2.5 is mostly stable. It's definitely more stable than some other
> release programs....
There's still one or two things that need fixing before I would deem 2.5.X as
a release candidate. There's no rush. :) I'd much rather see it done
proper than released; pampering to the possible cries of the users that so
desperately want it. :)
Anything that wouldn't require a rewrite/hack?
Cheers
Renato
-- Thomas Adam
--
ThisWindow (thomas_adam) Destroy
