On 2020-05-14 5:48 p.m., Austin Green wrote:
Hi Matthew,
On Thu, 14 May 2020 16:20:58 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Can you elaborate on what you are trying to do specifically? There may be a better way.
Sure thing.
The plugin 'recordkey', and possibly others, connects to the 'key-press-event' signal. Possibly depending on the order of plugins being loaded, or possibly not, but either way: some of the keys bound to other plugins are lost to the view of 'recordkey', presumably because Geany processes all of the keybindings in its handling of the 'key-press-event' signal. The order of loading plugins cannot be controlled anyway, as the user may load/unload at any time. Causing Geany to emit a new signal, on receipt of the 'key-press-event' signal, but prior to any processing, allows any plugin (that connects to the new signal) to view (but not suppress) all key press events.
I'll be pleased if there is another way which doesn't involve changing Geany, it will save me some work. ;) And of course it's always good not to have to bump the ABI version.
You could use something like `gtk_key_snooper_install()`[0] to get priority access to keys. It's deprecated because the GTK+ team don't care about edge cases where it's useful, or other reasons, but it should still work fine with GTK2/3 on all platforms, though I haven't tested it.
If you don't mind writing #ifdefs/platform-dependent code, you could use XLib and/or Win32 functions directly to grab the key events for the window. I don't believe Wayland protocol supports this (on principle), but it may be supported by some compositors in protocol extensions, not sure.
I can think of a few ideas to do it with Geany/GTK+/plugin alone, but I'd have to test it out to see if would work at all.
Regards, Matthew Brush
[0]: https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-key-snooper-in...