As a remark, one could always use config.h as configuration file
and run make from a wrapper script before dwm is started in
.xinitrc -- so you aim the same behavior as having a config
file, but without the overhead of a config file parser.
Kind regards,
Anselm
On Sat, Feb 02, 2008 at 09:57:43PM -0500, Ritesh Kumar wrote:
> 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 <[EMAIL PROTECTED]> wrote:
>
> > markus schnalke wrote:
> > > Joerg van den Hoff <[EMAIL PROTECTED]> 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.
> >
> >
--
Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
