>>>>> "CL" == Christoph Lohmann <20h_AT_r-36.net> 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
anyway).
...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