Re: [dwm] dwm's future

Hello,

I am sorry but I really hope dwm can switch to using pango.

X fonts are broken and not well supported, at least in Ubuntu. I have six
Chinese fonts shown in xlsfonts, but only two of them can be displayed. Two
of them only support 16 pixel and 24 pixel size. They are too large, given
that my dpi is as low as 75. The other font is arphic ukai, but it is not
bitmap font, and therefore broken. WenQuanYi Bitmap Song is a nice bitmap
font and covers many encodings, but I can use it for no obvious reason.

It seems to me that pango's powerfulness comes with almost no cost.

For programmers, there is little difference, or at least it generally will
not increase SLOC.

For users, they just need to set the font to something like "Sans-10" or
"Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig
is powerful. User can set spacing, priority, antialias, hinting, and a lot
more properties of fonts, which is necessary for certain fonts.

Of course pango is not as comman as xlib, and it even depends on Cairo, but
it works.

Sincerely,

Haomin Wen
On Sun, Apr 26, 2009 at 6:38 PM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:

> 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 - 11:57:28 UTC