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 106004 - Different keycode returned by the java application that the gtk application
Different keycode returned by the java application that the gtk application
Status: RESOLVED DUPLICATE of bug 106081
Product: at-spi
Classification: Platform
Component: javabridge
0.0.1
Other Linux
: Normal normal
: ---
Assigned To: Darren Kenny
Darren Kenny
Depends on:
Blocks:
 
 
Reported: 2003-02-13 16:14 UTC by ps
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4


Description ps 2003-02-13 16:14:47 UTC 
I tested gnopernicus on my linux system, whit different type of
applications (gtk and java based applications).
The gtk application return different keys and keycodes as the java
application. 
In java application that the Num_Lock is active at keypress did not return
that the Num_Lock is on (in modifier flag ). In java application the
Num_Lock is not a modifier?
Comment 1 ps 2003-02-14 08:36:10 UTC 
On java application gnopernicus get a keyevent which is not registered.
Ex. It made a keyset for ControlL key, and this keyset is registered
for  an keylistener. The listener listen only this one key. On java
application the callback for ControlL event is called, whit a
keystruct filled by the not listened key. Can it fix it?
Comment 2 Darren Kenny 2003-02-14 08:57:19 UTC 
I'm looking at this now. NumLock (and others) are not viewed as
modifiers in Java, so will need mapping... Unfortunately the
more I look into it the more I'm seeing that there might be more
involved given Java's view of a "Virtual" keyboard.
Comment 3 Darren Kenny 2003-02-14 15:01:10 UTC 

*** This bug has been marked as a duplicate of 106081 ***
Comment 4 bill.haneman 2003-02-14 15:12:05 UTC 
Darren: since this concerns the 'application' (as opposed to the
'global') key listener API, it's not clear to me that we should
enforce complete consistency.  We should think carefully about how to
be reasonably consistent while still keeping to the toolkit/app's view
of the keyboard.