[RFC] Handling lobal shortcuts conflicts

[Lubos Lunak]

On Thursday 12 of April 2007, Andreas Hartmetz wrote:
> Hello list,
>
> In KDE 3 there is a system in place to find and resolve global shortcuts
> conflicts. If you choose (in KKeyChooser) a shortcut that is already taken
> by another applications' global shortcut, you will be asked if you want to
> "steal" it from the other application or choose another one.
> This system fails in many cases.
>
> If you do black-box testing, it looks like there is a predefined list of
> standard global shorcuts (like Klipper's) that you are not allowed to
> steal. Stealing mostly(?) has no effect, and the system doesn't notice when
> a global shortcut in another application was changed so that the old
> shorctut is now available.
> During examination of the code, it seemed to me like all global shortcuts
> were saved in the config file "kdeglobals" and conflicts were resolved by
> looking there for other shortcuts.

 Yes, that's how it works. There are all those whateverbindings.cpp files that 
are #included in kcmkeys and it uses it for showing the complete list. It 
also writes them to kdeglobals so that conflicts can be detected even in 
keyboard dialogs of applications.

> The truth lies somewhere in between (?) and frankly, I have given up
> research because the system doesn't work anyway.
>
> We need something that works for KDE 4.
>
> My idea is to use KGlobalAccel as the gateway to a config group in
> kdeglobals

 Not kdeglobals, please. This file is parsed when any config file is opened 
and it's pretty cluttered with things that are only rarely used by few apps. 
Use e.g. some dedicated config file.

> where *all* global shortcuts have to be registered, like 
> <Application-Name>:<Shortcut-Name> = <Shortcut>.
> When a shortcut was changed, KGlobal Accel would send a DBUS signal to all
> applications  to update their instances of KGlobalAccel, similar to the way
> KDE 3 does this now.
> The users of KGlobalAccel wouldn't have to know anything about this.
> KGlobalAccel would be the one and only class that contains the guts of
> global shortcuts, nice and tidy. The config group that KGlobalAccel uses
> would be made fixed. Its configurability has no real advantage and it's a
> bit confusing.
>
> Do you see any problems with this approach?

- How would this work with unused yet installed apps? E.g. Amarok has some 
global shortcuts, I have it installed but I don't use it. With KDE3 I simply 
don't care, because conflicts with it are not checked, but should this work 
now? Amarok not having any global shortcuts by default? Not nice. The user 
having to reassign such taken shortcuts? And what about conflicts between two 
apps, say Amarok and Juk? They should ideally have the same shortcuts but 
that's a conflict then.

- How exactly do you expect the shortcut registration to work? And note that 
some "global" global shortcuts (KWin, KRunner, etc.) should be shown together 
in kcmkeys.

> (How to remove entries of uninstalled applications? Is it needed?)

 I guess this question and the answer would be similar to the 
unused-but-installed case above.

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