>>>>> "CL" == Christoph Lohmann <2...@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.