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
12 matches
Mail list logo
