kcmkeys (was Re: Global shortcuts and i18n)

[David Faure]

On Wednesday 06 February 2008, Lubos Lunak wrote:
> 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 what if I decide to change the amarok shortcut and use its former value for the kwin shortcut?
It's much more convenient if I can do that from the same kcontrol module, rather than having
to do the first in amarok itself and then the second in kcmkeys. Especially if I'm not using amarok at all....

> but which Amarok user will go to kcmkeys to  
> change its global shortcuts?

Maybe not for amarok, but what if someone ported kdesktop or kicker to kde4 in extragear,
or wrote other desktop/panel apps as an optional alternative to plasma? (just an example,
plasma is great, but the point is that modularity is good). Or what if you don't know KDE very well,
but you notice that a given key shortcut is eaten by KDE, and you have no idea which application
eats it? Having to open the "configure shortcuts" of each and every application to find that shortcut
is certainly not practical, looking it up in a show-all-global-shortcuts kcmkeys is the only solution.

> [*] 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.

Yes, we should allow duplicates at configuration time (i.e. adding a "keep" option to the current warning box),
and pop up another conflict warning box when pressing a shortcut that is associated to more than one -running- application.

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

Just wait until kde-on-windows guys want krunner (for instance) and we move it out of kdebase-workspace....
The #include solution only works within a single module, which nowadays isn't even all of kdebase.
The #include solution also kills the possibility of making standadalone tarballs for an application;
I know that official KDE releases doesn't do it this way, but it happens often that people
want to package a single application out of a kde module. To fork it, to port it, to only compile it, etc.
Cross-applications #includes kill that.
But OK, you can dismiss this (saying "we'll see when the need arises") if you want, the 
previously mentionned reason (finding which app eats your keys) is the big one anyway.

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

OK, that's a good point. We need to show named groups in the kcm, rather than implementation component names.
Which joins with my previous suggestion of passing a "group" (an i18ned QString) with the action; then we can
put Log Out in the "Desktop" group like in kde3.

> Or how about Alt+F1 (show menu, not implemented in Plasma yet  
> it seems) and Alt+F2, being not close together?

They were not in kde3 either, I don't see why they should absolutely be.

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

Good point here. I guess we could also associate an order number with every action,
but this isn't making things simpler indeed.

> This was pretty simple in KDE3  
> compared to how you'd have to do it with what's now in KDE4.

We could optionally read a data file that defines grouping and ordering, then.
Without that file we just do like we do now (which is useful for the simple apps
with 1-3 global shortcuts like klipper, a simple media player, etc.).

>  Really, if you compare the KDE3 and KDE4 ways, then I think the summary is 
> rather simple:
> 
> KDE3:
[numbers added by me]
> 1) +/-  only desktop components show up in kcmkeys (the - is there because you 
> disagree, but for me this is clear +)
> 2) + no additional complications for kdedglobalaccel (this is +++, as far as I'm 
> concerned)
(personally I didn't find that Aurélien's changes made it that much more complicated
than it already was...).

> 3) + simple to do grouping and ordering
> 4) + no arbitrary grouping by whichever executable the action is actually handled by
> 5) + not having code in kdelibs for only kcmkeys
The code you're talking about is only storing some information in a kded module, it's
not part of the kdelibs API.

> 6) + You don't have to run the app first in order to see its keys in kcmkeys.
That is true... it can be seen as a feature though. If I don't ever use amarok, why should
it show up in kcmkeys? I should see all shortcuts of applications I use, but not those of the
applications I don't use...

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

KDE4 with optional description file:
1) + (for me) all global shortcuts centralized in kcmkeys
2) kdedglobalaccel mostly unchanged, the kcm can read those files itself
3) + grouping and ordering comes from the file
4) + grouping should also work cross-component, and component names should be hidden
5) is a non-issue IMHO (but I agree that doing sorting+ordering through kdedglobalaccel would be an issue for this item)
6) + fixed

A per-app file describing the global shortcuts is indeed the idea I had originally (before kde4) about this.

Alternative:
KDE4 with mandatory description file:
1) + (for you) applications can choose to have their shortcut appear 
2-6) unchanged (but the code is simpler if the description file is the only source of information)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).