From kde-core-devel Mon Mar 27 14:05:31 2006 From: Hamish Rodda Date: Mon, 27 Mar 2006 14:05:31 +0000 To: kde-core-devel Subject: Farewell KAccel, you have served us well Message-Id: <200603280105.46271.rodda () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=114346835628827 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2348672.f0RB2asRP3" --nextPart2348672.f0RB2asRP3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Now that QAction has taken over the shortcut management, it is time to remo= ve=20 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 fil= es=20 and xml files. I hope I've replaced it all. 2) Porting the KKey* and KShortcutDialog classes in kdeui to use purely Qt = key=20 codes and apis (removing the X specific stuff, it didn't seem to gain us mu= ch=20 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 m= ore=20 sense to allow any KAction to be associated with a global accelerator, rath= er=20 than to special case it as was the case in the past. So, now you can assig= n=20 (programatically at least, gui to follow) a global accelerator to any=20 KAction. imho it is a gain, but not as large as it might first seem (many= =20 actions need focus to do something meaningful for the user). I also=20 abstracted most of the bookkeeping out of KGlobalAccelPrivate and into=20 KGlobalAccel itself, so that the (now renamed) KGlobalAccelImpl class can=20 concentrate on doing platform-specific tasks only. KGlobalAccel is now a=20 singleton. Other changes I made include: 1) Moving files around - most of the classes I have moved to kdeui (the oth= ers=20 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, KKeyNativ= e,=20 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 sa= y=20 yes to allow kiosk limitations) 2) Should this prohibition be separate to the configurability of the normal= =20 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 th= is. =20 Seeing how the normal shortcut is not a part of the constructor, the defaul= t=20 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 t= o=20 default setShortcut() to setting the default as well, with a boolean flag t= o=20 override. This doesn't sit too well with me (not just for the use of the=20 boolean, which I guess would be better as an enum), but it seems to be the= =20 best solution I can think of. By far the most common use case is that the= =20 code is setting a shortcut which should be the default, mostly custom=20 shortcuts should get loaded from config files. So I'd certainly appreciate= =20 feedback on this. The whole patch isn't quite ready to go (need to actually make the global=20 accelerators work again, and hook them into the gui), but here it is for yo= ur=20 constructive criticising... Whole patch: http://members.optusnet.com.au/~hamishrodda/kdelibs-nokaccel-20060327.patch= =2Ebz2 Relevant interestingly changed headers only: http://members.optusnet.com.au/~hamishrodda/noaccel-headers.tar.bz2 Cheers, Hamish. --nextPart2348672.f0RB2asRP3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEJ/E6H8BtnSmIlUYRAiEtAKCDA/JOxAnU70egVvHcU2pT/mR5PACeKGTP 2KBC7tM7HOO2ujsJnjZpmlI= =my5L -----END PGP SIGNATURE----- --nextPart2348672.f0RB2asRP3--