! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Gtk3 menus are constrained by struts from all monitors.


Description Alistair Buxton 2014-01-12 18:13:56 CET
Created attachment 5307 
screenshot showing the bug

This is tricky to explain, so have a look at the attached image.

Gtk3 menus are constrained by the screen workarea. This is per screen, not per monitor, and therefore it cannot handle L-shaped displays like mine.

Gdk3 has a workaround for this - it will ignore the workarea on all but the primary screens. In my setup the left monitor is the primary and so the workarea is used.

But this presents a problem due to the way xfwm4 calculates workarea. It considers every panel from all monitors, and so no menu on my first monitor can ever be higher than the panel on my second monitor.

As a workaround for this, I propose when setting the NET_WORKAREA atom, to ignore any struts which don't intersect the primary display. I have a patch which implements this.
Comment 1 Alistair Buxton 2014-01-12 18:14:45 CET
Created attachment 5308 
Comment 2 Alistair Buxton 2014-07-03 21:14:03 CEST
I just noticed that this bug has a really trivial workaround: just set "Don't reserve space on borders" on the problematic panels, and it won't set any struts. As such it might not be worth fixing this, since it makes the code quite a bit more complex.
Comment 3 Nick Schermer editbugs 2014-07-28 11:56:17 CEST
True, but we should mention this 'workaround' in the docs at least
Comment 4 Olivier Fourdan editbugs 2015-01-08 16:45:06 CET
Computation of the workarea looks correct, it takes struts and partial struts from all monitors.

The workarea is computed for the entire screen (i.e. including all monitors) and struts are relative to the screen (not monitor).



"All coordinates are root window coordinates."



"The Window Manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL properties set on client windows."

Which is exactly what xfwm4 does.

The only thing is GNOME doesn't place docks on anything but the main monitor, but if you try the same setup in mutter by running xfce4-panel the results is identical or even worse than with xfwm4.

So this is not a bug in xfwm4, I see no point in adding complexity when the computation is correct.
Comment 5 Olivier Fourdan editbugs 2015-01-08 16:46:16 CET
This should be raised with gtk+
Comment 6 Olivier Fourdan editbugs 2015-01-08 21:47:27 CET
Pushed (with modification), thanks!
Comment 7 Raphael Groner 2015-08-21 20:29:30 CEST
Downstream bug (Fedora 21 and EPEL7 with Xfce 4.10): 
Comment 8 Olivier Fourdan editbugs 2015-08-21 20:54:19 CEST
(In reply to Raphael Groner from comment #7)
> Downstream bug (Fedora 21 and EPEL7 with Xfce 4.10): 
> https://bugzilla.redhat.com/show_bug.cgi?id=1093998

This looks completely unrelated to this bug, xfwm4 does not set xrandr resolutions, xfsettings does.

Bug #10625

Reported by:
Alistair Buxton
Reported on: 2014-01-12
Last modified on: 2015-08-21


Olivier Fourdan
CC List:
2 users




screenshot showing the bug (641.22 KB, image/png)
2014-01-12 18:13 CET , Alistair Buxton
no flags
patch (3.48 KB, patch)
2014-01-12 18:14 CET , Alistair Buxton
no flags

Additional information