Bug 37652

(*** This bug was imported into bugs.kde.org ***)

Hi folks

This is a bug that's been around as long as KDE (it was present
in kvt too) but it looks like QT has the feature necessary to fix it
now.  Here's the deal: Qt doesn't (or didn't) make any distinction between the
keypad keys and their counterparts elsewhere on the keyboard even though 
they have different keycodes and keysyms.  

(see for example http://bugs.kde.org/db/71/7150.html )

For example:
Start xev and look at the keycode and keysym for the keyboard's "1" 
key  and the keypad's "1" key.   For the main keyboard key I get 
keycode=10 keysym=1.  For the keypad "1" key (with num lock off) I get 
keycode=87 keysym=KP_End.  With num lock on this would be KP_1.

X clearly knows that these are different keys but konsole
doesn't.  For example edit /usr/share/apps/konsole/vt100.keytab so 
that the End key is defined as:

         key End   -Shift-AppCuKeys : "stuff"

Now I start up a konsole using this keytab.  I find that both the End key and
the KP_End key generate the string "stuff".

As of QT 2.2.0 it looks like there's a mechanism to fix this.

(see http://www.trolltech.com/developer/changes/2.2.0.html )

According to this in "QKeyEvent" Numeric keypad keys now set a Keypad flag.

I'd love it if the next version of konsole could distinguish
between keypad keys and main keyboard keys.  Then I wouldn't have to
keep replacing konsole with xterm for my users (who use the keypad
extensively).

Thanks
Bryan
-- 
===============================================================================
Bryan Wright                |"If you take cranberries and stew them like 
Physics Department          | applesauce they taste much more like prunes 
University of Virginia      | than rhubarb does."  --  Groucho 
Charlottesville VA  22901  |
(434) 924-7218              |         bryan@virginia.edu
===============================================================================