kcmkeys (was Re: Global shortcuts and i18n)
l.lunak at suse.cz
Thu Feb 7 14:52:26 GMT 2008
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
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.
> 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)
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
More information about the kde-core-devel