Farewell KAccel, you have served us well

[Hamish Rodda]

Hi,

Now that QAction has taken over the shortcut management, it is time to remove 
KAccel from kdelibs.

This turned out to only be complicated in a few areas:
1) Finding alternatives for saving and loading of shortcuts from config files 
and xml files.  I hope I've replaced it all.

2) Porting the KKey* and KShortcutDialog classes in kdeui to use purely Qt key 
codes and apis (removing the X specific stuff, it didn't seem to gain us much 
now that we rely on Qt's keycodes for everything anyway)

As an added bonus, I noticed that from an api design perspective, it made more 
sense to allow any KAction to be associated with a global accelerator, rather 
than to special case it as was the case in the past.  So, now you can assign 
(programatically at least, gui to follow) a global accelerator to any 
KAction.  imho it is a gain, but not as large as it might first seem (many 
actions need focus to do something meaningful for the user).  I also 
abstracted most of the bookkeeping out of KGlobalAccelPrivate and into 
KGlobalAccel itself, so that the (now renamed) KGlobalAccelImpl class can 
concentrate on doing platform-specific tasks only.  KGlobalAccel is now a 
singleton.

Other changes I made include:
1) Moving files around - most of the classes I have moved to kdeui (the others 
like KShortcut and KStdAccel could probably follow suit)

2) Made KShortcut rentrant and implicitly shared (QSharedData is cool)

3) Removed KAccel, KAccelBase, KShortcutList, KKeySequence, KKey, KKeyNative, 
and others i've probably forgotten to mention

4) Simplified KKeyServer (removed unneeded methods)

Questions that this raises:
1) Should global accelerators be able to be prohibited per KAction? (I'd say 
yes to allow kiosk limitations)

2) Should this prohibition be separate to the configurability of the normal 
shortcuts of the action?  (probably yes again but i'm less sure of this)


I also found a problem with the new KAction api while I was doing all of this.  
Seeing how the normal shortcut is not a part of the constructor, the default 
shortcut did not get set as a routine for non-deprecated uses of the api.

The fix I came up with (which is short of doing some massive porting) was to 
default setShortcut() to setting the default as well, with a boolean flag to 
override.  This doesn't sit too well with me (not just for the use of the 
boolean, which I guess would be better as an enum), but it seems to be the 
best solution I can think of.  By far the most common use case is that the 
code is setting a shortcut which should be the default, mostly custom 
shortcuts should get loaded from config files.  So I'd certainly appreciate 
feedback on this.

The whole patch isn't quite ready to go (need to actually make the global 
accelerators work again, and hook them into the gui), but here it is for your 
constructive criticising...

Whole patch:
http://members.optusnet.com.au/~hamishrodda/kdelibs-nokaccel-20060327.patch.bz2

Relevant interestingly changed headers only:
http://members.optusnet.com.au/~hamishrodda/noaccel-headers.tar.bz2

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060328/003042d4/attachment.sig>