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. > > > 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]
signature.asc
Description: Digital signature
