GNOME Bugzilla – Bug 318615
Keycodes delivered by Java access bridge are inconsistent with keycodes delivered by GTK
Last modified: 2008-06-17 15:01:15 UTC
Please describe the problem: Java applications apparently provide different keycodes than those provided by GTK on the same platform. The reason for this seems to be that GTK uses X Window System based keycodes and Java uses its own notion of platform-independent keycodes. The result, however, is that inconsistent keycode information is provided to assistive technologies trying to use the AT-SPI. Steps to reproduce: 1. Run the AT-SPI key-event-listener test 2. Run gnome-terminal 3. Set up java access bridge and run the SwingSet2 demo. Actual results: Press 'd' while in gnome-terminal: keycode=40 Press 'd' while in SwingSet: keycode=68 Expected results: I'd expect the keycode for 'd' to be the same for all applications and toolkits on the same desktop. Does this happen every time? Yes. Other information:
Note that this ONLY affects keycodes returned via the 'toolkit key listener' API, not those returned with the ALL_WINDOWS flag. Now that Xevie is available (and working properly... ?), one can work around this by specifying ALL_WINDOWS. This also works around the problem with OpenOffice/StarOffice not supporting CAN_CONSUME.
Will and I discussed possible fixes. Looks like a java-keycode-to-keysym conversion in the java-bridge would be appropriate. However, the current delivery mechanism for bridges (such as atk-bridge and java-bridge) for 'toolkit key events' (i.e. non-global keyboard event notifications) is DeviceEventController::notifyListenersSync()/DeviceEventController::notifyListenersAsync, neither of which pass any info about the source of the event (i.e. which toolkit, etc.). One way to fix this with the current API would be to define additional AT_SPI device event types KEYSYM_PRESS_EVENT and KEYSYM_RELEASE_EVENT, which the deviceeventcontroller could translate/transcode into KEY_PRESSED_EVENT and KEY_RELEASED_EVENT on receipt, as a special extension to the current API contract.
Created attachment 112453 [details] [review] Patch to use X11 keysym names where appropriate This patch does two things: 1) Makes sure the appropriate KP_xxx X11 keysym names are used for keypad keys 2) Makes sure the appropriate X11 keysym names are used for non-alphanumeric symbols I tested this on a US keyboard using the US keymap and it does much much better than we ever used to do. I know I'm missing some non-US keysyms, such as the upside down exclamation point and upside down question mark, but I'm not sure how I can catch them all. In any case, Jeff - what do you think of this patch?
Making sure Jeff is CC'd on this.
Looks good, please commit it to trunk and branch.
Patch committed to trunk and gnome-2-22 branch. Closing as FIXED.