Re: [dwm] placement of tags on titles

From: Sander van Dijk <a.h.vandijk_AT_gmail.com>
Date: Thu, 24 Aug 2006 13:28:50 +0200

On 8/24/06, Stefan Tibus <sjti_AT_gmx.net> wrote:
> On Thu, 24 Aug 2006 12:19:47 +0200 "Sander van Dijk" <a.h.vandijk_AT_gmail.com> wrote:
> > It's not the amount of #define's that bother me, but the amount of
> > colors to configure. I know that just two extra bordercolors isn't
> > much, but where do you draw the line? Someone else might want separate
> > colors for the stdin status thing on the right, or for the titles on
> > non-focused windows.
> Actually, it would be a good idea. Those are different contents being
> presented in the dwm bar, so they should be distinguished.

Yes, I was afraid already that this would be the reply ;-)

> > To me, part of minimalism is keeping the amount
> > of stuff that you can/have to configure small, leaving only things
> > that matter 'sufficiently' configurable (I'm well aware that that's
> > not objectively determinable).
> Well, it should try to reduce the amount that _has_ to be configured,
> but it shouldn't reduce what may be configured. The default could
> still be
> #define STATUS_FOREGROUND NORMAL_FOREGROUND

It's open source, so basically the configuration options are
unlimited; however, it's of course a good thing to provide an easier
way of configuration for the things most likely to be changed (such as
keybindings, tags, etc). That's why config.h was introduced (early
versions of dwm still had those part spread out across the various
source files, and the user had to grep for CUSTOMIZE to find them).
Keeping the amount of configuration options in config.h to a minimum
is a good thing to me, since that means that it'll always be easy to
see what global options there are. By making all colors customizable
through config.h, we'd only clutter it and make configuration harder;
besides, having say 10 functional configuration options, and an equal
amount (or more) for something as trivial as colorsettings misses the
point I believe. dwm is obviously a wm that aims at functionality, not
eyecandy...

> > For exactly this reason, the removal of
> > DEFTAG was a good idea, for instance.
> Don't think so, those defines even make the code more readable,
> as you can _read_ what this colour (or any other number) is
> about.

The reason DEFTAG's removal was a good idea because it's pointless to
have it configurable (at the config.h level) at all. Just use tag 1 as
the default tag is much simpler. If people _really_ need to start
working at tag 2 for some obscure reason, they can just change it in
the source. Such triviality does not belong in config.h, since it only
clutters it, making it harder to find the stuff that _does_ matter.

> > Dunno if you've ever tried to
> > configure MS Windows' color/fontscheme, but that's a situation I'd
> > like to avoid for dwm (in fact, if one could take for granted that
> > fore- and background color look good and are readable when inverted
> > too, I would have suggested to just use two colors instead of four).
> Yes I did (>10 years ago). What's the problem with it? Even though
> some defaults may look good, I didn't like most. That's personal
> taste and may even change. And in contrast to changing the colour
> of my car, changing the colour of my wm is no huge effort (neither
> for the user nor for the programmer in this case).

I didn't mean that changing the colors is a bad thing, I meant that
the procedure itself sucks because there's just way too much to
configure (color here, color there, font such, font so, font again,
some more colors, blablabla... Why no just _one_ font, for starters,
and a whole lot less colors...)

> And if it takes more LOC to produce better readable code, I prefer
> the larger one... (i.e. I'd leave DEFTAG in, e.g.).

Not when it's pointless, which DEFTAG is.

Greetings, Sander.

PS. a little disclaimer: English is not my native language, which may
occasionally lead to statements that appear harsher than I intend
them. I'm just trying to state my oppinion, not to flame and/or make
personal attacks...
Received on Thu Aug 24 2006 - 13:28:51 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 14:30:26 UTC