GNOME Bugzilla – Bug 346605
[PATCH] Modifier-key events are not sent
Last modified: 2006-07-07 22:38:09 UTC
GDK backends should send GDK_BUTTON_PRESS and GDK_BUTTON_RELEASE events when modifier keys are pressed and released, but quartz only sends these events when non-modifier keys are pressed. Clients which expect these events (such as GtkImSimpleContext) get confused. Steps to reproduce: 1. Run tests/testtext 2. Focus on the text view. 3. Hold down shift and control. 4. Continue holding down shift and control, and press the 'U' key to enter Unicode entry mode. Notice the underlined-u appearing in the text view, to indicate the new entry mode. 5. Still holding shift and control, enter the text "40" to indicate U+0040 COMMERCIAL AT. The text appears after the 'u', also underlined. 6. Release the shift and control keys. Expected result: The underlined 'u40' disappears, and is replaced by the @ symbol. Actual result: The text 'u40' remains, and messages such as the following appear on the console: 2006-07-05 01:31:42.103 testtext[25380] Unhandled event NSEvent: type=FlagsChanged loc=(-101,625) time=148034.9 flags=0x100 win=0x169aee0 winNum=13999 ctxt=0x17913 keyCode=59 The attached patch uses the NSFlagsChanged event to detect modifier key pressed and released events. It also adds debugging of key events when --gdk-debug=events is passed at the command line. The X11 backend appears to always pair press and release events, but this implementation does not. For example, if the user holds down Alt while in the Finder, switches to a GTK app, and then releases Alt, only the release event will be received by GTK. Any apps that depend on the exact behavior of the X11 backend could misbehave. Is this a significant problem with the patch?
Created attachment 68377 [details] [review] Patch to enable modifier-key events
Created attachment 68540 [details] [review] Fixed patch Apparently flags-changed events are sent when an Exposé keyboard shortcut is used, although the keycode in these events is zero and appears to be meaningless. I'm not really sure what Apple was thinking when they decided this! Anyhow, the new patch properly ignores these events.
Thanks, I've committed this. The potential problem that you mention could be an issue but we can deal with the corner cases in later iterations. Are you sure that the gtk app being switched to receives a key press event if alt is being pressed and then the gtk app is focused?
At least in X11 on OS X, that seems to be the behavior. Some sort of phantom events seem to be sent in order to ensure that there's always (or at least usually) exactly one press per release. It probably has more to do with the keyboard driver for X11 than with anything in GDK. Try it yourself with GDK_DEBUG=events if you want to be sure I'm not imagining it! Thanks for taking a look at my patches, I appreciate it. Just FYI, I've also filed a couple of bugs on cairo-quartz that have been preventing gtk-demo's Text View -> Multiple Views from working: https://bugs.freedesktop.org/show_bug.cgi?id=7437 https://bugs.freedesktop.org/show_bug.cgi?id=7446