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 116998 - Duplicated focus event comming using numpad.
Duplicated focus event comming using numpad.
Status: VERIFIED INCOMPLETE
Product: gnopernicus
Classification: Deprecated
Component: keyboard&mouse
unspecified
Other Linux
: Normal major
: ---
Assigned To: ps
ps
Depends on: 108664
Blocks:
 
 
Reported: 2003-07-08 15:40 UTC by ps
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4



Description ps 2003-07-08 15:40:26 UTC
Description:     
Use GNOME stack from 19.06.2003, gnopernicus version 0.3.4 from date   
07.07.2003 (GNOME CVS) and at-spi version 1.3.5 from 07.07.2003 (GNOME 
CVS) 
Using numpad keys to activate commands of gnopernicus, a focused object  
loses the focus and it is refocused, and the "window:activate" and  
"window:deactivate" events are comming.     
Gnopernicus repeats to say a focused object at all numpad key press 
event.     
     
Steps to reproduce:       
1. Run Gnopernicus     
2. Active speech from General Settings.   
3. Run window-listener-test from at-spi    
	This test application is used to show the window events.   
4. Move focus on gnopernicus, e.g. on General Settings button.   
5. Activate NumLock.   
6. Press numpad_0 and and numpad_+. This will change the command layer.  
7. Press more time numpad_del, and you will hear the switch window event.   
The output what the the window-listener-test showed I will addedd in   
addition information.   
   
Actual results:      
Activate and deactivate event are comming. Gnopernicus says "Switch 
window event" and the focused object.  
   
Expected results:      
None of these events to come when the numpad keys are pressed.   
   
Addition information:      
Test application log:   
window:deactivate gnopernicus  
window:activate gnopernicus  
window:deactivate gnopernicus  
window:activate gnopernicus  
window:deactivate gnopernicus  
window:activate gnopernicus  
window:activate gnopernicus  
window:deactivate gnopernicus  
window:activate gnopernicus  
  
This version of gnopernicus use global listener for numpad key listening  
(SPI_KEYLISTENER_ALL_WINDOW), and this bug depend on bug number 108664  
(Unwanted switch window event occur when use  
SPI_KEYLISTENER_ALL_WINDOWS). In the next commit I will made the reverse  
of this changes. It will use toolkit listener until when the bug number  
108664 not fixed.
Comment 1 padraig.obriain 2003-07-29 10:30:34 UTC
Paul,

I am starting to look at this bug now. Where is the key listener for
numpad key listening defined? Is it using SPI_KEYLISTENER_ALL_WINDOWS
now?
Comment 2 ps 2003-07-29 10:44:17 UTC
Hi Padraig. 
 
The file where the keylistener is defined is in gnopernicus package 
/kbd_mouse/libke/libke.c 
 
At start of this file it is an undef USE_ALL_WINDOWS 
If you define this flag and compile it, it will use 
SPI_KEYLISTENR_ALL_WINDOW for numpad keys. 
The registering are in the ke_init function. 
Comment 3 padraig.obriain 2003-07-29 12:35:52 UTC
I have tried to follow the instructions.

Nothing happens in window-listener-test window after I activate
NumLock and press the keys. How do I debug this?
Comment 4 Calum Benson 2003-08-07 16:18:01 UTC
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)
Comment 5 bill.haneman 2003-08-22 11:24:08 UTC
Padraig, are you trying this on linux or Solaris?  There are
differences in the XKeySyms on the two platforms which may affect your
results; there may be another bug masking the problem on Solaris,
since I don't think XSun distinguishes between 'KP_1' and '1'.  As
I've told the gnopernicus team before, we need some special code in
gnopernicus to determine the X Keycode for the numeric keypad keys,
and they gnopernicus should do a keycode-based ALL_WINDOWS grab
instead of a KeySym-based ALL_WINDOWS grab.

- Bill
Comment 6 padraig.obriain 2003-08-22 11:43:14 UTC
I had tried to investigate on Solaris.
Comment 7 bill.haneman 2003-08-27 15:38:07 UTC
this bug appears to be a duplicate of 108664, at least given the
initial description.

I really this bug is misleading since the current codebase doesn't
produce the symptom.  Therefore instead of being an open blocker bug,
I think this bug should be closed!

However, I think it's very important that gnopernicus change to using
the ALL_WINDOWS flag to its key listeners, which might cause this bug
to reappear if 108664 is not completely fixed.
Comment 8 ps 2003-09-03 16:57:01 UTC
Changes on cvs. I close this bug because it is main issue is fixed of
this bug and it is duplicated.