smartgaps_fact on bar padding

[SalahDin Rezk]

Hello, I made code for smartgaps_fact on bar padding, I wanna submit it into this repo, should I make it a separate patch or integrate it into BAR_PADDING_VANITYGAPS_PATCH?

The code is as follows:

diff --git a/dwm.c b/dwm.c
index 543b721..5212468 100644
--- a/dwm.c
+++ b/dwm.c
@@ -2112,6 +2112,12 @@ focus(Client *c)
 		grabkeys();
 	}
 	#endif // ON_EMPTY_KEYS_PATCH
+	#if BAR_PADDING_VANITYGAPS_PATCH
+		updatebarpos(selmon);
+		for (Bar *bar = selmon->bar; bar; bar = bar->next)
+			XMoveResizeWindow(dpy, bar->win, bar->bx, bar->by, bar->bw, bar->bh);
+		arrange(selmon);
+	#endif // BAR_PADDING_VANITYGAPS_PATCH
 }
 
 /* there are some broken focus acquiring clients needing extra handling */
@@ -4664,8 +4670,15 @@ updatebarpos(Monitor *m)
 	if (enablegaps)
 	#endif // PERTAG_VANITYGAPS_PATCH
 	{
-		y_pad = gappoh;
-		x_pad = gappov;
+		unsigned int n; Client *c;
+		for (n = 0, c = nexttiled(m->clients); c; c = nexttiled(c->next), n++);
+		if (n > 1) {
+			y_pad = gappoh;
+			x_pad = gappov;
+		} else {
+			y_pad = gappoh * smartgaps_fact;
+			x_pad = gappov * smartgaps_fact;
+		}
 	}
 	#elif BAR_PADDING_PATCH
 	y_pad = vertpad;

[Stein Gunnar Bakkeby]

Based on the proposed code changes I take it that the general idea is that the bar padding should be disabled if there are one or less tiled clients.

The smartgaps_fact can be set to 0 to have no gaps when there is only one client. It can also be set to 3 to have exaggerated gaps when there is only one client.

As such you probably do not want to use smartgaps_fact here as it would seem odd / wrong to have the bar move more into the screen space when there is no clients or only one client.

The y_pad and x_pad variables are initialised as 0 so you wouldn't need that else statement to achieve this.

The main issue is that updatebarpos and arrange are called from the focus function, so if you have five client windows open and you change focus between them then you are going to call these functions every time the focus changes.

In most places where an arrange call is made there is also a focus call - which means that arrange would in general be called twice which is obviously a waste of effort.

If you think about it you only ever need to change the position of the bar if the number of tiled clients have changed - and every time the number of tiled clients change an arrange call is made. So I think that you could add the handling of that in the arrangemon function (the tab patch does something similar there).

It would need some testing I think because if arrange(NULL) is called then there won't be a call to restack, and without a call to restack there won't be a call to drawbar. Without the call to drawbar the bar window may resize but it won't be redrawn so it may be cut off or have some garbled graphics on the right hand side. More importantly the placement of the systray may not move.

Probably easiest to test this by disabling the status updater and to use the tagsync patch which calls arrange(NULL) a lot.

The fix for that would be to add an explicit call to drawbar.

Of course it would be more ideal to only go through updatebarpos if there is a need for it, but it would likely make the implementation more complicated.

As for your question I think having the bar change position based on how many clients are tiled is not something that would appeal to everyone, so I would want to add another toggle for this particular feature.