After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 730527 - Some qt application menu not displayed with two monitor tiled vertically
Some qt application menu not displayed with two monitor tiled vertically
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-05-21 15:11 UTC by xgdgsc
Modified: 2014-06-12 13:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
boxes: Ignore struts that don't attach to the side they claim (2.62 KB, patch)
2014-06-12 07:37 UTC, Florian Müllner
committed Details | Review
testboxes: Update test cases (4.78 KB, patch)
2014-06-12 07:37 UTC, Florian Müllner
committed Details | Review
workspace: Extend builtin struts to screen edge when possible (2.67 KB, patch)
2014-06-12 07:37 UTC, Florian Müllner
committed Details | Review
layout: Do not expand struts to screen edges (2.64 KB, patch)
2014-06-12 07:43 UTC, Florian Müllner
committed Details | Review

Description xgdgsc 2014-05-21 15:11:34 UTC
This one is very strange. I have two monitors both 1920*1080 tiled vertically (both physically and in gnome settings). The lower one is the one with gnome panel. When Lyx or Rstudio (these two are both qt4 apps) window is in the lower one, when I click menu like "File", "Edit" , the menus are not shown at all , while accessible with keyboard shortcut (such as 'x' to exit in "File"). 

When I drag them to the upper one, and click again, the menus are shown properly. If I set the external monitor to the left or right (instead of above) of the laptop screen in the display settings , the menus are displayed properly wherever I put the windows of Lyx and Rstudio. I currently only experience this with the two apps.

I don' t experience this with KDE with these two apps. So I suspect it is a gnome bug. Sorry if I selected the wrong component.

the system is archlinux, gnome-shell 3.12.2. Lyx 2.1.0 and Rstudio 0.98.501. qt4 4.8.6,
Comment 1 xgdgsc 2014-06-02 08:05:15 UTC
I found recently that transmission-qt and virtualbox also has this problem, making gnome-shell awful for use.
Comment 2 xgdgsc 2014-06-03 12:24:51 UTC
And mendeley also.
Comment 3 Florian Müllner 2014-06-12 07:37:24 UTC
Created attachment 278313 [details] [review]
boxes: Ignore struts that don't attach to the side they claim

Like the _NET_WM_STRUT/_NET_WM_STRUT_PARTIAL client properties,
_NET_WORKAREA is defined in terms of screen geometry rather than
taking individual monitors into account. However we do want to
allow system chrome to be attached to a monitor edge rather than
a screen edges under some circumstances. As not all clients can
be assumed to deal gracefully with the resulting workarea, use
those "struts" only internally for constraining windows, but
ignore them when exporting _NET_WORKAREA.
Comment 4 Florian Müllner 2014-06-12 07:37:32 UTC
Created attachment 278314 [details] [review]
testboxes: Update test cases

Who cares? We do now ...
Comment 5 Florian Müllner 2014-06-12 07:37:55 UTC
Created attachment 278315 [details] [review]
workspace: Extend builtin struts to screen edge when possible

Struts are defined in terms of screen edges, so expand the rectangles
we get via set_builtin_struts() accordingly. However we do want to
allow chrome on edges between monitors, in which case the expansion
would render an entire monitor unusable - don't expand the rectangles
in that case, which means we will only use them for constraining
windows but ignore them for the client-visible _NET_WORKAREA property.
Comment 6 Florian Müllner 2014-06-12 07:43:07 UTC
Created attachment 278317 [details] [review]
layout: Do not expand struts to screen edges

set_builtin_struts() in mutter now handles this for us, so we can kill
off the extra code here.
Comment 7 Rui Matos 2014-06-12 12:46:00 UTC
Review of attachment 278317 [details] [review]:

ok
Comment 8 Rui Matos 2014-06-12 12:46:28 UTC
Review of attachment 278315 [details] [review]:

ok

::: src/core/workspace.c
@@ +1086,3 @@
+    }
+
+  if (strut_lists_equal (struts, workspace->builtin_struts))

I'd just do this once here and remove the check above but no biggie.
Comment 9 Rui Matos 2014-06-12 12:46:41 UTC
Review of attachment 278314 [details] [review]:

right
Comment 10 Rui Matos 2014-06-12 12:47:17 UTC
Review of attachment 278313 [details] [review]:

looks fine

::: src/core/boxes.c
@@ +549,3 @@
+/* ... and another helper for get_minimal_spanning_set_for_region()... */
+static gboolean
+check_strut_align (MetaStrut *strut, const MetaRectangle *rect)

strut_is_at_the_edge() ? I like descriptive names but can't think of anything good here.
Comment 11 Florian Müllner 2014-06-12 13:36:27 UTC
Attachment 278313 [details] pushed as 906cbee - boxes: Ignore struts that don't attach to the side they claim
Attachment 278314 [details] pushed as f3d7c9c - testboxes: Update test cases
Attachment 278315 [details] pushed as a735047 - workspace: Extend builtin struts to screen edge when possible

(In reply to comment #8)
> +  if (strut_lists_equal (struts, workspace->builtin_struts))
> 
> I'd just do this once here and remove the check above but no biggie.

The idea is to not do the padding checks again if the passed-in struts are already good, but then I didn't measure at all whether the checks are actually more expensive than the strut_list_equal() one ... so yeah, looks redundant and shouldn't make a difference at least in the most common cases (1-2 monitors, 1 strut).
Comment 12 Florian Müllner 2014-06-12 13:37:12 UTC
Attachment 278317 [details] pushed as 5859301 - layout: Do not expand struts to screen edges