After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319639 - Java application keycodes are different.
Java application keycodes are different.
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
unspecified
Other All
: High major
: ---
Assigned To: Orca Maintainers
Orca Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-10-24 20:25 UTC by Rich Burridge
Modified: 2006-08-10 16:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Rich Burridge 2005-10-24 20:25:25 UTC 
See also rfe #319638

     The key event handler is currently "taking the easy way out" by
     registering synchronous event handlers for the entire keyboard.
     BillH has advised against this.  Instead, the key event handler
     should:

    > Use global handlers for synchronous keyboard events - this will
      (or should) work around the fact that keycodes emitted by Java
      applications are different from the rest of the world.  Note that
      this requires the Xserver XEvIE extension to be in place.

    > Use synchronous listeners sparingly.  For all other things, such
      as "any keystroke stops speech," one should consider asynchronous
      listeners.

    NOTE: for learn mode, one must have synchronous listeners for all
    keystrokes.
Comment 1 Willie Walker 2006-04-12 20:47:19 UTC 
Using the XEvIE extension may ultimately solve our woes here because it will allow use to get events at a very low level.  In the meantime, however, we may need to create a custom script for Java to translate Java keycodes back into platform keycodes (yech, because different platforms have different keycodes), or we may need to modify the Java access bridge to do this for us (probably a better solution).
Comment 2 Willie Walker 2006-07-17 19:41:43 UTC 
Lynn Monsanto from the Orca team has created a workaround in Orca to better handle this bug.  It lives in the J2SE-access-bridge.py:consumesKeyboardEvent method, and converts the keysyms we're getting from Java to keycodes.  It works OK, as long as the keyboard handling logic is getting this far.  The places where it won't get this far are for global keystrokes that live in orca.py.

We are talking about refactoring the keyboard event handling to move all keystroke handling to scripts.  If this is the case, then the J2SE-access-bridge.py workaround will probably be sufficient for a while.  BTW, please note also that the java-access-bridge maintainer has decided that delivering consistent keycodes is an RFE: see bug 318615.
Comment 3 Rich Burridge 2006-08-10 16:31:20 UTC 
Keystoke handling has been refactored to be done in default.py
so there are no more global keystroke handlers in orca.py.
Closing as FIXED.