Hey, I agree with Doug, but that's neither here nor there since I'm just a user.
That said: On Monday 11 September 2006 07:46, Anselm R. Garbe wrote: > On Mon, Sep 11, 2006 at 07:33:49AM -0400, Doug Bell wrote: > > Anselm R. Garbe wrote: ... > > > 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 ;) Fork!!! Seriously, though... if it ever comes to that, I won't do development, but I can contribute public subversion or darcs hosting, plus resources for a mailing list. At the moment, I don't opine that anything that Anselm is suggesting for WMII is bad; it all sounds good. But I can certainly believe that if somebody decides to take up the mantle (and effort!) of primary developer, they may object to having a back-seat driver. That's when it'll fork. > > > 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. Replacing it with ... what? At the moment, wmiir is magic to me. I know it uses 9P in there, somewhere, but as far as I'm concerned, it could be using any old socket protocol to communicate with wmii. As long as the end result includes something like wmiir, so that I can continue to script wmii with Ruby, then I'm happy. > > But I disagree with the decision to eliminate run-time > > configuration files in dwm. Yes, I could edit "config.h". But why ... > > I've written configuration file parsers before. It isn't that > > tough. Please re-consider this decision. Is the concern that wmii will be abandoned because Anselm working on dwm? Personally, I don't much care what Anselm does with dwm, since I don't use it. Or is this mailing list also used for discussing dwm issues? The rest of this is a discussion about DWM, which I really have no interest in. Unless someone is suggesting stripping runtime configuration out of WMII, then -- for me -- the rest of this discussion is purely academic. > This is UNIX, and it has tradition to customize software in its > source code. dwm is dedicated to point out this tradition. Hmm. I'd debate that. I know very few Unix programs that don't take arguments (which are a form of configuration), and many will take their arguments in the form of a config file. Very, very few Unix programs require you to recompile the program to change the runtime behavior, which is what you do with dwm. I'm not willing to argue which way is better, but it is wrong to suggest that "configuration through compilation" is "The Unix Way." > 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 Yup! Because it takes me three seconds to learn the config file syntax, and I only do that once. Editing the config.h file and recompiling is going to consume that time over, and over, and over... Also, you're assuming that someone already knows the C header syntax, and you're also making assumptions about the resources available to the compiler. It isn't absurd to assume that somebody is using old hardware to run WMII, especially considering WMII's attractive runtime resource requirements. > Also, you should settle with a configuration which can be used > for quite a long time. People change. And even if they didn't, it can take quite a while for a person to get to the point where they're happy with their configuration. Hell, I change my WMII all the time (well, fairly often). My requirements change, my hardware changes, Linux changes. Linux doesn't do suspend-to-RAM correctly on my laptop right now, so I haven't created a hotkey to trigger that. But it might work in the future, at which point I'll want to add a hotkey. And when I do, I'll probably add it, and then change the behavior a couple of times until I work the bugs out and get it the way i like it. I *vastly* prefer doing this with config files (edit-reload) than having to do the whole edit-compile-install-restart loop. My point is that there is at least one user of WMII who feels that he's justified in changing his configuration periodically, and I doubt that I'm the only one. --- SER _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
