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 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. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
