gnomeConfig avoidStruts doesn't work with classic gnome-panel

[medwards]

After going from Ubuntu 16 to 18 my windows started covering up the gnome panel and status bar. I was able to fix this by configuring ManageDocks (in the attached config I changed lines are 7 and 66). This makes me think it might be related to xmonad/xmonad#79, #194, or #215 but I'm not entirely sure.

Seems like XMonad.Config.Gnome should probably be updated either way.

My current config is at https://pastebin.ca/4031349 and is based on some config I found on the xmonad wiki ages ago.

[slotThe]

The desktopConfig sets the correct docks combinator, so I think it should be fine? What exactly did you change? (the pastebin is offline; that's what you get for not getting to issues until 3 years later :>)

[medwards]

I've attached it here: xmonad.hs.txt

I have spent a lot of additional time on this issue:
See this reddit thread where I think I'm nailing down the issue: https://www.reddit.com/r/xmonad/comments/mk645m/avoidstruts_ignoring_gnomepanel/

On my desktop PC the struts are avoided as expected, but on every laptop I've installed this setup on it ends up ignoring the dock and being over top. I suspect there is something about laptop displays that is causing the X window properties to be incorrect, but I don't know what else to look at.

I describe my setup (and some motivation to head off "why don't you do a different setup" questions) here and workarounds necessary for Ubuntu here: https://gist.github.com/medwards/a36eda6daedaa469050057bd810d83dc

[slotThe]

I describe my setup (and some motivation to head off "why don't you do a different setup" questions) here and workarounds necessary for Ubuntu here: https://gist.github.com/medwards/a36eda6daedaa469050057bd810d83dc

This looks very nice! Would you perhaps be interested to contribute this to e.g. the website? We are slowly working towards replacing the wiki with an up-to-date and self-contained website instead.

[medwards]

@slotThe just checking in: You don't have any ideas for further information I could provide to narrow the bug down?

[slotThe]

@slotThe just checking in: You don't have any ideas for further information I could provide to narrow the bug down?

Are you perhaps using two monitors whenever you are observing this bug? I don't think I've ever looked into how X11 handles struts, so my knowledge there is spotty at best (@liskin and @geekosaur are much more knowledgable here), but I just installed gnome-panel from my distributions package repositories and here's what I noticed.

When executed, two bars are visible on the screen and when only using a single monitor everything works fine. However, when I, say, connect a second monitor on top of the main one, the top bar will stop being respected. There is a curious change in the _NET_WM_STRUT_PARTIAL_ property of the top bar here:

• single monitor: _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 0, 1365, 0, 0
• two monitors: _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 1365, 0, 0

The second one says that the height of the bar is zero! It is thus rightfully ignored in the getStrut function. Curiously, the panel seems to define its own property which seems to have the required info available:

• _GNOME_WM_STRUT_AREA(CARDINAL) = 0, 1080, 1366, 24

This seems to be in violation of the EWMH spec (as I understand it):

The start and end values associated with each strut allow areas to be reserved which do not span the entire width or height of the screen. Struts MUST be specified in root window coordinates, that is, they are not relative to the edges of any view port or Xinerama monitor.

Another example is a panel on a screen using the Xinerama extension. Assume that the set up uses two monitors, one running at 1280x1024 and the other to the right running at 1024x768, with the top edge of the two physical displays aligned. If the panel wants to fill the entire bottom edge of the smaller display with a panel 50 pixels tall, it should set a bottom strut of 306, with bottom_start_x of 1280, and bottom_end_x of 2303. Note that the strut is relative to the screen edge, and not the edge of the xinerama monitor.

[liskin]

Oh, this looks like some new development: https://mail.gnome.org/archives/wm-spec-list/2018-December/msg00000.html, https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/22, https://muktupavels.id.lv/posts/better-multi-monitor-support-in-gnome-flashback

Seems like those discussions I had on wm-spec list around 2009 went nowhere and someone implemented a different thing in 2020. :-D

We might need to implement support for _GNOME_WM_STRUT_AREA in X.H.ManageDocks.

[muktupavels]

I checked with Ubuntu 16.04 in VM and _NET_WM_STRUT_PARTIAL values looks similar to what @slotThe posted. So something else has changed when you upgraded from 16 to 18, gnome-panel sets same values.

[slotThe]

I checked with Ubuntu 16.04 in VM and _NET_WM_STRUT_PARTIAL values looks similar to what @slotThe posted.

Similar to which of the two values? The second one could have never worked because we explicitly filter out struts that have height zero. I don't exactly know how the issue in the OP relates to what this has become, perhaps @medwards is talking about something else entirely.

I'm still surprised that gnome-panel does not set the correct _NET_WM_STRUT_PARTIAL even though it sets them in _GNOME_WM_STRUT_AREA. Using the values from my previous comment, something like

`_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 1080, 0, 0, 0, 0, 0, 0, 1365, 0, 0`

does indeed seem like the right value, given the height of the panel (xmobar sets 1095 and is a lot slimmer, for example).

We might need to implement support for _GNOME_WM_STRUT_AREA in X.H.ManageDocks.

Perhaps we do (reading the commits it seems like they can do "more" than _NET_WM_STRUT_PARTIAL), but at least for this issue it should be fine if we simply got the actual values.

[muktupavels]

I checked with Ubuntu 16.04 in VM and _NET_WM_STRUT_PARTIAL values looks similar to what @slotThe posted.

Similar to which of the two values? The second one could have never worked because we explicitly filter out struts that have height zero. I don't exactly know how the issue in the OP relates to what this has become, perhaps @medwards is talking about something else entirely.

Both. First value looks like is without top monitor. Second is with top monitor. This has not changed in gnome-panel.

I'm still surprised that gnome-panel does not set the correct _NET_WM_STRUT_PARTIAL even though it sets them in _GNOME_WM_STRUT_AREA. Using the values from my previous comment, something like

`_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 1080, 0, 0, 0, 0, 0, 0, 1365, 0, 0`

I don't know why it was decided to set strut size to 0 in such cases. This definitely has not changed recently! It is unlikely that I will change this especially that _GNOME_WM_STRUT_AREA provides correct info and does not require any workarounds.

does indeed seem like the right value, given the height of the panel (xmobar sets 1095 and is a lot slimmer, for example).

We might need to implement support for _GNOME_WM_STRUT_AREA in X.H.ManageDocks.

Perhaps we do (reading the commits it seems like they can do "more" than _NET_WM_STRUT_PARTIAL), but at least for this issue it should be fine if we simply got the actual values.

Providing actual values could cause regressions for someone else.

[slotThe]

I don't know why it was decided to set strut size to 0 in such cases. This definitely has not changed recently!

Oh interesting. Then maybe the issue I found is not what the issue was in the original OP; thanks for clearing that up! Still I think it's worth discussing.

It is unlikely that I will change this especially that _GNOME_WM_STRUT_AREA provides correct info and does not require any workarounds.
[...]
Providing actual values could cause regressions for someone else.

That sounds like an argument against fixing bugs in general :P I think that relying on incorrect (not even undefined, EMWH is quite clear what _NET_WM_STRUT_PARTIAL should contain) behaviour is just asking for trouble and people actively doing this surely know it.

[medwards]

TLDR: multi-monitor doesn't seem to be a culprit on my setup. Strut values appear to be consistent across both working and buggy computers.

All values were derived using xprop and clicking on the upper Gnome panel.

Ubuntu 20.04 laptop - doesn't work, solo, plugged into a dock with both screens, plugged into a dock with the laptop closed:
Using dock monitor

GNOME_WM_STRUT_AREA(CARDINAL) = 0, 0, 2560, 24
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 0, 2559, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 24, 0

Using laptop alone:

_GNOME_WM_STRUT_AREA(CARDINAL) = 0, 0, 1920, 24
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 0, 1919, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 24, 0

This is contrasted with two other computers
(working) Ubuntu 20.04 on a desktop - two monitors on different video cards (PCI-E + onboard):

_GNOME_WM_STRUT_AREA(CARDINAL) = 0, 0, 2560, 24
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 0, 2559, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 24, 0

(working) Ubuntu 19.04 on a laptop:

_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 0, 1919, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 24, 0

[muktupavels]

That sounds like an argument against fixing bugs in general :P I think that relying on incorrect (not even undefined, EMWH is quite clear what _NET_WM_STRUT_PARTIAL should contain) behaviour is just asking for trouble and people actively doing this surely know it.

Again, I don't know why it is set to 0. Perhaps someone decided it is better then adding workarounds in window managers...

Anyway, I don't plan to spend time to find reason why it was done this way (I just don't have time for this, sorry). I will review merge request that changes this if it will contain info why it was done this way and why it is better to not do that. I don't care about old struts as GNOME Flashback supported window managers use new property. And I will revert such change if someone will report issue / regression with other window manager.

TLDR: multi-monitor doesn't seem to be a culprit on my setup. Strut values appear to be consistent across both working and buggy computers.

Values looks correct for top panel... Some configuration problem then (if in both cases you use 20.04, one works, other does not)?

[medwards]

if in both cases you use 20.04, one works, other does not

Correct. If this is a configuration problem but my xmonad.hs is the same, what am I looking for then? Some sort of difference in GnomeConfig? I don't think it has been changed in a very long time.