On Thu, Aug 14, 2014 at 12:51:33AM +0100, Thomas Adam wrote: > > this guy asked about porting mvwm patches to fvwm, and I don't > > know what to answer. As you know, I've been inactive in fvwm for > > years, and I even missed your fork. Can you tell me a bit about > > your project, its goals and what your plans are for the future > > relation of fvwm and mvwm? > > Sure. I need to be careful about calling it a fork, because it's still > compatible with fvwm. The reason I've forked it and called it mvwm is > to allow me to run the two side-by-side, and that also trying to do this > in CVS would have made me cry [0].
Same for me. I really do not want to work with CVS anymore, and I'd be happy if we had an fvwm git repository tomorrow. :-) > You can have a look here for the TODO file: > > https://github.com/ThomasAdam/mvwm/blob/master/TODO I have taken a look, and can provide background information on various points. Also, I'm interested in discussing the list and helping with the implementation. Do you have already set up a place to discuss the "mvwm" work? Ideally, if the plan is to keep compatible to the current fvwm at least for a while, it would be cool if fvwm-workers gets a copy of the "mvwm" discussions. I think the fvwm users should be a part of the renewal process. Just two quick comments on points of the TODO list. 1) Static vs. dynamic linkage Today, there's really no reason anymore to statically link the fvwm library. Back in the days when I vehemently fought for keeping static linkage, the library was small, and dynamic linking was somewhat unstable. Both is not the case anymore; switching to dynamic linking is a good thing today. 2) Parsing That each command and style does its own parsing is terrible and has bothered me for many years. As a first step I would like to write a new parser that can be configured to deal with the syntax of every existing command and style. The commands can then be adapted to the parser one by one, and if we clean up the commands one day, the parser should still be usable. Switching to a real parser would also remove tons of bugs in the various functions and save a lot of code. And I'd like to start discussing that as soon as possible. > I'm also keen to shrink some of the things fvwm offers---things like the > decor stuff, and having complicated colour gradients, ying/yang > drawings, etc., just seem really strange to me, and a lot of bloat. Hm, the yin-yang gradients were more an expression of the enthusiasm we experienced when the colorsets were invented than a real feature. :-) It was so cool that things like that were suddenly possible with just a little extra code. > I've ripped out a lot of the fvwm modules I > consider to be passe, perhaps too aggressively. Many years ago we already concluded that all of the gui-like modules (buttons, taskbar, iconman, iconbox, pager etc.) should eventually be replaced by a single module (with the provisional name "FvwmGui"). In my eyes, it * combines all the functionality of the obsolete modules, * uses colorsets consequently to allow configuring _all_ gui elements, * can be reconfigured at run time through user interaction (e.g. dragging elements to a different spot in the window), * can parse all the old module configurations, at least in the beginning, * can replace all the old modules with symlinks for compatibility. > The net result of this is to over time amass no real sweeping changes > from fvwm, but to change the underlying things quite a bit. That's > really important, because I believe in fvwm. Ideally, I'd try to keep compatible to fvwm as long as possible. Of course that is not possible once we start cleaning up the syntax. > [0] You and I have looked at this in the past, moving to it. If that's > ever something you want to pick up again, just say the word, all the > bits and pieces are there, and I still maintain the fvwm git repo on > Github. I am happy that you have started the process - something I never managed. And yes, I'd love to help with all the work that needs to be done as soon as possible. For me, there are two important questions: * What is the relationship between fvwm and mvwm. It is clear that once the work starts, fvwm2 is sentenced to an eventual death. The question is how to manage the process of replacing fvwm2 with the reworked code (mvwm, fvwm3, whatever). * We need a place to get organized and discuss things. Maybe it would suffice to simply use fvwm-workers and prefix all rework related messages with "MVWM:" or whatever. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
