Re: [dwm] dwm's future

From: Haomin Wen <wen1987_AT_gmail.com>
Date: Sun, 26 Apr 2009 20:00:16 +0800

Oh, sorry. There is a typo. Three but not two Chinese fonts can be
displayed. Two of them are too large, and the third one is not bitmap font.

On Sun, Apr 26, 2009 at 7:57 PM, Haomin Wen <wen1987_AT_gmail.com> wrote:

> 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 - 12:00:16 UTC

This archive was generated by hypermail 2.2.0 : Sun Apr 26 2009 - 12:12:04 UTC