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.
Created attachment 5308 patch
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.
True, but we should mention this 'workaround' in the docs at least
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). See: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317566832 http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317564416 "All coordinates are root window coordinates." And http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317674416 "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.
This should be raised with gtk+
Pushed (with modification), thanks!
Downstream bug (Fedora 21 and EPEL7 with Xfce 4.10): https://bugzilla.redhat.com/show_bug.cgi?id=1093998
(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.