kcmkeys (was Re: Global shortcuts and i18n)

[Lubos Lunak]

On Wednesday 06 of February 2008, David Faure wrote:
> On Wednesday 06 February 2008, Lubos Lunak wrote:
> >  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....

 Well, if you never use Amarok, KdedGlobalAccel is currently not going to know 
about it at all AFAICS. But anyway, you've never actually tried it, 
right :) ? Just try to assign Alt+F2 to something and you'll see - you get 
prompted about the conflict and asked whether you want to reassign.

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

 Well, then the solution is having it a bit less hard-coded than plain 
#include <xyz.cpp>. That still doesn't make it necessary to show every single 
global shortcut in there.

> 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 necessary. If you try to assign that shortcut to something, you should 
again get the conflict dialog.

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

 This is only the two things above.

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

 By KDE4 I meant KDE4 as it is now, with having kdedglobalaccel as the place 
that provides all the information. 'KDE4 with (non-optional) description 
file' is 'KDE3', so you're basically supporting me :). Well, except for 1).

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

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