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 702338 - [GNOME Classic] long list of menu are lost under the bottom panel
[GNOME Classic] long list of menu are lost under the bottom panel
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-06-15 14:07 UTC by Bastián Díaz
Modified: 2013-06-26 11:38 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8


Attachments
Example of the problem on the bottom panel. (23.02 KB, image/png)
2013-06-15 14:07 UTC, Bastián Díaz
  Details
New example (388.46 KB, image/png)
2013-06-15 17:20 UTC, Bastián Díaz
  Details
windowList: Stack below the top_window_group (1.05 KB, patch)
2013-06-22 07:47 UTC, drago01
none Details | Review
layout: Keep the top_window group above newly added chrome (1.12 KB, patch)
2013-06-26 09:37 UTC, Florian Müllner
committed Details | Review

Description Bastián Díaz 2013-06-15 14:07:36 UTC
Created attachment 246893 [details]
Example of the problem on the bottom panel.

Description of problem:
* This is a problem that previously affected the top panel.
Sometimes it has a very long list menu (eg context menu) and this is lost below the bottom panel.

Version-Release number of selected component:
fedora 19 beta
GNOME 3.8.2
Comment 1 Matthias Clasen 2013-06-15 15:10:14 UTC
Florian, are we not adjusting the workarea for the window list ?
Comment 2 Florian Müllner 2013-06-15 16:47:43 UTC
We do, and popup menus now use a layer above shell chrome, so no idea offhand ...
Comment 3 Bastián Díaz 2013-06-15 17:20:55 UTC
Created attachment 246902 [details]
New example

No if a pattern completely, but it seems that this affects the GTK +2 applications as GTK +3 in same is not true (I have not tried QT applications).

Attached an image with other examples: Left "day" and right "GIMP".
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-06-15 19:36:41 UTC
The top window group is added directly to the uiGroup. If the bottom panel extension just adds itself to the uiGroup in enable(), it will be stacked on top of the top_window_group. Maybe we want to add the panel to the trayBox / panelBox, or a new box?
Comment 5 drago01 2013-06-22 07:47:31 UTC
Created attachment 247509 [details] [review]
windowList: Stack below the top_window_group

Otherwise menus (that are in top_window_group) will be stacked below it.

----

Why not just doing something like that?
Comment 6 Florian Müllner 2013-06-26 09:37:11 UTC
Created attachment 247804 [details] [review]
layout: Keep the top_window group above newly added chrome

The top_window_group was introduced for popup windows that should
appear above system chrome, but as the group itself is just a child
of Main.uiGroup, chrome that is added after top_window_group will
still be stacked on top.
At least correct the stacking for actors added via addChrome().


Alternative to the patch in comment #5, which moves the stack adjustment into addChrome() instead (e.g. one less detail extensions have to take care of themselves)
Comment 7 drago01 2013-06-26 11:20:20 UTC
Review of attachment 247804 [details] [review]:

This is indeed better.
Comment 8 Florian Müllner 2013-06-26 11:38:27 UTC
Attachment 247804 [details] pushed as 9786b2d - layout: Keep the top_window group above newly added chrome