Bspwm does not update struts after dock application disappears

[patrick96]

I am maintaining polybar and have over time had many people mention that after polybar is killed, bspwm leaves a gap where the bar was. It looks to me that bspwm respects _NET_WM_STRUT_PARTIAL of the bar when it is started and adds a gap to the screen edge, but when the bar is stopped and the window disappears, the gap remains (even though no application is defining any struts anymore).

Is this intentional behavior?

Steps to reproduce

I have run my test in a Xephyr instance (Xephyr :1 -screen 400x300) with an empty bspwmrc. I'm using tint2 version 17.0.2 (just to show that this doesn't exclusively happen with polybar :wink:).

Fresh startup with only terminal running:

After starting tint2:

After killing (Ctrl-C) tint2:

As you can see the gap created for the tint2 struts remain and one has to run bspc config top_padding 0 to remove them.

For good measure, here is the xprop output for the tint2 bar:

WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified location: -992, -1
        program specified minimum size: 400 by 32
        program specified maximum size: 400 by 32
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 32, 0, 0, 0, 0, 0, 0, 399, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 32, 0
WM_CLASS(STRING) = "tint2", "Tint2"
XdndAware(ATOM) = ATOM
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: False
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK
_NET_WM_PID(CARDINAL) = 1318076
_NET_WM_ICON_NAME(UTF8_STRING) = "tint2"
_NET_WM_NAME(UTF8_STRING) = "tint2"
WM_ICON_NAME(STRING) = "tint2"
WM_NAME(STRING) = "tint2"

[Tectu]

bspwm + polybar user here: I am experiencing the same behavior.

[ATM-Jahid]

As far as I understand, bspwm changes padding values to deal with panels. The padding values are not changed back in case a panel is killed.

I was thinking about a few ways to deal with this:

• Storing the padding values of the state before the change. This approach assumes there is only one panel/dock present. It will not work for multiple panels/docks.
• Fetching the panel/dock dimensions before it's killed and changing padding values accordingly.

Another problem is the user-defined padding values. Let's imagine the following scenario.

1. User sets a padding value of 10 using bspc config left_padding 10.
2. The panel/dock changes the left padding value to 30.
3. User kills the panel/dock.

What should be the left padding value after the panel/dock is killed? 0 or 10? Trying to undo padding values gives rise to many such edge cases.