Re: [dwm] DWM is DWM

Since I'm one of the people (I guess) who often talks about different things on the mailing list, I'll just put across my point of view. Firstly, dwm is completely Anslem's wm and I completely respect that. Secondly, I often mention stuff on this mailing list partly to see if someone comes back with a suggestion "there's a better way to do this" that's better than what I'm thinking; things I talk about aren't suggestions for actual implementation (except by me). Finally, whatever I say below I haven't written much code and I obviously respect that Anselm (& others) have actually written much larger amounts. <controversial=on> Having said that, the main reason I moved from wmii is that I really liked the mini-titlebars (which were similar to what I was using as a nasty personal hack to Ion3 at the time) and I couldn't figure out how to modify the wmii codebase to support them. The wmii codebase was so dense that I've several times tried to look at it and come away an hour or so later none the wiser. My personal opinion is that a major part of the problem with wmii is that the code is _too_ small, in the sense that there's a large amount of interrelated code that's split between the various programs and that's doesn't introduce any abstraction but stays at such a low level, so you have to read and correlate almost everything to get a handle on any individual thing. (I'd be very impressed if anyone can actually tell what if((c = sel) == nexttiled(clients)) if(!(c = nexttiled(c->next))) return; does (particularly wrt side-effects into following code) at a high-level without basically drawing a client list on a piece of paper and trying various permutations for sel and viewed clients :-) ) In general, I think obsessing over lines of code is misguided; I think the ideas of "tastefully coded" and "well-defined" task would serve better for code that sucks less. Generally, I feel that programs should be try and maintain a clear well-defined task and not bring in peripheral activities "because they can" (expanding the plethora of things web-browsers do, etc) but accept there will be other programs that can perform those things. However, within a well-defined task I don't see any problem with adding well-defined, simply coded functionality (which may or may not be a user invocable "functionality"). Al the things I think about and talk about are elements central to _automatic window management_ that I think it makes perfect sense to incorporate into _a_ window manager, even though I know they probably aren't appropriate for mainstream dwm given its mission statement. I know _in my personal work situation_ my modifications like multiple columns, maintaining certain aspect ratios, etc, to dwm make it much more useful _for me_ than bare dwm (which is much more useful that most other window managers). I try and make available my stuff, partly in case anyone else finds them useful and partly in case anyone is stimulated to reply with better ideas. <controversial=off> Anyway, I guess what I'm saying is by all means go for simplicity, but don't get hung up on reducing lines of code that actually make things _less_ simple. My POV, cheers, dave tweed Send instant messages to your online friends http://uk.messenger.yahoo.com
Received on Sat Nov 25 2006 - 09:59:55 UTC