KKey* classes

[Lubos Lunak]

On Tuesday 06 of September 2005 15:23, Caleb Tennis wrote:
> 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:

 Ah, great. I was already mentally preparing for accepting the fact that this 
person would have to be me ;).

>
> 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.
...
>
> 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.

 I suggest you have a closer look at KGlobalAccel. Support for global 
shortcuts needs to stay in kdelibs as I doubt Qt will ever have support for 
that, so KGlobalAccel will need to stay. KGlobalAccel may have some 
additional requirements (though I doubt that). In fact I think that the only 
classes that need to stay are KGlobalAccel+dependencies and 
KKeyDialog+dependencies. I can't think of any good reason why the rest 
shouldn't be switched to Qt classes (but unlike you I haven't really looked 
into it).

>
> 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.

 There should be some code in KWin (and perhaps elsewhere) that needs things 
like KKeyServer::modXNumLock() but I don't think any "normal" app should need 
that stuff. If you'll need any help with that or X11 in general feel free to 
ask.

>
> 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).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/