On 2/10/06, Mikhael Goikhman <[EMAIL PROTECTED]> wrote: > On 10 Feb 2006 08:35:04 +0100, Dominik Vogt wrote: > > > > On Fri, Feb 10, 2006 at 01:19:26AM +0000, seventh guardian wrote: > > > Then we have two options: > > > > > > - Modules don't pass a matching string to fvwm and fvwm is entirely > > > responsible of the module's aliases. > > > > > > - Modules continue to pass the matching string and fvwm translates it > > > if an alias is defined in the core. > > > > Hm, would that break the old way FvwmIconMan requested its config > > liens? I mean > > > > *FvwmIconMan*1*foobar ... > > > > Instead of the new > > > > *FvwmIconMan: 1 foobar ... > > > > Or is that completely transparent to the modules? > > > > Mikhael? > > The second line is unfortunately (for backward compatibility with all > other modules parsing their config) is sent as: > > *FvwmIconMan1 foobar ... > > FvwmIconMan simply supports 2 formats, old with "*", and without "*". > > Similarly, FvwmButtons config that looks like: > > *MyButtons: Frame 5 > *MyButtons: (Container) > > is sent (again, for backward compatibility) as: > > *MyButtonsFrame 5 > *MyButtons(Container) > > At least "DestroyModuleConfig MyButtons: Width" and "DestroyModuleConfig > MyButtons: *" do the right thing, i.e. do not affect lines of another > alias "*MyButtonsFrame: Title my-frame". > > Of corse, the correct thing is to introduce MX_MODULE_CONFIG packet and > new rules (a module may request from the core a config related to the > module name, say FvwmScript, or related to its alias, say FvwmButtons, > or both, say FvwmForm) and to send the config lines without any prefix. > > This requires rewrite of all modules and the core. Not before 2.6. >
I'm forced to agree, but when will 2.6 come out? I happende to step on this when I was trying the wiki: DV> What about the future? Well, the work for the next stable series DV> (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV> again near the end of the year so that 2.6 is ready before fvwm's DV> tenth birthday on 1st of June, 2003. I have vague plans for a DV> big event on that day to remind people that fvwm is still there DV> and that it can easily compete with any other window manager. DV> After that there are plans for a version 3.0 that would change a DV> lot of the syntax and introduce fantastic new features, but that's DV> too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? Cheers Renato Caldas