GNOME Bugzilla – Bug 745919
Classic mode: app menu is odd in the top panel
Last modified: 2021-07-05 14:39:06 UTC
In classic mode, the app menu follows the applications and places menus. This always struck me as being a bit odd, since it places the dynamic application-specific menu directly alongside two static system menus. One alternative could be to use GTK+'s fallback app menus, so the app menu is shown inside header bars rather than in the panel.
(In reply to Allan Day from comment #0) > One alternative could be to use GTK+'s fallback app menus, so the app menu > is shown inside header bars rather than in the panel. That part would need to be implemented in gnome-settings-daemon/gtk+, all we can do in the shell is hide the app menu (which obviously does not make sense before we got the other part).
Why classic mode would be different in this respect though? In normal mode the application menu is next to a static system button and it is followed at short distance by another system menu.
(In reply to Giovanni Campagna from comment #2) > Why classic mode would be different in this respect though? ... Two possible reasons I can think of: (a) There are two permanent system items in classic mode, which outweigh the single app item and make it feel like it doesn't belong. (b) Activities is a button, not a menu - the oddness in classic comes from the fact that app menu is similar to the applications and places menus, and yet it is a bit different, and that makes it feels awkward.
Created attachment 299003 [details] [review] panel: Hide app menu when disabled by settings For what it's worth, I'm not convinced that further increasing the differences between normal and classic session is a great idea unless absolutely necessary - unless we seriously shift priorities from the normal session, there'll always be better "traditional" options around than gnome-classic. However for what it does - easing the GNOME 3 transition by a more familiar interface - it's doing an OK job already. Sure, there's stuff like this that makes it a bit more OK, but we end up with more differences, which means more bugs, which means less time to work on other areas ... In any case, attached patch is all we would do on the gnome-shell side, after that it's up to gsd/gtk+ to make sure the setting has a different default value when running in the classic session.
Created attachment 299043 [details] [review] xsettings: Set Gtk/ShellShowsAppMenu only if the shell is in user mode -- Here's the g-s-d patch in case we want to go forward with this. Gtk+ already handles this fine.
(In reply to Florian Müllner from comment #4) ... > For what it's worth, I'm not convinced that further increasing the > differences between normal and classic session is a great idea unless > absolutely necessary ... This bug is less severe after bug 745909 was been fixed, since the app menu no longer looks so out of place. You could argue that moving app menus to header bars would bring classic mode closer to the GNOME 2 experience, and would be desirable from that point of view, but I totally see the argument about resources.
*** Bug 756017 has been marked as a duplicate of this bug. ***
Review of attachment 299003 [details] [review]: Otherwise looks good and I think we should push this since g-t-t exposes this setting. ::: js/ui/panel.js @@ +129,2 @@ if (!this._visible) this.actor.hide(); This was already here but it's pointless since we call _sync() at the end of _init() @@ +132,3 @@ this._overviewShowingId = Main.overview.connect('showing', Lang.bind(this, this._sync)); + this._gtkSettings.connect('notify::gtk-shell-shows-app-menu', + Lang.bind(this, this._sync)); I this, just to be consistent with the other signal connections here, we should disconnect from this on destroy()
Comment on attachment 299003 [details] [review] panel: Hide app menu when disabled by settings Attachment 299003 [details] pushed as 36ee4e6 - panel: Hide app menu when disabled by settings (In reply to Rui Matos from comment #8) > ::: js/ui/panel.js > @@ +129,2 @@ > if (!this._visible) > this.actor.hide(); > > This was already here but it's pointless since we call _sync() at the end of > _init() No, it's not pointless - while sync() will call show()/hide(), those are noops when the expected visibility (i.e. this._visible) already matches the requested one.
If an app freezes, we could now access quit menu though. Should quit be on Dash?
(In reply to alex diavatis from comment #11) > If an app freezes, we could now access quit menu though. > Should quit be on Dash? I mean we cant access the quit menu.
If an app is frozen, it is unlikely to handle the app.quit action ...
(In reply to Florian Müllner from comment #13) > If an app is frozen, it is unlikely to handle the app.quit action ... OTOH, if you select quit from the app menu we also send a ping to the app, which will bring up the app frozen dialog. But we do the same every time you focus the window, so it's not a huge problem...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab-test.gnome.org/fmuellner/gnome-shell-extensions/issues/113.
Sorry for the noise, I "found" a bug in the migration script: https://gitlab.gnome.org/External/bugzilla-to-gitlab-migrator/issues/2
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.