Re: [dwm] placement of tags on titles

From: Anselm R. Garbe <>
Date: Thu, 24 Aug 2006 15:17:25 +0200

On Thu, Aug 24, 2006 at 03:10:47PM +0200, Julian Romero wrote:
> On 8/24/06, Sander van Dijk <> wrote:
> >On 8/24/06, Julian Romero <> wrote:
> >> > To me, part of minimalism is keeping the amount
> >> > of stuff that you can/have to configure small,
> >> Elegance also matters, and having different colors for different
> >> things is more elegant that excesive saving/reusing.
> >
> >I beg to differ: I definitally agree that elegance matters, but I
> >believe that a having a bunch of color-this, color-that, color-such,
> >color-so, color-here, color-there, color-blabla defines is far less
> >elegant than the current situation. There isn't excesive reusing,
> >there is sane reusing. This is supposed to be a functional wm, not
> >some flashy bling-bling thing.
> >
> Flashy?
> I'm not proposing adding horizontal blinking auto-scrolling for long
> text status messages.
> Are you also in the Gnome list and answered the wrong message? ;)
> If we move our conflictive #define's to dwm.h we'll be talking about
> good programming practices, not about configurability anymore.
> Active window title is hard to read.
> Current focused window is hard to notice.
> Top-right unfocused window's title mix (visually) with status.
> Not allowing columns vs. rows layout is arbitrary.
> etc.
> All this can be solved adding a few (very few) #defines in some .h
> plus some code refactoring. As a side effect the code will allow
> faster configuration and will be more self-documented.

I don't see what is questionable here. We have
#define {FG,BG,BORDER}COLOR in dwm-1.0?

If you ask for BORDERW, and for some other magic numbers, yes there I
agree that it might be a good idea to use a name instead, but
those cases of magic numbers are very very rare in the source.

Thus I don't see what's wrong with the current approaches?


 Anselm R. Garbe  ><><  ><><  GPG key: 0D73F361
Received on Thu Aug 24 2006 - 15:17:26 UTC

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