GNOME Bugzilla – Bug 695377
App menu is inconvenient when the app is in another monitor
Last modified: 2021-07-05 14:13:51 UTC
I have two monitors side by side. Say I start an application that makes heavy use of the app menu, like Totem or Empathy. If I put that application's window on a monitor that is not the one that holds the shell's panel and app menu, it becomes very cumbersome to use that app's commands. I need to mouse all the way to the other monitor and back in the course of using the application. For those apps that I use often, I've become used to having to do that, although it is still inconvenient. But for apps which I seldom use and I don't know that well, it's very easy for me to completely miss commands that are actually available in the app menu. When I don't find what I'm looking for in the application's window, I'll eventually remember, "oh, let's look over there" :)
*** Bug 694507 has been marked as a duplicate of this bug. ***
Totem and Empathy are two examples of applications which are over-using the app menu, in my opinion. Items in that menu shouldn't be frequently used. It would also be really helpful if we could have a consistent set of items in the menus, so that they are predictable. One useful thing that we could do is survey the existing application menus and work towards increased consistently. Updating the Totem and Empathy to resemble our design aspirations will also help enormously.
(In reply to comment #2) > Totem and Empathy are two examples of applications which are over-using the app > menu, in my opinion. Items in that menu shouldn't be frequently used. It would > also be really helpful if we could have a consistent set of items in the menus, > so that they are predictable. > > One useful thing that we could do is survey the existing application menus and > work towards increased consistently. Updating the Totem and Empathy to resemble > our design aspirations will also help enormously. That does not solve the underlining problem though ...
*** Bug 693452 has been marked as a duplicate of this bug. ***
*** Bug 698713 has been marked as a duplicate of this bug. ***
(sorry for the duplicate report) From 698713: On F19-alpha: gnome-shell-3.8.0.1-2.fc19.x86_64 I have a 2-screen setup. I just opened up rhythmbox fullscreen on the non-primary screen (the one without the top bar) and also opened up firefox fullscreen on the primary screen. Accessing the application menu (in the top bar) now becomes quite a challenge (I have focus follows mouse): - I have to make sure rhythmbox is focussed - I now have to aim my mouse travel into the top bar such that I do not by accident focus firefox Some remarks about this: - The application menu is located on the OTHER screen than where the application is running. This is a major 'context' violation w.r.t. cognitive ergonomics. - The mouse travel is way too far and way too delicate Proposal: - Make the application context accessible from the 'right-click on window top bar'
(In reply to comment #2) > Totem and Empathy are two examples of applications which are over-using the app > menu, in my opinion. Items in that menu shouldn't be frequently used. It would > also be really helpful if we could have a consistent set of items in the menus, > so that they are predictable. > > One useful thing that we could do is survey the existing application menus and > work towards increased consistently. Updating the Totem and Empathy to resemble > our design aspirations will also help enormously. So can we have a fixed design for 3.10 please? Pretending that problems do not exists don't make them go away. We have do *something*.
*** Bug 676200 has been marked as a duplicate of this bug. ***
Maybe it is necessary to make really clear (to developers): What is the purpose of the Application-Menu? As far is I understand the Application-Menu is a extension to regular menues or Wrench-Button, and not a replacement like on Unity or MacOS. The later two seperate the application from its menues, what is horrible (long distances, multi-screen, unlogical seperation). While the Application-Menu should offer a concise selection, always at the same place in the same fashion? What it should contain: Prefernces, Help, About? And, Open? I don't know. https://wiki.gnome.org/Design/HIG/ApplicationMenus Sadly I can't access this website since days, like many other pages of the GNOME-Project.
Just in case someone looks at the title and suggests a multi-monitor-specific solution: Even within the same monitor it can be just as inconvenient. With a large monitor, a small app window like empathy's contact list can be a *long* way from its menu.
(In reply to comment #10) > Just in case someone looks at the title and suggests a multi-monitor-specific > solution: Even within the same monitor it can be just as inconvenient. With a > large monitor, a small app window like empathy's contact list can be a *long* > way from its menu. That's the key friction point and what Peter above describes. Empathy simply folded its menu into an app menu. That's making the travel distance/time a big issue. App menus don't work well for frequently used items like starting a new conversation. That should be accomodated directly in the main window — https://wiki.gnome.org/Design/Apps/Chat However the issue of the app menus not particularly working on multi-monitor, with one of them taking on the primary role, remains.
just for the record: https://bugzilla.gnome.org/show_bug.cgi?id=688105
*** Bug 709095 has been marked as a duplicate of this bug. ***
*** Bug 688105 has been marked as a duplicate of this bug. ***
So, abuse of the app-menus is one problem, sure. However, when they're being used correctly, the multi-monitor aspect of this bug is still a big issue. FWIW, installing the multi-monitor panels extension ( https://extensions.gnome.org/extension/323/multiple-monitor-panels/ ) makes this much better -- you get appmenus on each monitor, for the applications on that matter. It really makes the whole multi-monitor experience under gnome feel *MUCH* more cohesively designed to me.
Thanks for the link, using the Top-Bar (without date and system-tray) also on the secondary monitor is the only solution I could imagine so far. Sadly it doesn't work with current release.
let's add Rhythmbox to the list of apps that use a common action ('Add to music collection') inside the app menu; if you have RB on a secondary display, so that it doesn't occupy a whole workspace in the stack, you have to walk around for a bit with your pointer. prior art for having the panel on every output: MacOS X 10.9. Apple tied the menu bar on every screen to the ability of showing different workspaces on them as well, so if you disable the latter, you don't get the former.
perhaps automatically adding the CSD App menu to the headerbar for windows moved to a secondary screen would solve this partially? not very consistent i know, but the only other option i can think of would be to add a top panel to every screen then :/
(In reply to Emmanuele Bassi (:ebassi) from comment #17) > ... > prior art for having the panel on every output: MacOS X 10.9. Apple tied the > menu bar on every screen... > ... Showing the header bar with the app menu on every screen sounds like to only sane solution. I know the intention of not showing the header bar on secondary displays should save some vertical pixels, but can't work together with the app menu in a consistent way. Some vertical pixels need to be sacrified for this, but the current solution just doesn't work with multiple displays. Mereley, the header bar is dependency of the menu bar.
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.