Having to click once to close an open Gnome menu is confusing for new users

Reported by Yfrwlf on 2011-01-09
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ayatana Design
Undecided
Unassigned
One Hundred Papercuts
Undecided
Unassigned
gtk+2.0 (Ubuntu)
Low
Unassigned

Bug Description

I feel this is a paper cut:

Often times I will watch new Gnome/Ubuntu users click on a menu but decide they want to do something else instead. They will then try to click on some other window, or another menu, or an icon, and expect a response but not get one. This leaves new users confused and uncomfortable, as it seems their desktop isn't responding to what they are telling it to do.

While Linux/Gnome/Ubuntu users have gotten used to clicking once anywhere first in order to close the menu before they can click on something else, new users are used to not having to do that. I feel that such a setting is really not ideal or necessary and really doesn't accomplish anything that I can tell. It also doesn't really mesh well with existing settings such as being able to scroll inside windows which are not in focus simply by placing the mouse cursor over them and scrolling. One would think that if you could do that, surely you could also click on those unfocused windows and get a response from them. This doesn't mesh well with menus "controlling" the mouse until a click is given to close them, even if a user is clicking on a legitimate icon or menu somewhere else, and seems a bit contradictory.

Learning to click to close menus is something that I don't think any other OS out there requires right now, so for Linux to still require it, and for usability concerns, I think is a step in the wrong direction.

Chris Wilson (notgary) wrote :

I can see how this would be problematic for some users. When the user clicks on a menu and moves the cursor to an adjacent menu, focus will automatically switch to the new menu. However, by that reasoning, the user would expect the menu to close completely if they move the cursor away from it completely, which it doesn't.

This isn't a trivial fix given that this functionality is deeply rooted within the Ubuntu GUI. I'm not sure if this is a GTK things, or something to do with Gnome's implementation of it, but this will require some work to change, so I am marking this as invalid for the paper cuts project.

Changed in hundredpapercuts:
status: New → Opinion
status: Opinion → Invalid
Yfrwlf (yfrwlf) wrote :

I thought you just had to change the type of X window that gets created for Gnome menus from one which steals focus to one which doesn't basically? "Menus" (simply a different kind of X window) clearly have a different kind of focus setting than most normal windows do, like Nautilus windows.

You'd think there would be a master control for any and all "menu" GTK windows, so that making such a change wouldn't be required across all programs, but only for the "menu" window class.

But, I guess you know it's not an easy fix like that, since you said it wasn't.

Sebastien Bacher (seb128) wrote :

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Changed in gtk+2.0 (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers