search

eyelash / xi-gtk

a GTK front-end for the Xi editor
Apache License 2.0
355 stars 23 forks source link

GtkSourceView key-binding signal compatibility #8

Open sp3d opened 7 years ago

sp3d commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@sp3d does e5a54980539fb42338891653e7b2dc62e6930458 fix this issue for you?

sp3d commented 7 years ago

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! :tada: