Each of *.po files references to a file ../data/geany.glade.h but this file is absent in the sources. Is this file lost?
On Mon, 4 May 2020 at 10:02, Dmitry Unruh via Devel devel@lists.geany.org wrote:
Each of *.po files references to a file ../data/geany.glade.h but this file is absent in the sources. Is this file lost?
IIUC these are created by intltool when it extracts strings from glade but I'm no expert.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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 of calling the plug init functions is what counts, but it's complicated by plugins being unloaded and reloaded dynamically.
On Tue, 12 May 2020 at 12:00, Austin Green austin.green@orcon.net.nz 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 of calling the plug init functions is what counts, but it's complicated by plugins being unloaded and reloaded dynamically.
Correct, signals can be added before or after (https://developer.gnome.org/gobject/stable/gobject-Signals.html#g-signal-con... and connect_after) but in the face of non-determinism of the order of loading and enabling plugins (as the user can enable and disable them in any order) its not possible to guarantee the resulting signal order. That appears to be a limitation of the gobject signals implementation.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Hi Lex,
On Tue, 12 May 2020 14:02:15 +1000 Lex Trotman elextr@gmail.com wrote:
On Tue, 12 May 2020 at 12:00, Austin Green austin.green@orcon.net.nz 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 of calling the plug init functions is what counts, but it's complicated by plugins being unloaded and reloaded dynamically.
Correct, signals can be added before or after (https://developer.gnome.org/gobject/stable/gobject-Signals.html#g-signal-con... and connect_after) but in the face of non-determinism of the order of loading and enabling plugins (as the user can enable and disable them in any order) its not possible to guarantee the resulting signal order. That appears to be a limitation of the gobject signals implementation.
Thanks for that. My proposed fix is to register 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 it. Thus, any plugin that needs to be assured of priority (and promises not to suppress the signal handling) will get first look-in. Does that sound feasible?
Cheers, Austin.
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 it. Thus, any plugin that needs to be assured of priority (and promises not to suppress the signal handling) will get first look-in.
OK, I've tried it out, and it works very well. It doesn't look, at least to me, as a non-Geany-expert, that it would cause any problems. So, what's the best way to bring it to the attention of the Geany devs? Do they perhaps read this list? ;) Or should I just go ahead and submit a pull request?
Cheers, Austin.
On Thu, 14 May 2020 at 16:52, Austin Green austin.green@orcon.net.nz 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 "pre-key-press-event" with the same event data as was passed to it. Thus, any plugin that needs to be assured of priority (and promises not to suppress the signal handling) will get first look-in.
OK, I've tried it out, and it works very well. It doesn't look, at least to me, as a non-Geany-expert, that it would cause any problems. So, what's the best way to bring it to the attention of the Geany devs? Do they perhaps read this list? ;) Or should I just go ahead and submit a pull request?
Yep. But probably worth describing your use-case as well.
Cheers Lex
Cheers, Austin. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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 of calling the plug init functions is what counts, but it's complicated by plugins being unloaded and reloaded dynamically.
Hi,
Can you elaborate on what you are trying to do specifically? There may be a better way.
Regards, Matthew Brush
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.
Cheers, Austin.
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...
@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 tested it.
I'd rather not use deprecated functions, you never know what GTK might do with them in the future.
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.
Hmm, sounds a bit can-of-wormsy. I feel my solution is cleaner; needs only two extra statements in keybindings.c.
Cheers, Austin.
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 all platforms, though I haven't tested it.
I'd rather not use deprecated functions, you never know what GTK might do with them in the future.
It will exist and (in theory) function correctly until gtk4.
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.
Hmm, sounds a bit can-of-wormsy. I feel my solution is cleaner; needs only two extra statements in keybindings.c.
I guess we'll see what the PR looks like, I'm not entirely sure I understand the underlying issue (assuming you mean the existing 'keyrecord' plugin?), or the proposed solution.
Regards, Matthew Brush
On Fri, 15 May 2020 at 10:48, Austin Green austin.green@orcon.net.nz 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.
Of course you can't enforce non-suppression, the best you can do is to document it clearly (hint not to forget the documentation :)
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.
I think a new signal that doesn't change the semantics of any other signal or function probably won't need ABI just API version change
Cheers Lex
Cheers, Austin. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
@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 you don't trust plugin developers, you could pass only a copy of the event data.
Cheers, Austin.
On Fri, 15 May 2020 at 14:35, Austin Green austin.green@orcon.net.nz 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 value from the g_signal_emit_by_name call. To make certain, if you don't trust plugin developers, you could pass only a copy of the event data.
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-e...
Cheers Lex
Cheers, Austin. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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-e...
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 events, or maybe just event generated by g_signal_emit_by_name calls.
The upshot of all this is:
1. Can't use key-press-event, because Geany filters out all key strokes bound by any installed plugin. 2. Can't use key-release-event, because at least two other plugins use it, and filter out the event in some circumstances. 3. My proposed pre-key-release-event signal is unfilterable, and so is suitable for plugins that need a 'look but don't touch' event. However, it would still not stop a plugin determined to usurp a key bound to someone else. Despite that, I still think it's worth implementing.
This has been an interesting learning experience for me, so my thanks to you and to Matthew for all the discussion.
Cheers, Austin.
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 events, or maybe just event generated by g_signal_emit_by_name calls.
Well, it sort of makes sense, GTK doesn't know your new callback from a snow leopard, so it doesn't know if it has a boolean return paradigm or not.
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 TRUE to inhibit further processing, which means that 'vimode' can deprive Geany and other plugins of certain keystrokes. It works OK for 'keyrecord', at least without 'vimode' loaded. I guess I should probably use it for now, though it may break in the future, and may not work properly if 'vimode' is loaded at the same time as 'keyrecord'.
Cheers, Austin.
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
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.
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.
Regards, Matthew Brush
@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 key. Geany, in its handling of key-press-event, checks for a key binding that matches, and if found, calls the callback and then prevents the event from going any further (by returning TRUE). If it didn't, any plugin could receive the same events and assign its own action to the key, and chaos would no doubt be the result.
Cheers, Austin.
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 key-press-event signal merely by binding to a key. Geany, in its handling of key-press-event, checks for a key binding that matches, and if found, calls the callback and then prevents the event from going any further (by returning TRUE). If it didn't, any plugin could receive the same events and assign its own action to the key, and chaos would no doubt be the result.
Just to be clear, you are talking about this:
https://github.com/geany/geany-plugins/blob/062865e3b57a3baa882f69e4f3bc2912...
and depending on the order the plugins connect to same signal as well as whether or not they return `TRUE` from their signal handler, there's no guarantee the `keyrecord` plugin gets too see all `ScintillaObject::key-press-event` signal emissions?
Regards, Matthew Brush
Hi Matthew,
Just to be clear, you are talking about this: https://github.com/geany/geany-plugins/blob/062865e3b57a3baa882f69e4f3bc2912...
Yes, that's the one.
and depending on the order the plugins connect to same signal as well as whether or not they return `TRUE` from their signal handler, there's no guarantee the `keyrecord` plugin gets too see all `ScintillaObject::key-press-event` signal emissions?
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'.
Cheers, Austin.
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/062865e3b57a3baa882f69e4f3bc2912...
Yes, that's the one.
and depending on the order the plugins connect to same signal as well as whether or not they return `TRUE` from their signal handler, there's no guarantee the `keyrecord` plugin gets too see all `ScintillaObject::key-press-event` signal emissions?
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 `ScintillaObject::key-press-event` has the opportunity to propagate that signal to other handlers by returning `FALSE` from the handler function. Any plugins which swallow GTK+ events, preventing them to be handled by other plugins or core itself, should be highly suspect, as far I can see.
Regards, Matthew Brush
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 `ScintillaObject::key-press-event` has the opportunity to propagate that signal to other handlers by returning `FALSE` from the handler function. Any plugins which swallow GTK+ events, preventing them to be handled by other plugins or core itself, should be highly suspect, as far I can see.
I agree; nevertheless, taking 'key-release-event' as an example, both geanymacro and geanynumberedbookmarks plugins return TRUE when they have handled the event. I have tried to use 'key-release-event' in 'keyrecord', and, with 'geanymacro' loaded, I saw no events.
Perhaps those plugins should be regarded as buggy?
Geany itself, in its handler for 'key-press-event', after calling a key-binding callback for a matching key, then returns TRUE. Presumably the thinking is that only one plugin may bind to any given key, so no further action needed. However, that action does stop other plugins from merely looking at the key-press event; that may be intentional too, otherwise plugins could effectively usurp keys that had been bound elsewhere.
Cheers, Austin.