On Tue, Aug 08, 2006 at 04:18:41PM +0100, seventh guardian 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? > > >> The very first issue is > >> that there is no defined way of choosing the alias. From what I see in > >> the code, it was suposed to have the very first user argument as an > >> alias (standard). Since some modules don't use (respect?) this, I > >> guess the effort was undermined by the back-compat issues.. > >> > >> But this can be partially tackled if we add a command for the modules > >> to request their alias in the fvwm internal data. Is it worth > >> continuing the job? Is it safer to start an experimental side branch > >> on this? > > > >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.
No, it isn't. It has some areas that are hardly tested at all, and some features that can not be released in the current state (see the corresponding to-do file for details). After that we may change everything to our heart's desire (unless we want a 2.8 release before 3.0). > It's definitely more stable than some other > release programs.... Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
