Re: [dwm] dwm's future

2009/4/26 Szabolcs Nagy <nszabolcs_AT_gmail.com>:
> On 4/25/09, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>> 1. One idea is getting rid of the dwm bar altogether and to print the
>> dwm state to stdout when it changes, however after thinking carefully
>> about it I conclude that having the bar build-in is definately a
>> stayer. It's so much simpler than the hassle with an external bar, not
>> worth it. So very unlikely.
>
> if external bar is a hassle then inter-process communication is broken
> in our systems
>
> if built-in bar is a hassle then x is broken (unable to display text)

Well, an external bar is a hassle because it would increase the
overall complexity if it's assumed to be implemented properly (or in a
fashion like what we got). One has to specify handling where the bar
appears, which size, and all kinds of interface handling between the
bar and dwm.

>> 2. Another idea is to switch to another dependency for the rendering
>> bit which could possibly be cairo. After all I'm nearly giving up the
>> hope that X font handling will ever be fixed and work properly,
>
> $ du -h /usr/lib/libcairo.a
> 608K    /usr/lib/libcairo.a
>
> pango seems to be slightly smaller, but i don't know what these libs
> do exactly..

They do fairly more than what we need for a single bar. So let's stick
to what we got.

> imo it's not suckless, but it can be a temporary solution until x is fixed

Knowing who drives the X development I gave up any hope that X will
ever be fixed, more the contrary.

I think the only solution is dws, which needs more assistance and
which can be based on legacy crap. Important is that dws provides
decent interfaces and possibly a legacy X interface on top of it. I
think that's the long term plan we should achieve. But it'll take a
long time with the resources we got atm (I hoped GSoC would sponsor us
somehow to get started into that direction).

>> 3. A third idea for legacy support is, that I tend to add a
>> compile-time option or a specific Rule extension that let's you set to
>> reparent all clients or certain clients which are broken
>
> rule extension won't work as these applications tend not to set
> class,instance,name properly

Yea that's a pity and that makes the rules more questionable, perhaps
I should make them simpler or changing the mechanism eg having a
"catch next map" function instead which applies a certain rule to the
next window which is mapped.

Kind regards,
--Anselm
Received on Sun Apr 26 2009 - 10:38:29 UTC