GNOME Bugzilla – Bug 59579
Scroll menus should remember last position
Last modified: 2018-02-10 03:30:53 UTC
On the Mac, if I pop up a scroll menu, it will always have the last-selected item in the visible area, so I don't have to scroll to it again. We could keep a history of the last menu item that was activated. Perhaps ideally we'd also have API for applications to set the last-active item, but for now just automagically remembering the last activated item would be nice.
We actually do keep a history of the last activated menu item -- that's how GtkOptionMenu works.
I hacked up a small patch for this issue some weeks ago, but the accessibility people weren't happy with it, see: http://mail.gnome.org/archives/gtk-devel-list/2001-October/msg00129.html The bug is still open, I'll attach my patch so it won't get lost :) ChangeLog: Fri Oct 5 18:33:43 2001 Kristian Rietveld <kristian@planet.nl> * gtk/gtkmenu.c (gtk_menu_popup): add a call to gtk_menu_shell_select_item() to activate the last activated item. Fixes bug #59579
Created attachment 6081 [details] [review] proposed patch
I don't think _selecting_ the last active item is really right. The ideal GUI behavior is probably: - If the menu is activated from the keyboard, always comes up scrolled to the top. - If the menu is activated from the mouse, comes up scrolled so that the last selected item is visible (but nothing is selected) This is what Mozilla does, Windows (IE5 favorites menu) always comes up scrolled to the last position, either from the keyboard or mouse; and you get the annoying behavior of a sudden jump in scroll location when you keyboard navigate into the scrolled section; it's a little less annoying than it could be because there is the neat touch that only the actual favorites scroll, not the top fixed menu items (add to favorites, organize favorites.)
Created attachment 39013 [details] [review] Another proposed patch This problem is nicely pops in GtkComboBox using menus. Combobox should scroll popup to current item and probably highlight it somehow. If not highligh, but just make last element prelighted.
Patch 39013 applies cleanly. Reviewing it would take a little while. (Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.