2009/4/26 Szabolcs Nagy <nszabo...@gmail.com>: > On 4/25/09, Anselm R Garbe <garb...@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
