GNOME Bugzilla – Bug 786692
Wrong placement of application icon for control center
Last modified: 2017-10-06 08:57:04 UTC
Created attachment 358256 [details] Wrong placement of icon When the app menu is set to not appear in the top panel (via Tweak Tool), the application icon for the control center, which should bring up the app menu on click, is put at the wrong place, with an redundant word "Settings" shown at the top left-hand corner. The screenshot attached shows the wrong behaviour in control centre as well as an example of the expected behaviour.
Thanks for this! I agree that the current look isn't good. However, I think my preference would be to show the application menu to the right of the "Settings" heading, but still above the list, like: +----------------+---- | S Settings A | +----------------+---- S = search/back A = application menu This would communicate that the application menu belongs to the top level of the application, and not the panel. That said, I'm pretty sure that this is a GTK bug, since it's GTK that determines the fallback behaviour and not the control center.
Filed a separate bug report to GTK, and this is what I've got: bug786746
Created attachment 359014 [details] Redundant app menu The bigger annoyance than the wrong placement of icon is in fact the weird app menu just below the search button (circled in red)
This bug consists of two different issues: 1. The placement of the menu button at the wrong header bar; Because of the split header bar, we should handle the layout decorations by ourselves (as pointed out by Matthias in Bug 786746) 2. The menubar AND the menu button being visible at the same time. Seems like a Gtk+ bug. However, gnome-tweak-tool seems to arbitrarily disable the menubar entirely. This is ok if we expect the g-c-c users to always have client side decorations.
Created attachment 359023 [details] [review] window: Split the window decorations between the header bars When application menus are not supported by the desktop environment or are disabled, Gtk+ makes the menu available with a fallback. For client-side decorations the fallback consists of adding a menu button at the begining of the titlebar. Since g-c-c has a split headerbar, we need to explicitly handle the decoration layout. This commit forces the "menu" to belong to the left headerbar, and leaves the other buttons to ble placed at the right headerbar. The "show-close-button" property has to be set in order to present any type of decoration buttons in the header bar.
Created attachment 359024 [details] [review] window: Disable the menubar It looks better to present the fallback app menu in the headerbar instead. This change assumes that client side decorations will be available, and therefore a GtkHeaderBar.
(In reply to Allan Day from comment #1) > Thanks for this! I agree that the current look isn't good. However, I think > my preference would be to show the application menu to the right of the > "Settings" heading, but still above the list, like: > > +----------------+---- > | S Settings A | > +----------------+---- > > S = search/back > A = application menu > > > This would communicate that the application menu belongs to the top level of > the application, and not the panel. The standard seems to place the _application menu button_ at the leftmost position in the header bar even for split header bars. See gnome-tweak-tool, gnome-contacts, and other GNOME applications with split header bars. Regarding the menubar, that's something that the HIG doesn't seem to cover when used in parallel with split header bars. gnome-contacts, for instance, seems to have the weird behavior shown by OP in her/his screenshot attached above.
Created attachment 359031 [details] With the new patches With the two patches, the icon/app menu is moved to the left, but the weird "Settings" still appears under the header bar.
Created attachment 359055 [details] [review] window: Disable the menubar It looks better to present the fallback app menu in the headerbar instead. This change assumes that client side decorations will be available, and therefore a GtkHeaderBar.
The new patch works for me.
Review of attachment 359023 [details] [review]: Only a small nitpick. Should be committed after freeze (Settings already entered the Hard Code Freeze phase) ::: shell/cc-window.c @@ +727,3 @@ +{ + gchar *layout, *layout_start, *layout_end; + gchar **buttons; Could use g_autofree here.
Review of attachment 359055 [details] [review]: Makes sense.
Attachment 359023 [details] pushed as 357e944 - window: Split the window decorations between the header bars Attachment 359055 [details] pushed as cfbe34f - window: Disable the menubar
Pushed to gnome-3-26 Attachment 359023 [details] pushed as 04a96ed - window: Split the window decorations between the header bars Attachment 359055 [details] pushed as 01e3f9e - window: Disable the menubar
*** Bug 788566 has been marked as a duplicate of this bug. ***