On 8/8/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam 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
> 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.

But there is a soulution.  Extend the config win packet with a
flag that indicated whether a window can be moved by the user,
i.e. the return code of the function that determines whether the
window can be moved or not.


Elegant enough :) Viktor will you do it?

Cheers
 Renato

> > > 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.  :)

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFE2Nh3meSprTOr4tgRAhSYAKCtVnMulvIbWYgQDdaODNvDkH1lkACfRjuT
EUZJPAB99lkRifhELOa88TI=
=lp+7
-----END PGP SIGNATURE-----




Reply via email to