[SOLVED] St terminal window shrinks when zooming / dezooming

LithoUser · 2021-03-16 08:34:55

Hello,

You can zoom / dezoom in St using Ctrl+Shift+PgUp / PgDown, as defined in config.def.h:

{ TERMMOD,              XK_Prior,       zoom,           {.f = +1} },
{ TERMMOD,              XK_Next,        zoom,           {.f = -1} },

The problem is that each time I press those keybinds, the window size shrinks (even when I'm actually zooming), until it's only one line height and a few characters width. The only way I've found to keep the same window size while zooming or dezooming is to maximize it.

I've read that applying the anysize patch might help, so I've done it and recompiled; it has correctly been applied (since when the window is maximized, the text is now vertically centered, instead of being aligned at the top) but the same problem remains while (de)zooming.

Is there a way to avoid this? Or, at least, to increase the window size accordingly when zooming, instead of having it shrunk?

I hope I'm understandable (sorry for my poor english).

Thanx a lot for any help!

Last edited by LithoUser (2021-03-16 17:22:08)

seth · 2021-03-16 12:50:59

My money is on your WM trying to adapt to the changing increment size and being biased to the floor (integer division)

LithoUser · 2021-03-16 13:07:36

You're probably right; so it wouldn't be a bug in st (in fact, I was wondering whether it was the default behaviour); that's good to know, thanx!

That being said, I'm using Openbox as a WM (not XFCE, no desktop environment) : would anyone know if something can be done to avoid this problem (except from migrating to another WM, since I really love Openbox)?

Thanx for the help!

seth · 2021-03-16 14:49:11

I'd first run a cross-test (eg. w/ icewm)
The patch you linked should™ however prevent this kind of behavior. What's the output of "xwininfo -size" for that window?

LithoUser · 2021-03-16 16:30:26

OK, the cross-test was a good idea... but I encounter the same problem : I've launched st within icewm (the "anysize" patch is applied), but the window size still shrinks when zooming or dezooming. So maybe it's not (or not only) a WM problem, after all. However, I've also tested with i3, and everything is fine, but i3 being a tiling window manager, I assume it doesn't help much...

"xwininfo -size" gives the following:

xwininfo: Window id: 0x1a00005 "st"

  Normal window size hints:
      Program supplied size: 720 by 475
      Program supplied minimum size: 13 by 23
      Program supplied base size: 4 by 4
      Program supplied x resize increment: 9
      Program supplied y resize increment: 19
      Program supplied size in resize increments:  80 by 25
      Program supplied minimum size in resize increments: 1 by 1
      Program supplied base size in resize increments:  0 by 0
  No zoom window size hints defined

Thanx a lot, seth, for trying to provide some help!

seth · 2021-03-16 16:41:17

xwininfo wrote:

Program supplied x resize increment: 9
Program supplied y resize increment: 19

That does not suggest that the patch was applied, since it… wait a second: there're two patches there, only the first does

@@ -793,8 +797,8 @@ xhints(void)
 	sizeh->flags = PSize | PResizeInc | PBaseSize | PMinSize;
 	sizeh->height = win.h;
 	sizeh->width = win.w;
-	sizeh->height_inc = win.ch;
-	sizeh->width_inc = win.cw;
+	sizeh->height_inc = 1;
+	sizeh->width_inc = 1;
 	sizeh->base_height = 2 * borderpx;
 	sizeh->base_width = 2 * borderpx;
 	sizeh->min_height = win.ch + 2 * borderpx;

That being said: my st (October 2020, alpha and scrollback patch) doesn't do this at all on fluxbox but I can reproduce it on openbox (so it's gonna be the WM)

LithoUser · 2021-03-16 17:04:55

seth wrote:

wait a second: there're two patches there, only the first does

You're completely right! I forgot to mention this: since 2 versions of the patch exist on the "anysize" patch webpage, I've assumed that the one named "20201003" was more recent than the "0.8.1" one... but maybe I'm wrong?

So I've just tested the other one ("20201003"), and it works just fine! The problem is I've just installed st very recently, and I didn't know when the 0.8.1 version has been published... So, does anyone know if it's a regression? In which case I could warn the author (his mail is on the patch webpage).

Thanx, seth! I'll just wait in case someone can tell if I should contact the author, and then I'll mark this subject as [solved].

Edit: browsing the source code of st, it appears that version 0.8.1 has been published on 2018-03-20; so it does seem like a regression... I'll contact the author.

Edit 2: I'm really confused, since those two lines are in fact the only difference between the 2 patches... So there must have been a reason for removing them... but which one?

Last edited by LithoUser (2021-03-16 17:55:53)

seth · 2021-03-16 20:30:53

Bug? The entire thing won't make much sense unless the WM ignores the increment base.
Edit: in that case st would at least render the "dead" space.

Did you contact the patch author?

Last edited by seth (2021-03-16 20:32:14)

LithoUser · 2021-03-18 09:27:03

Yes, I have. Waiting for an answer.

augustob · 2021-03-18 11:27:02

Hey guys, I'm the original author of the patch, thanks LithoUser for letting me know about this thread!

The second version of the patch is not mine, and from LithoUser's email and your discussion here, I believe that that version's contributor tried to rebase to a later commit and simply forgot those two lines, as the patch makes little sense without them.

I have basically zero free time at the moment, so feel free to re-add the lines, rebase to whatever the latest commit is and submit the revised patch to suckless.org (via their website's git repo).

While I'm here, I have a couple bug reports that have been sitting in my inbox for years that you guys might be able to include in the updated version:

---
From Chris Rawnsley:

Just writing to say that I found a minor issue when you start st
with floating mode in dwm. I have found that it does not respect
the cols and rows that were set in config.h

A small change to the xinit function in x.c seems to fix it:

/* adjust fixed window geometry */
- win.w = 2 * borderpx + cols * win.cw;
- win.h = 2 * borderpx + rows * win.ch;
+ win.w = 2 * win.hborderpx + 2 * borderpx + cols * win.cw;
+ win.h = 2 * win.vborderpx + 2 * borderpx + rows * win.ch;

(I've added the 2 * borderpx back in compared to the original patch)

---
From mohkale:

In the line below you've used win.hborderpx when it should be vborderpx.
This is really only noticeable when using the alpha patch (with two alpha values). Having it enabled causes sections of the top and bottom
window border to not be cleared.

```
diff -u --label /home/mohkale/.dotfiles/prog/st/x.c --label \#\<buffer\ x.c\> /home/mohkale/.dotfiles/prog/st/x.c /tmp/buffer-content-9Kv8kX
--- /home/mohkale/.dotfiles/prog/st/x.c
+++ #<buffer x.c>
@@ -1628,7 +1628,7 @@
((winy + win.ch >= win.vborderpx + win.th)? win.h : (winy + win.ch)));
}
if (y == 0)
- xclear(winx, 0, winx + width, win.hborderpx);
+ xclear(winx, 0, winx + width, win.vborderpx);
if (winy + win.ch >= win.vborderpx + win.th)
xclear(winx, winy + win.ch, winx + width, win.h);
/* Fill the background */

Last edited by augustob (2021-03-18 11:28:26)

LithoUser · 2021-03-18 12:33:07

Thanx for taking the time for an answer, augustob!

I've incorporated your 2 fixes, and they seem to work fine; in fact, they even correct a little bug that I had encountered (using st with Openbox), where the borders (set as "borderpx" at the beginning of your config.h) were not taken into account for the window size (whereas they do were taken into account without the anysize patch). Great!

augustob wrote:

feel free to re-add the lines, rebase to whatever the latest commit is and submit the revised patch to suckless.org (via their website's git repo).

I'd be glad to help, but that seems to be way above my skills. However, I'll try my best; I'm going to look for some info about how to do it, and I'll report it here if I succeed. If anyone has some ELI5 explanations that I could read, that could certainly help (I found https://suckless.org/hacking/ of course, but it seems complicated for me; my main problem is I only know very little about git). Thanx!

Edit: I think I've managed to do it (without using git). Could anyone review it before I try to submit it to the suckless.org website? Thanx!

Here it is: that would be st-anysize-0.8.4.diff, I guess:

--- a/x.c	2021-03-18 13:51:55.352081831 +0100
+++ b/x.c	2021-03-18 13:47:38.052078273 +0100
@@ -81,6 +81,7 @@ typedef XftGlyphFontSpec GlyphFontSpec;
 typedef struct {
 	int tw, th; /* tty width and height */
 	int w, h; /* window width and height */
+	int hborderpx, vborderpx;
 	int ch; /* char height */
 	int cw; /* char width  */
 	int mode; /* window state/mode flags */
@@ -331,7 +332,7 @@ ttysend(const Arg *arg)
 int
 evcol(XEvent *e)
 {
-	int x = e->xbutton.x - borderpx;
+	int x = e->xbutton.x - win.hborderpx;
 	LIMIT(x, 0, win.tw - 1);
 	return x / win.cw;
 }
@@ -339,7 +340,7 @@ evcol(XEvent *e)
 int
 evrow(XEvent *e)
 {
-	int y = e->xbutton.y - borderpx;
+	int y = e->xbutton.y - win.vborderpx;
 	LIMIT(y, 0, win.th - 1);
 	return y / win.ch;
 }
@@ -721,6 +722,9 @@ cresize(int width, int height)
 	col = MAX(1, col);
 	row = MAX(1, row);
 
+	win.hborderpx = (win.w - col * win.cw) / 2;
+	win.vborderpx = (win.h - row * win.ch) / 2;
+
 	tresize(col, row);
 	xresize(col, row);
 	ttyresize(win.tw, win.th);
@@ -838,8 +842,8 @@ xhints(void)
 	sizeh->flags = PSize | PResizeInc | PBaseSize | PMinSize;
 	sizeh->height = win.h;
 	sizeh->width = win.w;
-	sizeh->height_inc = win.ch;
-	sizeh->width_inc = win.cw;
+	sizeh->height_inc = 1;
+	sizeh->width_inc = 1;
 	sizeh->base_height = 2 * borderpx;
 	sizeh->base_width = 2 * borderpx;
 	sizeh->min_height = win.ch + 2 * borderpx;
@@ -1121,8 +1125,8 @@ xinit(int cols, int rows)
 	xloadcols();
 
 	/* adjust fixed window geometry */
-	win.w = 2 * borderpx + cols * win.cw;
-	win.h = 2 * borderpx + rows * win.ch;
+	win.w = 2 * win.hborderpx + 2 * borderpx + cols * win.cw;
+	win.h = 2 * win.vborderpx + 2 * borderpx + rows * win.ch;
 	if (xw.gm & XNegative)
 		xw.l += DisplayWidth(xw.dpy, xw.scr) - win.w - 2;
 	if (xw.gm & YNegative)
@@ -1211,7 +1215,7 @@ xinit(int cols, int rows)
 int
 xmakeglyphfontspecs(XftGlyphFontSpec *specs, const Glyph *glyphs, int len, int x, int y)
 {
-	float winx = borderpx + x * win.cw, winy = borderpx + y * win.ch, xp, yp;
+	float winx = win.hborderpx + x * win.cw, winy = win.vborderpx + y * win.ch, xp, yp;
 	ushort mode, prevmode = USHRT_MAX;
 	Font *font = &dc.font;
 	int frcflags = FRC_NORMAL;
@@ -1344,7 +1348,7 @@ void
 xdrawglyphfontspecs(const XftGlyphFontSpec *specs, Glyph base, int len, int x, int y)
 {
 	int charlen = len * ((base.mode & ATTR_WIDE) ? 2 : 1);
-	int winx = borderpx + x * win.cw, winy = borderpx + y * win.ch,
+	int winx = win.hborderpx + x * win.cw, winy = win.vborderpx + y * win.ch,
 	    width = charlen * win.cw;
 	Color *fg, *bg, *temp, revfg, revbg, truefg, truebg;
 	XRenderColor colfg, colbg;
@@ -1430,17 +1434,17 @@ xdrawglyphfontspecs(const XftGlyphFontSp
 
 	/* Intelligent cleaning up of the borders. */
 	if (x == 0) {
-		xclear(0, (y == 0)? 0 : winy, borderpx,
+		xclear(0, (y == 0)? 0 : winy, win.vborderpx,
 			winy + win.ch +
-			((winy + win.ch >= borderpx + win.th)? win.h : 0));
+			((winy + win.ch >= win.vborderpx + win.th)? win.h : 0));
 	}
-	if (winx + width >= borderpx + win.tw) {
+	if (winx + width >= win.hborderpx + win.tw) {
 		xclear(winx + width, (y == 0)? 0 : winy, win.w,
-			((winy + win.ch >= borderpx + win.th)? win.h : (winy + win.ch)));
+			((winy + win.ch >= win.vborderpx + win.th)? win.h : (winy + win.ch)));
 	}
 	if (y == 0)
-		xclear(winx, 0, winx + width, borderpx);
-	if (winy + win.ch >= borderpx + win.th)
+		xclear(winx, 0, winx + width, win.vborderpx);
+	if (winy + win.ch >= win.vborderpx + win.th)
 		xclear(winx, winy + win.ch, winx + width, win.h);
 
 	/* Clean up the region we want to draw to. */
@@ -1534,35 +1538,35 @@ xdrawcursor(int cx, int cy, Glyph g, int
 		case 3: /* Blinking Underline */
 		case 4: /* Steady Underline */
 			XftDrawRect(xw.draw, &drawcol,
-					borderpx + cx * win.cw,
-					borderpx + (cy + 1) * win.ch - \
+					win.hborderpx + cx * win.cw,
+					win.vborderpx + (cy + 1) * win.ch - \
 						cursorthickness,
 					win.cw, cursorthickness);
 			break;
 		case 5: /* Blinking bar */
 		case 6: /* Steady bar */
 			XftDrawRect(xw.draw, &drawcol,
-					borderpx + cx * win.cw,
-					borderpx + cy * win.ch,
+					win.hborderpx + cx * win.cw,
+					win.vborderpx + cy * win.ch,
 					cursorthickness, win.ch);
 			break;
 		}
 	} else {
 		XftDrawRect(xw.draw, &drawcol,
-				borderpx + cx * win.cw,
-				borderpx + cy * win.ch,
+				win.hborderpx + cx * win.cw,
+				win.vborderpx + cy * win.ch,
 				win.cw - 1, 1);
 		XftDrawRect(xw.draw, &drawcol,
-				borderpx + cx * win.cw,
-				borderpx + cy * win.ch,
+				win.hborderpx + cx * win.cw,
+				win.vborderpx + cy * win.ch,
 				1, win.ch - 1);
 		XftDrawRect(xw.draw, &drawcol,
-				borderpx + (cx + 1) * win.cw - 1,
-				borderpx + cy * win.ch,
+				win.hborderpx + (cx + 1) * win.cw - 1,
+				win.vborderpx + cy * win.ch,
 				1, win.ch - 1);
 		XftDrawRect(xw.draw, &drawcol,
-				borderpx + cx * win.cw,
-				borderpx + (cy + 1) * win.ch - 1,
+				win.hborderpx + cx * win.cw,
+				win.vborderpx + (cy + 1) * win.ch - 1,
 				win.cw, 1);
 	}
 }

Last edited by LithoUser (2021-03-18 17:16:38)

LithoUser · 2021-03-18 17:23:05

I've had a chance to test the new patch on another computer, and it seems to work fine. Now I should submit it to the suckless website, but I'm stuck here:

augustob wrote:

submit the revised patch to suckless.org (via their website's git repo)

I would really need some explanations here, as I don't know anything about using git: could anyone help me for this part?

Edit: the way I see it, it would be something like this:

1. git clone https://git.suckless.org/st/
2. cd st/
3. create a directory for the patch? Not sure about this
4. git commit -m "anysize: fix regression in st-anysize-20201003-407a3d0.diff + st doesn't respect the cols and rows set in config.h (thanx Chris Rawnsley) + win.hborderpx should be win.vborderpx (thanx mohkale)"
5. git push origin/master

Am I right?

Last edited by LithoUser (2021-03-18 18:35:26)

seth · 2021-03-19 08:56:10

You're unlikely going to be able to push to the mainline repos.
See https://suckless.org/wiki/ for user patches (basically you edit the wiki)

LithoUser · 2021-03-19 11:30:58

OK, it's actually easier that I thought.

I've edited the wiki locally, but before pushing my commit, I'd like an advice about my patch: all the patches begin with:

diff --git a/x.c b/x.c

whereas mine begins with:

--- a/x.c	2021-03-18 13:51:55.352081831 +0100
+++ b/x.c	2021-03-18 13:47:38.052078273 +0100

Furthermore, nothing is displayed when I apply my patch, whereas usually the changes are displayed on the screen when I apply a patch.
I've tried "diff --git a/x.c b/x.c" instead of "diff a/x.c b/x.c", but got the following error:

diff: unknown option "--diff"

So, here is my question: is my patch wrong or not? It doesn't seem to comply with the usual requirements... Sorry for all these questions, and thanx in advance for any help!

seth · 2021-03-19 12:47:12

The headers come from git diff, ie. you fetch the st sources via git, edit/patch them and then run "git diff" to display the uncommited changes.
There's also gonna be an index, eg.

the original patch wrote:

diff --git a/x.c b/x.c
index 00cb6b1..8f87c0f 100644
--- a/x.c
+++ b/x.c

LithoUser · 2021-03-19 13:32:25

Done, but God that was hard!

vim (used by git diff) didn't want to exit insert mode with my usual Esc key after providing the commit message; I've had to use Ctrl-C. Then I didn't know if I had to go to the root of the wiki (the sites/ folder) or if I could push directly from the "anysize" folder (that's what I've done, hope I was right).

seth, thanx very much for your help! I wouldn't have (half-)succeeded without it.

If the patch isn't published in the next few days/weeks, I'll come back here and call for some help again.

Edit: I was about to desperate, but... it's done ! The patch is now online.

Last edited by LithoUser (2021-03-28 17:59:58)

Arch Linux

#1 2021-03-16 08:34:55

[SOLVED] St terminal window shrinks when zooming / dezooming

#2 2021-03-16 12:50:59

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#3 2021-03-16 13:07:36

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#4 2021-03-16 14:49:11

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#5 2021-03-16 16:30:26

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#6 2021-03-16 16:41:17

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#7 2021-03-16 17:04:55

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#8 2021-03-16 20:30:53

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#9 2021-03-18 09:27:03

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#10 2021-03-18 11:27:02

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#11 2021-03-18 12:33:07

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#12 2021-03-18 17:23:05

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#13 2021-03-19 08:56:10

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#14 2021-03-19 11:30:58

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#15 2021-03-19 12:47:12

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

#16 2021-03-19 13:32:25

Re: [SOLVED] St terminal window shrinks when zooming / dezooming

Board footer