On Mon, Sep 11, 2006 at 07:33:49AM -0400, Doug Bell wrote: > Anselm R. Garbe wrote: > > I propose following strategy. I'd like to wait until October, if > > Kris will re-appear till then, everything is fine. If not, we > > need another maintainer for wmii. I won't do the job again, > So you refuse to maintain wmii and there is no visible replacement > maintainer, but you are still directing it's development? Do you > expect this to work? As long as wmii is hosted on my server it has to work ;)
> > because from my POV dwm is the way to go. > I think that some of dwm's simplifications are worthwhile. For example, > I never thought that the 9P support in wmii was worth the downsides of > slower operation and so many race conditions. > > But I disagree with the decision to eliminate run-time configuration > files in dwm. Yes, I could edit "config.h". But why should I have to > recompile and re-install every time I change a setting? Also, this > scheme does not fit in well with multi-user systems. > > I've written configuration file parsers before. It isn't that tough. > Please re-consider this decision. > > I think that the right direction lies somewhere in the middle ground > between wmii and dwm. This is UNIX, and it has tradition to customize software in its source code. dwm is dedicated to point out this tradition. Is it more time-consuming to edit a config.h file and recompile the whole source code in 3s than learning yet another config file syntax and editing a config file? I think the 3s overhead are not an issue. Besides this, they keep out some useless complexity from the source code (eg parsing shortcuts, rules etc.), the program would only process one time at the startup. Also, you should settle with a configuration which can be used for quite a long time. If you really can't stand the way as it's done, it looks trivial to add yet another 200 LOC as a patch to write a config file parser or whatever. But I don't plan to do that (if you or someone else really considers this, the simpliest way would be writing the configuration to standard input and defining a special prefix for status text, e.g. 'status:'). But the main idea behind dwm is, that you can do source modifications easily to let the wm fit your needs. You can change how it arranges windows, or add extra special functions and bind keys to it, without learning yet another programming language. That has been the intention, and it's also the intention for other upcoming tools like st. At a bare minimum, there is config.h for the most common modifications. Regards, -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
