kcmkeys (was Re: Global shortcuts and i18n)

[Lubos Lunak]

On Wednesday 06 of February 2008, David Faure wrote:
> On the other hand I don't agree with Lubos that only core components should
> be in kcmkeys. If you assign a global shortcut to a kwin action then you'd
> better see the amarok global shortcuts too, to make sure you don't choose
> the same shortcut for two actions with global shortcuts.

 There is a difference between seeing the Amarok shortcut in kcmkeys and 
getting a warning about a shortcut being already taken by it. The latter 
should be there indeed [*], but which Amarok user will go to kcmkeys to 
change its global shortcuts?

[*] Not so simple either, actually. If I have one music player and one video 
player, then it should be possible to have the same global shortcut 
for 'Next' in both.

> The KDE3 solution sucked because it was all hardcoded, no way for apps not
> in kdebase to show up in the global shortcuts config module. The kded

 Again, why? Apps that are not in kdebase are not part of the desktop and have 
their own UI to set the shortcut. If there's really something where this is 
not true, then we can find some other way to include the info about shortcuts 
than plain #include <xyz.cpp>, but I don't see the need for anything more.

 Especially given that this would allow cutting down on kdedglobalaccel code.

> module (with Aurélien's solution) solves this nicely.
> However I do agree with Lubos that we shouldn't show "kded"/"krunner", but
> translated names for the components, of course; this is just another string
> to pass to the kded module together with the component name.

 How would you call KRunner, for example, and, whatever you'd call it, why 
should 'Log Out' be exactly there[*]? Especially given that it doesn't belong 
there and I want to move it to ksmserver, which is actually how my 
KConfig+KGlobalAccel+special characters fun started today. Then it would 
suddenly move. Or how about Alt+F1 (show menu, not implemented in Plasma yet 
it seems) and Alt+F2, being not close together?

 Not to mention that currently passing component name to KGlobalAccel is 
broken too :(.

> "separated by function and logically sorted" can be achieved by setting a
> "group" property on the actions (translatable name), and kglobalaccel would
> pass that group along to kdedglobalaccel.

 That's only grouping, not sorting. Currently there is "Switch to desktop 
1", "Switch to desktop 10", ... "Switch to desktop 2", in this order. 
Or "Lower window" and "Raise window" are now several actions appart. Actions 
with direction are now go in order Down/Left/Right/Up, or any other possible 
illogical order depending on the language. This was pretty simple in KDE3 
compared to how you'd have to do it with what's now in KDE4.


 Really, if you compare the KDE3 and KDE4 ways, then I think the summary is 
rather simple:

KDE3:
+/-  only desktop components show up in kcmkeys (the - is there because you 
disagree, but for me this is clear +)
+ no additional complications for kdedglobalaccel (this is +++, as far as I'm 
concerned)
+ simple to do grouping and ordering
+ no arbitrary grouping by whichever executable the action is actually handled 
by
+ not having code in kdelibs for only kcmkeys

KDE4:
just flip those +'s to -'s


-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz