>
> Well, whaddaya know? I cloned a recent version of geany, and found that
> someone has already implemented a very similar Geany signal, called
> "key-press".
For at least part of this thread I thought you meant that signal, not
the low level GTK signal.
Cheers
Lex
Well, whaddaya know? I cloned a recent version of geany, and found that
someone has already implemented a very similar Geany signal, called
"key-press". It was needed for the 'vimode' plugin, and at present that's the
only one that uses it. It differs from my proposal in that it can return
>
> 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 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
>
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
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
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 10:18 p.m., Austin Green wrote:
@Matthew:
Further to my previous message, you might also inspect the existing
plugins which are blocking GTK+ signals and see why they're doing that,
whether on purpose or on accident, and possible ways they can not do that.
They block the
@Matthew:
> Further to my previous message, you might also inspect the existing
> plugins which are blocking GTK+ signals and see why they're doing that,
> whether on purpose or on accident, and possible ways they can not do that.
They block the key-press-event signal merely by binding to a
On 2020-05-14 9:34 p.m., Austin Green wrote:
@Matthew:
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
@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 value from the g_signal_emit_by_name call. To make certain, if
@Matthew:
> 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
On 2020-05-14 5:48 p.m., Austin Green wrote:
Hi Matthew,
On Thu, 14 May 2020 16:20:58 -0700
Matthew Brush 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
On Fri, 15 May 2020 at 10:48, Austin Green wrote:
>
> Hi Matthew,
>
> On Thu, 14 May 2020 16:20:58 -0700
> Matthew Brush 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,
On 2020-05-14 5:48 p.m., Austin Green wrote:
Hi Matthew,
On Thu, 14 May 2020 16:20:58 -0700
Matthew Brush 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
Hi Matthew,
On Thu, 14 May 2020 16:20:58 -0700
Matthew Brush 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
On 2020-05-11 7:00 p.m., Austin Green wrote:
I need to ensure that one particular plugin will process keyboard events before
other plugins get to see them (as some plugins may cause further handling of
the event to be suppressed). Is there a way to achieve that? I'm guessing
that the order
On Thu, 14 May 2020 at 16:52, Austin Green wrote:
>
> Hi Lex,
>
> Further to my last message, which proposed: a new signal, say
> "pre-key-press-event", then, in Geany start-up (before any plugin loading)
> connect to "key-press-event". In the handler for "key-press-event", Geany
> just emits
Hi Lex,
Further to my last message, which proposed: a new signal, say
"pre-key-press-event", then, in Geany start-up (before any plugin loading)
connect to "key-press-event". In the handler for "key-press-event", Geany just
emits "pre-key-press-event" with the same event data as was passed to
Hi Lex,
On Tue, 12 May 2020 14:02:15 +1000
Lex Trotman wrote:
> On Tue, 12 May 2020 at 12:00, Austin Green wrote:
> > I need to ensure that one particular plugin will process keyboard events
> > before other plugins get to see them (as some plugins may cause further
> > handling of the event
On Tue, 12 May 2020 at 12:00, Austin Green wrote:
>
> I need to ensure that one particular plugin will process keyboard events
> before other plugins get to see them (as some plugins may cause further
> handling of the event to be suppressed). Is there a way to achieve that?
> I'm guessing
22 matches
Mail list logo
