GNOME Bugzilla – Bug 735614
Improve popup-menu keynav
Last modified: 2014-08-28 17:13:27 UTC
See patches. This fixes keynav issues with non-top-bar menus like the GDM session menu and the message tray button (when navigation to the button itself works, see bug 707799).
Created attachment 284721 [details] [review] popupMenu: Handle key-press events on sourceActor The behavior of opening/closing/navigating a menu from its source actor is generic enough to not limit it to PanelMenu.Buttons, so move the code into PopupMenu itself.
Created attachment 284722 [details] [review] popupMenu: Use an appropriate key to move focus into the menu The code from PanelMenu.Button assumed menus would open below their source actor, making KEY_Down a good choice; however with the new generic code, we should base the key used on the actual menu position.
Review of attachment 284721 [details] [review]: Makes sense to me.
Review of attachment 284722 [details] [review]: Couldn't it make sense to recognize all four at the same time? So when the menu pops up below the source actor, pressing Up goes to the last item in the menu? This is what GTK+ does.
Attachment 284721 [details] pushed as 1d58ea2 - popupMenu: Handle key-press events on sourceActor Attachment 284722 [details] pushed as 98847f2 - popupMenu: Use an appropriate key to move focus into the menu (In reply to comment #4) > Couldn't it make sense to recognize all four at the same time? No. In the top bar, left/right should move to the previous/next button, not navigate into the menu. > So when the menu pops up below the source actor, pressing Up goes to the last item in the menu? > This is what GTK+ does. GTK+ also wraps around when navigating with arrow keys, which we don't do. I don't really mind handling both up/down for top/bottom menus (not left/right, see above) eventually, but at this point in the cycle I'd rather not do any ad-hoc behavior changes.