Hi Lex,
> Doesn't matter what you do, any handler returning TRUE will stop other
> handlers being called within signal_emit before it returns to you.
> https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-key-press-event
This is true, for 'key-press-event' and 'key-release-event' at
Hi Matthew,
> > No, I was wrong with my first guess about the order mattering; it turns
> > that it's just the fact that anything else (Geany or plugin) binds to a key
> > makes that key unavailable to 'keyrecord'.
>
> That doesn't sound right. Anything that connects to say
>
>
> This is true, for 'key-press-event' and 'key-release-event' at least.
> However, for my 'pre-key-press-event', it is NOT the case; all connected
> callbacks are always called. I'm guessing that GTK makes a distinction
> between events originating in X or the kernel, and user-created
Hi Matthew,
> Just to be clear, you are talking about this:
> https://github.com/geany/geany-plugins/blob/062865e3b57a3baa882f69e4f3bc291278c200e4/keyrecord/src/keyrecord.c#L99
Yes, that's the one.
> and depending on the order the plugins connect to same signal as well as
> whether or not they
On 2020-05-14 11:31 p.m., Austin Green wrote:
Hi Matthew,
Just to be clear, you are talking about this:
https://github.com/geany/geany-plugins/blob/062865e3b57a3baa882f69e4f3bc291278c200e4/keyrecord/src/keyrecord.c#L99
Yes, that's the one.
and depending on the order the plugins connect to
On Fri, 15 May 2020 at 14:35, Austin Green wrote:
>
> @Lex:
> > Of course you can't enforce non-suppression, the best you can do is to
> > document it clearly (hint not to forget the documentation :)
>
> Actually you can (and my code currently does) enforce it, simply by ignoring
> the return
