GNOME Bugzilla – Bug 681428
Right click shouldn't have the same behavior as left click
Last modified: 2012-08-08 21:43:31 UTC
Hi, this was originally reported in Fedora's bugzilla, but it didn't get enough attention, so I'm cloning it here: +++ This bug was initially created as a clone of Bug #691314 +++ Description of problem: When right clicking in user menu or other menus, such as volume or accessibility, the right click has unexpectedly the same behavior as left click. Steps to Reproduce: 1. Open the user menu 2. Right click on "Log out" 3. The logout prompt is shown. Expected results: Either some context menu should be shown or nothing. Additional info: I found this problem when searching for options how to shutdown my computer. I was searching for some alternative for pressing Alt to unveil the shutdown option. I would expect that there is context menu which allows that, but instead, my computer was unexpectedly suspended. --- Additional comment from srainwater@ncc.com on 2012-03-03 18:02:24 CET --- Yes, this is very confusing for new users. After you've been using GNOME 3 for a while though it's just mind-bogglingly annoying. What's the design thinking behind making the left and right buttons both do what the left button used to and then hiding or removing all the functionality of the right button? This definitely needs to be fixed ASAP to make GNOME 3 remotely usable!
It's the same as GTK+ menus.
Looks like a problem only for people expecting the top panel to behave just like gnome-panel in GNOME 2. If you came with no prior ideas about the Shell, it feels quite natural. Anyway, what should right click do if not the same as left click ?
(In reply to comment #2) > Anyway, what should right click do if not the same as left click ? Well, the only reasonable alternative to "same as right click" is "nothing". Not what GNOME2 users would expect of course :-)
Doing nothing when a user explicitly acts on something doesn't sound like a nice experience. If there's a good reason to have an alternative set of options for a menu item, we could use right click for it (or long press), but I don't see why we would need that.
I guess this means WONTFIX for now... Thanks for the report anyways.
Well, the main reason is that it is not expected that computer will go sleep if I right click on the sleep menu item. It happens when you are searching for the way how to switch of the computer. BTW for me, it would be natural to show switch of option for the context menu of sleep menu. Simply put, right click is context menu, or I would expect the menu to close, but definitely not the same action as the left click.
I've been thinking about this, so I'll share my thoughts here, just in case they're worth to someone. When it was decided to assign to the right click the same behavior as the left click, I guess it was took for granted that the user will eventually learn that the shell's top panel doesn't have right click options, right? Okay, so now, is that really fair to assume? Because when right clicking on other elements in some applications (and even in the shell itself, eg. in the dash) a menu pops up with options. So how does the user really know what is going to happen when right clicking on an element? Trial and error? Shouldn't something like this be even more consistent and predictable? I agree doing nothing when right clicking is not the best solution either, though.
(In reply to comment #7) > When it was decided to assign to the right click the same behavior as the left > click, I guess it was took for granted that the user will eventually learn that > the shell's top panel [...] Or any menubar/menu in any GTK+ application ;-)
(In reply to comment #6) > Well, the main reason is that it is not expected that computer will go sleep if > I right click on the sleep menu item. It happens when you are searching for the > way how to switch of the computer. BTW for me, it would be natural to show > switch of option for the context menu of sleep menu. The menu will be improved for 3.6, it will no longer be an issue. See https://live.gnome.org/GnomeOS/Design/Whiteboards/SystemStopRestart
(In reply to comment #9) I know, but that is different topic, although the context menu would be much better.
(In reply to comment #8) > (In reply to comment #7) > > When it was decided to assign to the right click the same behavior as the left > > click, I guess it was took for granted that the user will eventually learn that > > the shell's top panel [...] > > Or any menubar/menu in any GTK+ application ;-) Ok, I see now. So the criteria is that no menu whatsoever has right click options, and that includes all the elements in the shell's top panel because they're in fact menus. That actually kinda makes sense.