I have seen this issue of configuration management and program complexity
come again and again. However, I have seen different people solve it
different ways... none being necessarily technically superior to anything
else. The way I see it, its more subjective and depends on the community
which shapes the product.
However, I do see an inherent cleanliness in using a programming language
for configuration itself. Most configuration languages are a combination of
assignments, comments and in rare cases some control flow. The question is,
why do the duplicated work of parsing and converting between one set of data
structures to another when you already have a well tested compiler/runtime
with you.
The compilation step does make the whole thing a little more complicated.
Had it been a scripting language (say lua) we could have made the
configuration file in lua itself which would be really convenient if the
window manager logic was written in lua too... we would just need in include
the file and be done with it... no compilation step required. In dwm's case,
I think C is more of a matter of subjective choice.
On the other hand for a source based distribution like gentoo, the
compilation step really doesn't matter because every upgrade of dwm would
require a recompilation and the configuration file in C is handled properly.
_r
On Feb 1, 2008 9:19 AM, Doug Bell <dougb_AT_bellz.org> wrote:
> markus schnalke wrote:
> > Joerg van den Hoff <j.van_den_hoff_AT_fzd.de> wrote:
> > >
> > > definitely don't believe in configuring a window manager by
> > > editing the source code. at the very least, this seems to imply
> > > that one starts over and over again with each new release (or
> > > one has to verify that the config header default layout has not
> > > changed.
> >
> > I upgrade dwm every half year or so. Normally there is no need for
> > users to follow the latest development.
> >
> > > I would stil be in favour of some simple(-minded)
> > > configuration file of the keyword/value variety (or even activating
> > > this by a compile flag only, leaving the defaults defined in config.h
> ).
> >
> > What is the big difference between config.h and a .dwmrc?
> > If .dwmrc would be simple, then editing config.h is needed anyway.
> > (Applying patches is needed anyway.)
> > If .dwmrc would be complete, then it would be the same as config.h.
> >
> > You sayed, that compling is not a problem.
> > And how often do you change your window manager configuration?
> >
> > > that's no good if I'm actually "only" a user of a nice window manager
> > > who needs to get other things done.
> >
> > So just take what vanilla-dwm offers you.
> > ... or if you want more, then apply some patches.
> >
> > > if I look at the home page there a quite a few nice extensions to
> `dwm'
> > > which are tied to specific releases and are simply left behind while
> > > dwm is developed further. I think this is a pity.
> >
> > dwm is community development. It's from developers for developers.
> > The available patches are just published personal extensions.
>
> I guess I agree with Joerg. I've been using dwm for more than a year
> (and various versions of wmi[i] for years before that), but I recently
> switched to awesome (<http://awesome.naquadah.org>). awesome is a fork
> of dwm with a different philosophy.
>
> I don't mean to troll here - I don't plan any more posts. I just wanted
> to share some advantages I see in awesome:
>
> - Conventional config file: Recompiling isn't much of a pain, but it
> is another step.
>
> - Distribution package: The use of a config file allows me to use the
> Debian package as-is, like I do for almost everything else.
>
> - Potential popularity: I'd like tiling window managers to gain in
> popularity to increase the incentive to fix broken applications that
> don't play nice. The above factors should contribute to long-term
> popularity.
>
> - More built-in features: Several features that would require dealing
> with patches (and keeping them current and playing nice together)
> are built into awesome. And some features I don't use are easy to
> ignore.
>
> - Interesting new development: awesome is still fairly early in
> development, so it's still experimenting with new ideas. dwm is
> more mature but less exciting.
>
> Yes, the awesome executable is three times the size of dwm's, but, for
> me, that is outweighed by the advantages above. At least awesome's
> executable is still less than 1% of the size of Firefox's :)
>
> Doug.
>
>
Received on Sun Feb 03 2008 - 03:57:46 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:18:08 UTC