> I think I've noted this above, but to be clear, the relationship is that > fvwm continues as it is at the moment, and people are free to work on > it, commit to it, fix bugs, etc. With mvwm, it's a way for us to try > out completely radical ideas, and break fvwm's compatibility, > eventually.
This was exactly my plan for fvwm-3.0. Fvwm has some pretty useful and flexible concecpts, but the basic code structure is also 25 years old. Large parts of the implementation and the syntax are terrible > As for replacing one against the other, I'm not sure. Of course I've no problem if someone wants to continue maintaining the old code, but - once we have the new code - I'm not the person who will do that. The compat stuff can be separated from the new core code, maybe as a module or script. But it's illusive to assume that it would be possible to be completely compatible and redo all the parsing. Fvwm's scripting is too powerful. For me, personally, it's important that we won't say that the "old" fvwm is crap and needs to be replaced with something new, better etc. It just needs to be renovated. P.S.: And I do want a window manager with a reference to cats in its name. ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
