GNOME Bugzilla – Bug 581605
consider adding icon actions to the context menu
Last modified: 2017-09-04 22:14:57 UTC
For accessibility, it would be nice to have a rule that says: Every action that can be accessed by clicking on an entry icon or by using its menu should also be accessible in some other way. One way to ensure that would be to add these actions to the entries context menu. We could do that automatically, and have a way to prevent that, maybe.
Looking at the entry icon api, this idea doesn't actually work, since we only have icon-press/icon-release signals, and the menus, etc are all handled application-side. The only thing I could come up with so far is a activate-icon keybinding signal, that can be bound to various key combinations to simulate icon-press and release events on the icons. This is really not very nice. The patch I'm attaching does Ctrl-Enter -> send icon-press/icon-release for button 1 on the primary icon Ctrl-Shift-Enter-> send the same for button 1 on the secondary icon Ctrl-Menu -> send icon-press/icon-release for button 3 on the primary icon Ctrl-Shift-Menu -> send icon-press/icon-release for button 3 on the secondary icon The application code then needs to be careful to make the menu behave well as a keyboard-triggered menu when the send_event flag in the event is set. Ugly, ugly.
Created attachment 134453 [details] [review] patch
In case the Epiphany address entry is affected: Epiphany already uses Ctrl+Enter and Ctrl+Shift+Enter in the address entry to open the entered URL in a new tab and in a new window, respectively.
Oh yeah, those bindings were mostly for test purposes. Coming up with available key combinations that make sense will be a challenge.