(unknown)

[Caleb Tennis]

One KDE4 port I've been researching for a while now is what to do with the 
KKey,KKeyServer,KShortcut,KKeySequence,etc. classes, which in many ways are 
just extensions to Qt counterparts.  I've been researching this code over the 
past few weeks to try and find what, if anything, is necessary and what can 
be moved to using the Qt classes directly.  Here's my short synopsis and my 
plan of action:

All of these classes are VERY tightly coupled.  When it comes down to it, the 
most basic class is KKey, which is supposed to represent a key on the 
keyboard.  For WIndows and Mac, it very simply stored the Qt::Key code.  For 
X11, it stores the X11 "symbol" and "modifer" values.  All of the other 
classes are based on this fact.

As best as I can tell, the reason it stores the X11 codes is to workaround 
earlier Qt limitations.  In the 3.0 release of Qt, there was no Qt::META key, 
so the Windows key on keyboard could not be used - for example.  This has 
been fixed in later versions.

The KKeyServer (X11) also added some functionality to allow you to determine 
if a keypress of "*" came from the number above the 8 or from the keypad.  
This is also rectified in Qt4 with a Qt::KeypadModifier flag in the 
Qt::KeyboardModifier enum.

The last thing KKeyServer does is attempt to provide some extra information 
about keypresses that may not be inferred by Qt::Key - for example, if a 
SysReq key is pressed it infers that the "Alt" key must also be pressed.  
This I am still researching to determine if the code is necessary or not.

Other than this, I cannot see a reason why storing the X11 keycode vs. the 
Qt::Key provides any benefit to KDE.  For some rogue cases, there are ways to 
directly call the X11 functions themselves to get the keyboard maps and scan 
codes.  But for the purpose of Accelerators and Shortcuts, I think that this 
code is simply not needed anymore.

So, my proposal is to slowly eliminate as much of these classes as necessary, 
moving stuff into kde3support as needed.  I've done a lot of work with lxr to 
see where the rest of this code is used in KDE and frankly, most of the low 
level stuff isn't used far enough probably to warrant much in the way of 
kde3support.  

My plan is to work in small discrete chunks and then let things settle a 
little bit before moving on to the next batch.  I plan to fix all instances 
in trunk where code would be calling functions that are obsoleted, so it 
should be "transparent" for existing code.  After the underlying code is 
fixed, I'll work on the replacements for KKeySequence and KShortcut.

If anyone has concerns or comments, please let me know (please CC me directly 
as I'm not subscribed to the list).