Re: [dwm] dwm's future

[Marc Andre Tanner]

On Sun, Apr 26, 2009 at 08:15:40AM -0500, Kurt H Maier wrote:
> I may be be in the minority here, but ASCII works wonderfully, and I'm
> happy with the state of font rendering in dwm.

+1 

-- 
 Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0

Re: [dwm] [idea] mwm - minimal/minimun/monocle window manager

[Leandro Chescotta]

Well, someone start this earlier,
*Wra!thin archlinux
forums
* here http://bbs.archlinux.org/viewtopic.php?id=70902 hope the best to this
project! :)

actually it's name is Most Minimal Window Manager (MMWM) lol and it
something in between dwm and antiwm, like antiwm with more features, like...

So far it has keys to:
- pop a new terminal
- kill selected window
- cycle through windows
- pop a launcher menu (using dmenu by default)
- show a list of windows (working, but needs some enhancement)

Configurable options:
- launcher menu to run
- terminal to run
- font
- window list fg/bg color/selected window fg color/
- screen padding(how much space to leave unmanaged on all sides of the
screen - you can see a 16 pixel gap on top of the screenie)
- window list position (one of the four corners)



On Sun, Apr 26, 2009 at 6:34 PM, Leandro Chescotta <
leandro.chesco...@gmail.com> wrote:

> mmm yes i can, but i was thinking that maybe we can even strip even down
> dwm code, i don't know a lot about programming (actually very little), so
> maybe im not the "chosen one" to do this, i think that the idea is worth the
> discussion at least
>
>
>
> On Sun, Apr 26, 2009 at 4:32 PM, yy  wrote:
>
>> 2009/4/26 Leandro Chescotta :
>> > - no tags, only a "list" of opened windows, that you can cycle with one
>> > keybinding or Alt+number
>> > - no bottom bar, just the window list that you can show/hide
>> > - no layouts, only a monocle-like one, and a floating "layer" for
>> > mplayer/feh/gimp
>> > - lol, an arch linux AUR package with the config.h ready to customize
>> the
>> > few font/colors/keybindings/apps
>> >
>>
>> you could just run dwm without the bar, with only one tag, and with
>> only the monocle layout.
>>
>>
>> --
>> - yiyus || JGL .
>>
>>
>
>
> --
>
> -
> http://aleyscha.spaces.live.com/
>
> ""El lugar mas peligroso de todos es el cielo... En el, cada pensamiento se
> hace realidad... sea bueno o malo... creas tu paraiso o tu infierno""
>



-- 

-
http://aleyscha.spaces.live.com/

""El lugar mas peligroso de todos es el cielo... En el, cada pensamiento se
hace realidad... sea bueno o malo... creas tu paraiso o tu infierno""

Re: [dwm] [idea] mwm - minimal/minimun/monocle window manager

[Leandro Chescotta]

mmm yes i can, but i was thinking that maybe we can even strip even down dwm
code, i don't know a lot about programming (actually very little), so maybe
im not the "chosen one" to do this, i think that the idea is worth the
discussion at least


On Sun, Apr 26, 2009 at 4:32 PM, yy  wrote:

> 2009/4/26 Leandro Chescotta :
> > - no tags, only a "list" of opened windows, that you can cycle with one
> > keybinding or Alt+number
> > - no bottom bar, just the window list that you can show/hide
> > - no layouts, only a monocle-like one, and a floating "layer" for
> > mplayer/feh/gimp
> > - lol, an arch linux AUR package with the config.h ready to customize the
> > few font/colors/keybindings/apps
> >
>
> you could just run dwm without the bar, with only one tag, and with
> only the monocle layout.
>
>
> --
> - yiyus || JGL .
>
>


-- 

-
http://aleyscha.spaces.live.com/

""El lugar mas peligroso de todos es el cielo... En el, cada pensamiento se
hace realidad... sea bueno o malo... creas tu paraiso o tu infierno""

Re: [dwm] dwm's future

[David Tweed]

On Sun, Apr 26, 2009 at 4:26 PM, Evgeny Grablyk
 wrote:
> Why not make statusbar a (default) compile-time option, and add
> possibility to export all statusbar information? This way user can
> choose between builtin statusbar, or make his own. To make things more
> simple, mouseclick support for statusbar should be removed.

One thing that's interesting is that no-one ever quantifies in what
manner things become simpler: for the programmers, for the user or
some other metric? I'll reiterate a point that I've made in the past
that I don't really care about number of lines of code providing that
the application provides the appropriate level of self-consistent
functionality (ie, the amount of functionality that makes sense at
this point in the software stack). Some of my custom tile()
implementations involve many more lines of quite intricate code that
nevertheless gives a "sophisticated but predictable" behaviour when
I'm a user.

In particular, when I'm on a desktop machine with a mouseI often use
clicks on the tags to manipulate the view. I'd be sad if that simple,
predictable functionality were removed simply because it means a lower
SLOC number can be quoted. (This is probably flamebait, but for some
reason the phrase "Cargo Cult" comes to mind.)

-- 
cheers, dave tweed__
computer vision reasearcher: david.tw...@gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot

Re: [dwm] [idea] mwm - minimal/minimun/monocle window manager

[Matthias-Christian Ott]

On Sun, Apr 26, 2009 at 04:11:25PM -0300, Leandro Chescotta wrote:
> minimal/minimum/monocle window manager, this come to my head today, when i
> meet antiwm http://sourceforge.net/projects/antiwm this is like dwm, but
> with no tags, no bottom bar, no layouts, more like ratpoison, the thing is
> that i tryed ratpoison and antiwm, and it lacks a couple of things, so, i
> see that suckless have wmii, stripping down there is dwm, and why not a
> smaller one like a suckless antiwm... mwm! :) this are the things i think
> mwm need...
> 
> - no tags, only a "list" of opened windows, that you can cycle with one
> keybinding or Alt+number
> - no bottom bar, just the window list that you can show/hide
> - no layouts, only a monocle-like one, and a floating "layer" for
> mplayer/feh/gimp
> - lol, an arch linux AUR package with the config.h ready to customize the
> few font/colors/keybindings/apps
 
Despite the fact that dwm already supports this, I like the idea. It should
be quite usable on netbooks and other computers with small screen where
monocle is the only option.

> maybe this is not worthy, but i like the idea, maybe you too, maybe is like
> getting dwm code and strip it down a little, only, maybe not...

You could probably through away much of dwm's code then.

Let us know when you release mwm.

Regards,
Matthias-Christian

Re: [dwm] [idea] mwm - minimal/minimun/monocle window manager

[yy]

2009/4/26 Leandro Chescotta :
> - no tags, only a "list" of opened windows, that you can cycle with one
> keybinding or Alt+number
> - no bottom bar, just the window list that you can show/hide
> - no layouts, only a monocle-like one, and a floating "layer" for
> mplayer/feh/gimp
> - lol, an arch linux AUR package with the config.h ready to customize the
> few font/colors/keybindings/apps
>

you could just run dwm without the bar, with only one tag, and with
only the monocle layout.


-- 
- yiyus || JGL .

Re: [dwm] dwm's future

[Kurt H Maier]

On Sun, Apr 26, 2009 at 2:08 PM, David E. Thiel
 wrote:
> Agreed. Proven fact: non-English-speaking people exist. Minimalism and
> simplicity shouldn't exclude basic functionality like displaying
> characters in the language the user speaks.

Rendering thousands of different codesets is not "basic
functionality."  Proven (in this very thread) fact: nobody has yet
come up with a suckless way to display unicode.  If x11's font
rendering is broken, fix it -- don't bloat up client software to work
around it.

# Kurt H Maier

[dwm] [idea] mwm - minimal/minimun/monocle window manager

[Leandro Chescotta]

minimal/minimum/monocle window manager, this come to my head today, when i
meet antiwm http://sourceforge.net/projects/antiwm this is like dwm, but
with no tags, no bottom bar, no layouts, more like ratpoison, the thing is
that i tryed ratpoison and antiwm, and it lacks a couple of things, so, i
see that suckless have wmii, stripping down there is dwm, and why not a
smaller one like a suckless antiwm... mwm! :) this are the things i think
mwm need...

- no tags, only a "list" of opened windows, that you can cycle with one
keybinding or Alt+number
- no bottom bar, just the window list that you can show/hide
- no layouts, only a monocle-like one, and a floating "layer" for
mplayer/feh/gimp
- lol, an arch linux AUR package with the config.h ready to customize the
few font/colors/keybindings/apps

maybe this is not worthy, but i like the idea, maybe you too, maybe is like
getting dwm code and strip it down a little, only, maybe not...

Re: [dwm] dwm's future

[David E. Thiel]

On Sun, Apr 26, 2009 at 05:09:26PM +0200, Antoni Grzymala wrote:
> Mate Nagy dixit (2009-04-26, 17:01):
> >  However, I strongly believe that the major problem of dwm currently is
> > not font handling (8bit ascii bitmap fonts are perfectly fine thank
> > you);
> 
> This is a very selfish view. 8-bit character sets suck big way, even not
> considering anything outside accented latin characters (which either
> work or not, usually not quite).

Agreed. Proven fact: non-English-speaking people exist. Minimalism and
simplicity shouldn't exclude basic functionality like displaying
characters in the language the user speaks.

Re: [dwm] dwm's future

[Enno Boland (Gottox)]

Hi There!
>  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 such as
>  Mathematica or various Swing apps, though I'm not absolutely sure how
>  likely that is. Somehow my inner feelings are against it, because it's
>  not a dwm problem and those broken apps should be fixed.
I believe that a compile time switch in rules is unneccessary. If we
want to support these b0rken apps, why not reparent any client?

regard
Gottox

Re: [dwm] dwm's future

[Guillaume Quintin]

Hi,

I never look at the windows titles. I only look at the tags in the 
status bar. So for me, this font rendering problem is less important 
than this problem : handling several monitors. I agree with Mate Nagy 
about dwm handling correctly several monitors. My point of view is that 
we should have Client *clients[NUMBER_OF_MONITORS] and manage each 
monitor independantly. But we should be able to move a window from a 
monitor to another and alsa an entire tag.


I agree with Jeremy Jay about a system of plugins... So that dwm stay 
very simple and one can build a nice status bar with cairo or pango 
dependencies if he wants. Why not implement this ?


--
Kind regards
Guillaume Quintin

Re: [dwm] dwm's future

[Kurt H Maier]

On Sun, Apr 26, 2009 at 10:45 AM, Mate Nagy  wrote:
>> ...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of
>> DVI-1.  Problem solved.
>  well obviously i had something more sophisticated in mind :)
>  like, horribile dictu, displaying different tags or different layouts
> on different monitors. or supporting more monitors than 2...

Okay, so I was being a bit of a smartass there :)

I really think that such cases are best left to a window manager that
tries to 'do everything' -- dwm is perfect for one (or two, in my
case) large monitor, and it handles it very well.  I keep hoping to
see dwm go into a 'steady state' where the only patches are to
maintain compatibility with latest x.org, etc., but instead every time
it seems 'done' we shoot forward into crazy-ass ideas like requiring
an extra 0.5 MB of libraries for a 2k SLOC program, just so people's
firefox titles look better.

Instead of porting everything to pango, I suggest leaving it alone,
and the affected users can turn the built-in bar off and use another
status bar program.


# Kurt H Maier

Re: [dwm] dwm's future

[Mate Nagy]

> ...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of
> DVI-1.  Problem solved.
 well obviously i had something more sophisticated in mind :)
 like, horribile dictu, displaying different tags or different layouts
on different monitors. or supporting more monitors than 2...

M.

Re: [dwm] dwm's future

[Kurt H Maier]

On Sun, Apr 26, 2009 at 10:01 AM, Mate Nagy  wrote:
> I strongly believe that the major problem of dwm currently is
> not font handling (8bit ascii bitmap fonts are perfectly fine thank
> you);

Agree 100%.  Folks, if you want unicode support, develop a sane,
working implementation.  I've never seen one that matches both "sane"
and "working."

> 1. Complete lack of proper xrandr and multi monitor support - this is
> solved in multiple tiling wms, there's no reason other than lack of
> interest or obscure ideology not to do this.

Here's a patch to make DWM work fine on a two-monitor side-by-side setup:

--- dwm.c~  2009-02-08 06:10:49.0 -0600
+++ dwm.c   2009-02-25 18:54:17.0 -0600
@@ -1415,7 +1415,7 @@
c = nexttiled(clients);
mw = mfact * ww;
adjustborder(c, n == 1 ? 0 : borderpx);
-   resize(c, wx, wy, (n == 1 ? ww : mw) - 2 * c->bw, wh - 2 * c->bw,
resizehints);
+   resize(c, wx, wy, mw - 2 * c->bw, wh - 2 * c->bw, resizehints);

if(--n == 0)
return;


...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of
DVI-1.  Problem solved.

# Kurt H Maier

Re: [dwm] dwm's future

[Evgeny Grablyk]

Hi,

Why not make statusbar a (default) compile-time option, and add
possibility to export all statusbar information? This way user can
choose between builtin statusbar, or make his own. To make things more
simple, mouseclick support for statusbar should be removed.

As about cairo/pango, again, why not make that optional? Or will that
add much code and so increase dwm's own complexity?

--
Evgeny

Re: [dwm] dwm's future

[bill lam]

On Sun, 26 Apr 2009, Haomin Wen wrote:
> I do not care antialias or hinting if there are bitmap fonts, but they
> are necessary when using some truetype fonts. I use dmenu to show how
> fonts are broken.
> 
> https://www.getdropbox.com/gallery/957017/1/dwm?h=fb5e6b

Thanks, I follow you example by echo "nei hou" but the "nei" always
become "Dc", not sure if this a problem in dmenu or not.

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩013 王維  送別
下馬飲君酒  問君何所之  君言不得意  歸臥南山陲  但去莫復聞  白雲無盡時

Re: [dwm] dwm's future

[Antoni Grzymala]

Mate Nagy dixit (2009-04-26, 17:01):

>  However, I strongly believe that the major problem of dwm currently is
> not font handling (8bit ascii bitmap fonts are perfectly fine thank
> you);

This is a very selfish view. 8-bit character sets suck big way, even not
considering anything outside accented latin characters (which either
work or not, usually not quite).

Agree with the rest of your points.

-- 
[a]

Re: [dwm] dwm's future

[Mate Nagy]

Hi all,
 I'm sure there is a severe risk of this piece being understood as
flamebait (this is not my intention).

 However, I strongly believe that the major problem of dwm currently is
not font handling (8bit ascii bitmap fonts are perfectly fine thank
you); not the status bar (it's great); instead, it's twofold:

1. Complete lack of proper xrandr and multi monitor support - this is
solved in multiple tiling wms, there's no reason other than lack of
interest or obscure ideology not to do this.

2. Handling of broken applications (reparenting). Not many tiling wms
get this right. I believe a good solution is to unconditionally reparent
all windows. This adds some code, but means no difference to the user
(the window "frame" can still be a single pixel border, if you like),
however it fixes all/most incompatibility problems in a single stroke.

NB. the added complexity of unconditional reparenting is massively
smaller than using pango (especially if you consider the dependencies);
the achieved improvement in perceived user experience is also arguably
much larger.

Regards,
 Mate

Re: [dwm] dwm's future

[Haomin Wen]

I do not care antialias or hinting if there are bitmap fonts, but they
are necessary when using some truetype fonts. I use dmenu to show how
fonts are broken.

https://www.getdropbox.com/gallery/957017/1/dwm?h=fb5e6b

On Sun, Apr 26, 2009 at 10:13 PM, bill lam  wrote:
> On Sun, 26 Apr 2009, Haomin Wen 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.
>
> Can you give examples, eg url where its title failed to displayed
> properly using firefox?  I use debian and previosly ubuntu and found
> no problems.  Not sure why correlate  bitmap font to broken or not?
> What do you mean by broken?  Can you give some screen shoot.  Does
> that really matter to have antialias or hinting in the single line
> bar?
>
> --
> regards,
> 
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> 唐詩150 劉禹錫  蜀先主廟
>天地英雄氣  千秋尚凜然  勢分三足鼎  業復五銖錢
>得相能開國  生兒不象賢  淒涼蜀故妓  來舞魏宮前
>
>

Re: [dwm] dwm's future

[bill lam]

On Sun, 26 Apr 2009, Haomin Wen 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.

Can you give examples, eg url where its title failed to displayed
properly using firefox?  I use debian and previosly ubuntu and found
no problems.  Not sure why correlate  bitmap font to broken or not?
What do you mean by broken?  Can you give some screen shoot.  Does
that really matter to have antialias or hinting in the single line
bar?

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩150 劉禹錫  蜀先主廟
天地英雄氣  千秋尚凜然  勢分三足鼎  業復五銖錢
得相能開國  生兒不象賢  淒涼蜀故妓  來舞魏宮前

Re: [dwm] dwm's future

[yy]

You could add an option to print the window title to stdout. This way
if somebody wants to pipe it to an external program to show window
titles (like dzen on top of the dwm bar), they can.


-- 
- yiyus || JGL .

Re: [dwm] dwm's future

[Haomin Wen]

On Sun, Apr 26, 2009 at 9:15 PM, Kurt H Maier  wrote:
>
> On Sun, Apr 26, 2009 at 6:57 AM, Haomin Wen  wrote:
> > For programmers, there is little difference, or at least it generally will
> > not increase SLOC.
> Yes, but at the cost of dragging in a huge chain of libraries, which
> is insanity.  Just because you can't see the complexity doesn't mean
> it's not there.
>
> > 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.
>
> Not only can the user set these things, the user *has to*, because
> otherwise his screen is an unreadable mess.

Most users need not set these things by themselves. Distributions and
font makers can do this work for them. Many students in my school said
that they are well pleased with the default Chinese font looking in
Ubuntu 9.04. Of course distributions and font makers could have
provide better support for X fonts, but it seems that they are losing
interests on X fonts. I prefer X fonts years ago. At that time Debian
support X fonts fairly well, but now some tools, dfontmgr for example,
are no longer supported.

Even if some people have certain special needs, dwm built with pango
will probably not be a problem for them. Anyway most people use
firefox or some other soft which also depend on fontconfig, hence they
need to tune fontconfig soon or later.
>
> I may be be in the minority here, but ASCII works wonderfully, and I'm
> happy with the state of font rendering in dwm.
>
> # Kurt H Maier
>

Re: [dwm] Low Power Fanless Computer

[Kai Großjohann]

I suggest to buy some sort of laptop or netbook and ignore the internal 
keyboard/display.


Perhaps the Dell Mini 12 is good (since fanless) but I don't know how it 
fits into the other requirements.


Kai

On 04/25/2009 02:59 AM, Matthias-Christian Ott wrote:

Hi,
after a few months of latop-only computing (my good old P4 1.8Ghz is now -
after 7 years - a Windows machine in our household), I plan to switch to a
normal computer again.

My requirements are the following:

   o Low power consumption (<  10W; 25W upper limit)
   o Support for major Free Software operating systems (no strange, custom
 GNU/Linux distributions), especially GNU/Linux or NetBSD
   o Fanless and no moving parts
   o No proprietary drivers, etc. (BIOS and bootloader acceptable)
   o Standard form-factor or custom case/enclosure (if so, hole for rp-sma
 connector)
   o Smallest form-factor that is possible (I don't understand why computers
 are still the size of a bottle crate)
   o Standard connectors (USB, VGA/DVI, Ethernet)
   o VESA mount (if possible)
   o low budget (<  500€)

After I found no RISC processors or SOCs, I looked at x86 CPUs. There three
low power architectures: VIA C7 and Nano, AMD Geode and Intel Atom.

VIA's technology (especially the C7) seems to be out-dated. VIA offers a
mini-itx board with its Nano CPU (VIA VB8001), but it has small fan and its
power consumption is slightly above the limit.

AMD's Geode is obsolete as well. The Geode LX family has the advantage of
low power consumption and small form factor. However, the performance per
watt ration is low.

Intel's Atom processors are modern and have probably the highest performance
per watt ration. However, the smallest affordable form-factor is mini-itx
(I talked to several companies that manufacture smaller industrial boards,
but the price performance ratio was terrible and buying one of those would
be my last option). Similar to the Nano most of the Atom Boards have a power
consumption that's a bit above 25W (there are the Z510 and Z530 embedded
Atom CPUs, but the come with the GMA 500 graphics chip which has no free
drivers). Nvidia's Ion, especially the Acer AspireRevo, seems to be quite
promising, but has proprietary drivers.

I wanted to ask you (because you very likely use your computers the same way
I do) whether you think the Geode is sufficient for the next three years or
so, otherwise would buy a cheap Atom mini-itx computer.

Usually I use my computer just for programming, typesetting (mainly
with groff and heirloom-doctools, but also occasionally with LaTeX),
reading and research. I don't need any computing power for simulations,
calculations, etc.; I can get access to bigger machines if I really have
such special tasks.

What bothers me a bit are these multimedia applications (video codecs,
etc.) and particularly web applications. I'm really not sure if the
Geode would be able to render on of these new JavaScript + HTML =
graphics-and-user-interface-API web apps in one and a half years or
so. Moreover, I can't imagine the CPU to decode a medium-sized h.264 videos
which seem to have become today's quasi-standard.

Maybe you know a better alternative.

Regards,
Matthias-Christian

   

Re: [dwm] dwm's future

[Kurt H Maier]

On Sun, Apr 26, 2009 at 6:57 AM, Haomin Wen  wrote:
> For programmers, there is little difference, or at least it generally will
> not increase SLOC.
Yes, but at the cost of dragging in a huge chain of libraries, which
is insanity.  Just because you can't see the complexity doesn't mean
it's not there.

> 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.

Not only can the user set these things, the user *has to*, because
otherwise his screen is an unreadable mess.

I may be be in the minority here, but ASCII works wonderfully, and I'm
happy with the state of font rendering in dwm.

# Kurt H Maier

Re: [dwm] dwm's future

[Haomin Wen]

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  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  wrote:
>
>> 2009/4/26 Szabolcs Nagy :
>> > On 4/25/09, Anselm R Garbe  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
>>
>>
>

Re: [dwm] dwm's future

[Haomin Wen]

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  wrote:

> 2009/4/26 Szabolcs Nagy :
> > On 4/25/09, Anselm R Garbe  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
>
>

Re: [dwm] dwm's future

[Anselm R Garbe]

2009/4/26 Szabolcs Nagy :
> On 4/25/09, Anselm R Garbe  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

Re: [dwm] dwm's future

[Anselm R Garbe]

Hi,

2009/4/26 Szabolcs Nagy :
> On 4/26/09, Christian Garbs  wrote:
>> On Sat, Apr 25, 2009 at 11:06:08PM +0100, Szabolcs Nagy wrote:
>>> On 4/25/09, Christian Garbs  wrote:
>>> > work, even without pango or cairo.  I have German umlauts as well as
>>> > Japanese characters (eg. web page titles from Firefox).
>>>
>>> try greek or cyrillic
>>> i had trouble with those when fonts were loaded with XCreateFontSet
>>
>> Looks ok to me:
>> https://www.cgarbs.de/tmp/dwm-ru.png
>
> no, that is ugly bold font, same problem with greek
>
>> Wrong font here?
>> https://www.cgarbs.de/tmp/dwm-ar.png
>
> most likely your font does not cover arabic fonts (iso8859-6) in the given 
> size
>
>> Korean does look broken, though:
>> https://www.cgarbs.de/tmp/dwm-ko.png
>
> yes, i get the same result using fixed-14

With the font spec:

"-*-*-medium-*-*-*-14-*-*-*-*-*-*-*"

I'm able to get proper results including Japanese, Chinese, Korean,
Greek, Russian, Hebrew, and Thai with that. Though not all of them are
monospaced (Gree and Russian for instance).

Arabic doesn't work for me if I'm not increasing the size to 17 or
above which is huge... and that's hard to be monospaced anyways.

I had a look into pango, well and I agree having such a dependency is
not very nice, pango is quite complex for what we need, cairo is bad
either for what we require. These achieve pseudo-monospace'ing through
scaling, which ends up in more or less equally bad results as using
plain X fonts, though perhaps looking a little bit smoother because
one doesn't need to declare large fonts.

So there are only three ways:

- stick with what we got (don't care if some langs look ugly)
- use pango and/or cairo or something like that
- invest some effort into a new font rendering lib (seems to be a hard
job, esp. if one asks for proper font support which can't be done by
us)

So I think, we stick to what we got after all. The bar stays at it is.

I agree there are more interesting problems.

Kind regards,
--Anselm