Re: [dev] [st PATCH] X geometry changes

From: Yuri Karaban <>
Date: Sat, 26 Apr 2014 00:37:41 +0300

>>>>> "CL" == Christoph Lohmann <> writes:

    CL>> Suckless is writing software for dwm. A specified geometry is
    CL>> fixed. Otherwise st is not floating by default when forcing a
    CL>> size.

If st was designed only to support tiling window managers then I guess I
made a wrong choice. When I first saw st, I was excited that I found a
terminal emulator without superfluous functions (which I don't use

...But it turned out that my beliefs about what is superfluous are
diverging from suckless ideology ;-)

    CL>> Then fix xwininfo and X11 to include both hints. Interpreting
    CL>> given arguments in different ways based on a subjective valuing
    CL>> of applications is wrong in all senses.

I didn't say that's something wrong with them. They was provided as
arguments in support of such behavior.

It's the standard way to specify geometry. If I want to open terminal
window with exactly 80 (120, 160, etc.) columns, what should I do?

Should I run st session just for inspection, check hints with xprop(1),
take calculator, multiply desired columns by increment hint, don't
forget about adding borders. And just after all these steps I can
specify geometry.

    CL>> The pixel specification is needed in the tiling world, to have
    CL>> a correct positioning. Here X11 is doing it wrong. Don’t
    CL>> overlap windows. St is written to only take the parts it can
    CL>> really use.

What's wrong with positioning. Window offsets in X geometry are always
in pixels.

Regarding dimensions, I don't understand what benefits are gained if
specified dimensions are not multiple of glyph size. In one case you
will have unused space inside terminal, in other you will have a gap
between windows, but in both cases space would be wasted.

    CL>> Another note is, that you are not using the st style in your
    CL>> patch. Especially in the switch and if statement. This won’t be
    CL>> included.

Do you mean a space between keyword and parenthesis and inline
statements in switch? But probably nevermind, if my patch won't be
accepted, what is the sense to fix a style.

    CL>> X11 is the enemy, introduced mass dynamic linking and
    CL>> inconsistencies like you mentioned. I won’t include this.

You don't like X11, but you deliberately choose X11 for your
application, and you deliberately choose legacy Xlib. Isn't it
irrational? ;-)

If you don't like X11 that much, maybe it worth to take a closer look on
Wayland and other alternatives, or at least consider xcb, it was
designed to address Xlib shortcomings.

Neque ignorare [medicum] oportet quae sit aegri natura.
Received on Fri Apr 25 2014 - 23:37:41 CEST

This archive was generated by hypermail 2.3.0 : Fri Apr 25 2014 - 23:48:06 CEST