After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 86367 - Recommend the initially selected item of popup menus
Recommend the initially selected item of popup menus
Status: RESOLVED OBSOLETE
Product: gnome-devel-docs
Classification: Applications
Component: hig
unspecified
Other Linux
: Normal normal
: ---
Assigned To: HIG Maintainers
HIG Maintainers
Depends on:
Blocks: 85976
 
 
Reported: 2002-06-24 16:49 UTC by Marco Pesenti Gritti
Modified: 2020-12-04 18:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Marco Pesenti Gritti 2002-06-24 16:49:22 UTC
Nautilus is using a custom function to position context menus so that the
first item is not selected. People seem to agree that the context menus
position should be the same in all apps but it's not sure if default
behavior is good for usability.
It would be good to know HIG position about this so that the bad behavior
can be fixed at nautilus level or at an higer level if the case.
See bug 85976 and
http://mail.gnome.org/archives/nautilus-list/2002-June/msg00198.html
Comment 1 Gregory Merchan 2002-11-13 04:10:00 UTC
Bug #85976 has already been resolved by making Nautilus use the Gtk+
standard positioning.

The reason noted on list for the behavior of Nautilus is that people
were right-clicking, not seeing a menu, right-clicking again and 
inadvertently selecting the first item on the popup menu. The obvious
solution for that is to make the menus faster.

Does the HIG need to specify anything here other than "Stop breaking
the toolkit!" ?

(I think NeXT-style scrolling menus are better, but support should
 be in Gtk+ first. Right?)
Comment 2 Gregory Merchan 2002-12-02 20:45:25 UTC
Somebody should have kicked me. The toolkit normally allows popup
menu positioning. I knew this. What I meant was, "I think using that
to move a menu away from the cursor is misuse of the toolkit function."

I read at least one other platform's HIG (don't recall which) wherein
it is stated that context menus should appear to a side of the context.
I fail to recall whether there was a particular side and whether
this is for both mouse and keyboard activation. I'll research again
for it.
Comment 3 Murray Cumming 2002-12-10 13:53:36 UTC
So this bug can be closed?
Comment 4 Murray Cumming 2002-12-24 01:07:08 UTC
Gregory?
Comment 5 Gregory Merchan 2002-12-24 01:22:22 UTC
Best not to close this just yet. The issue has resurfaced in some
recent feedback about GNOME2.

The question is not so much about the position as it is about the
effect. The effect of the default position is to select (highlight)
the first item on the menu. So the question is really:

Should a menu item be selected (highlighted) on a popup menu that
is shown in response to a mouse button action?

Other related questions are:
 Does this change for popup menus shown in response to keyboard
  actions? How?
 Which menu item should be selected in any case?

So either the summary needs to be changed, or this closed and a new
bug opened.
Comment 6 Sebastian Rittau 2003-07-09 19:20:48 UTC
Suggestions:

When a popup menu pops up, the first item should be selected,
regardless of whether it was opened with the mouse or the keyboard. I
guess that this is the most consistent way to do. Also, since normally
the most requested action should be at the top of a context menu, this
is convenient.
Comment 7 Calum Benson 2003-11-25 14:52:29 UTC
There's some relevant commentary on this from Owen in bug #70372
Comment 8 Kjartan Maraas 2005-04-16 12:00:25 UTC
Is this bug still relevant? The bug it supposedly blocks is closed as fixed a
long time ago...
Comment 9 Calum Benson 2007-12-06 18:43:08 UTC
I'm closing this as obsolete.  Popup menu behaviour seems consistent everywhere now, AFAICT: no item is ever selected by default when a popup menu is posted, by mouse or keyboard.  If we believe that's the wrong behaviour, it's a gtk+ issue, not a HIG issue.