These controllers are meant to be global and
thus should be able to react to events that are
getting routed to open popovers. This makes
shortcuts in open popover menus work.
With this change, the context menu picks up the
accels for the actions. The conversion is not
complete, since we don't have actions for all
bindings yet.
Send the shortcuts used by shortcut managers
and the per-class shortcuts to the action muxer
for associating accels with actions. The
action muxer has existing machinery for propagating
accels to the UI.
We were just cutting through to the application
at map time in a last-ditch effort to find
an accel to display. Drop that and just rely on
the menu tracker to give us the right thing.
For menus, mnemonics trigger without pressing Alt,
and the expectation is that we show them whenever
keynav is happening. Reinstate this behavior for
popover menus.
This is somewhat preliminary, but it helps
debugging shortcuts. It suffers from not having
the right list model apis to do this.
Eventually, this should become a link to the
object details.
Copying the code from GtkKeyHash, filter out X11 modifiers and
Caps Lock from events. Unfortunately, legacy X11 modifiers can
be present even when running full Wayland, due to XKB.
In GTK2, the filechooser was using a Paned, so switching between sidebar
and files list with the arrow keys didn't work (the slider would be
selected instead). So in
https://bugzilla.gnome.org/show_bug.cgi?id=161489 a crude hack was added
to make this possible.
Over the years the filechooser code has changed so that it now would do
this by default, yet the hack had been retained.
People should use shortcut controllers instead (global, capture).
A side effect of this is that GtkMenuItem (or rather: GtkAccelLabel) now
lost its method to magically look up accelerators to display. Somebody
needs to add that back later.
API remains the same, but activation is now done via a
shortcutcontroller.
The code uses a controller with global scope so that the shortcuts are
managed with all the other global shortcuts.
Reduce the amount of special casing by using a ListModel for global and
managed shortcuts, too.
This way, the ListModel API will work for the ShortcutController in the
GtkShortcutManager and GtkRoot.
The only special case remaining is shortcut activation, which needs to
pass the right widget to the controller in the global/managed case.
This is mainly for internal use, but I can't see a reason to not have it
public for people who want to maintain their own lists.
I'm sure gnome-builder will never ever find a way to misuse it.
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
- Activate a GAction