On 2020-05-14 5:48 p.m., Austin Green wrote:
Hi Matthew,
On Thu, 14 May 2020 16:20:58 -0700
Matthew Brush <mbr...@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-install
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
