In addition, the signal allows plugins swallow the event so it's not processed by Geany.
This signal is required for the vimode plugin - see https://github.com/geany/geany-plugins/pull/735 You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1829
-- Commit Summary --
* Allow plugins to process keypress events before Geany
-- File Changes --
M doc/pluginsignals.c (20) M src/geanyobject.c (9) M src/geanyobject.h (1) M src/keybindings.c (6) M src/plugindata.h (2)
-- Patch Links --
https://github.com/geany/geany/pull/1829.patch https://github.com/geany/geany/pull/1829.diff
Vim!!! Geany don't wanna work like vim :grin:
But anyway LGBI
Can't plugins easily just install their own handler to the main_window? Do we need an API for this?
@kugel- The plugin not only needs to receive the keypress events but also consume the event so Geany won't perform the assigned keybinding. And this isn't possible with just connecting "key-press-event" because Geany connects it too and its handler is performed first.
Should be possible to prioritize the plugin's handler signal recursion, right? I.e. emit key-press-event from Geanys handler.
Hmm, I'm not sure I understand - if you emit "key-press-event" from the Geany's handler, the handler gets called again and you get an infinite loop.
The current handler should be blocked automatically. If not there is an api for that; g_signal_handler_block()
@kugel- Yep, it works, thanks for the suggestion. One really has to block the signal manually otherwise it leads to an infinite loop.
Did you check if the plugin handler doesn't get called twice with that?
Ah, yeah, it probably is fired twice in the case when
1. the plugin doesn't consume the event, and 2. Geany doesn't consume the event
Basically it means it's fired twice when the plugin isn't interested in the event which doesn't really matter for the vimode plugin but it definitely isn't nice. So yeah, we are back where we were and I don't know how to handle this with the single "key-press-event" used both for Geany and the plugin. You'd really need to change the order in which the signal is connected but I don't see a way how this could be done.
Nobody seems to have any ideas how to fix the reuse of key-press-event so I reverted back to adding a new signal to Geany.
elextr commented on this pull request.
@@ -270,3 +270,23 @@ signal void (*update_editor_menu)(GObject *obj, const gchar *word, gint pos, Gea
*/ signal gboolean (*editor_notify)(GObject *obj, GeanyEditor *editor, SCNotification *nt, gpointer user_data); + +/** Sent whenever a key is pressed. + *
Is this only on key press? what about key release?
techee commented on this pull request.
@@ -270,3 +270,23 @@ signal void (*update_editor_menu)(GObject *obj, const gchar *word, gint pos, Gea
*/ signal gboolean (*editor_notify)(GObject *obj, GeanyEditor *editor, SCNotification *nt, gpointer user_data); + +/** Sent whenever a key is pressed. + *
Yes, the same way like Geany itself - Geany keybindings are also triggered by key-presses only.
elextr commented on this pull request.
@@ -270,3 +270,23 @@ signal void (*update_editor_menu)(GObject *obj, const gchar *word, gint pos, Gea
*/ signal gboolean (*editor_notify)(GObject *obj, GeanyEditor *editor, SCNotification *nt, gpointer user_data); + +/** Sent whenever a key is pressed. + *
ok, yeah, all keybindings are press only.
Well, it doesn't appear to break anything if its not used, so will commit over the weekend.
@elextr Great, thanks!
@techee I'm guessing at least you tested this works (ex. with your VIM mode plugin)? Otherwise it's kind of scary to merge untested code into master.
To clarify my post above, I have tested that the change does NOT cause any problems in Geany. Since plugins can be disabled, if it causes any problems with a plugin 1) the user can blame the plugin :grin: and disable it 2) the plugin writer can supply a PR to fix the problem 3) after that is tested to not cause problems in Geany and applied 3) the user can re-enable the plugin. (repeat until plugin works)
@codebrainz Of course I tested it - I wouldn't be able to develop the plugin without it. And it really shouldn't affect plugins not using the signal so I'd say this one is very low risk. Of course there could be some discussion how to call this signal (I named it "key-press" for the lack of any better idea) or whether to implement it in a different way (I liked the idea of @kugel- but I didn't find a way how to achieve what I needed without a new signal).
codebrainz approved this pull request.
I'm OK with this if @techee says it's OK. I didn't test it, but at least @elextr checked in didn't interfere with normal operation.
Merged #1829.
github-comments@lists.geany.org