GtkSourceView key-binding signal compatibility

[sp3d]

Keyboard interaction with GTK widgets should be done through the key binding infrastructure:

https://developer.gnome.org/gtk3/unstable/gtk3-Bindings.html

For text-editing widgets, you want to essentially mirror the signals presented by GtkTextView:

https://developer.gnome.org/gtk3/stable/GtkTextView.html#GtkTextView.signal-details

For touch and mouse events you basically have to read the source code of GtkTextView in order to implement the same state machines they have for selection-expanding scrolling, drag-and-drop, and middle-click paste events. This is ugly, but I'm not aware of an upstream GTK bug about it, or any design plans they have for making it cleaner.

[eyelash]

I definitely want to rewrite the key binding stuff at some point but I want to wait with this until it is clear where xi-core is going. My personal preference would be that shortcuts would be handled by the core. This would allow me to configure my preferred bindings once and then use that configuration across different Xi front-ends (at least on the same platform).

[eyelash]

@sp3d does e5a5498 fix this issue for you?

[sp3d]

The key-binding side of it looks great! Users can modify keybindings in their ~/.config/gtk-3.0/gtk.css with an entry like:

@binding-set XiEditViewBindings
{
    bind "<Control>Down" { "send-edit" ("move_right") };
}

*
{
  -gtk-key-bindings: XiEditViewBindings;
}

This does obviously differ from the signals used by GtkEntry and GtkSourceView, and it might be nice to support those signals (translating them into the appropriate Xi commands), but that doesn't enable anything fundamentally new over the current status. It would just mean users get their keybindings adapted automatically instead of having to configure them themselves.

We can either close this bug (and maybe open another about compatibility with the signal-set used in other widgets) or use this bug for the latter. Either way, this is already much improved! 🎉