Bug 37652 - keypad support in konsole
Summary: keypad support in konsole
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Other
: NOR wishlist
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-01-29 19:18 UTC by bryan
Modified: 2007-12-16 08:08 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch: Test implementing keypad in keytab files. (3.26 KB, patch)
2004-05-01 23:12 UTC, Kurt Hindenburg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bugzilla Maintainers 2002-01-29 19:04:15 UTC
(*** 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
===============================================================================
Comment 1 Geoff Kingsmill 2003-08-18 05:49:25 UTC
I too have an application that requires the keypad. This is one of the few 
missing features that prevent me from moving to Konsole. It would be terrific 
if Konsole could be updated to support the keypad.
Comment 2 Kurt Hindenburg 2004-05-01 23:12:51 UTC
Created attachment 5848 [details]
Patch: Test implementing keypad in keytab files.

I sort-of have this working.  Am I going about this the correct way?

Basically, in the .keytab file:
key Up	  -Shift-Keypad   : "Up -shift-keypad"
key Up	  +Shift-Keypad   : "Up +shift-keypad"
key Up	  +Keypad  : "Up +Keypad"
key End   -Keypad  : "End"
key End   +Keypad  : "KP End"
Comment 3 Robert Knight 2007-12-16 08:08:54 UTC
Fixed in KDE 4, more specifically - SVN revision #748996.  Added the "keypad" modifier which can be used like any other in the .keytab file, as per Kurt's example above.

The only special property of the 'keypad' modifier is that it does not count when matching entries against the AnyMod property.  This means that AnyMod only considers Control,Shift,Alt,Meta as before.