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: 0D73F361Received on Mon Sep 11 2006 - 13:46:58 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:13:37 UTC