From kde-core-devel Fri Apr 13 08:59:31 2007 From: Lubos Lunak Date: Fri, 13 Apr 2007 08:59:31 +0000 To: kde-core-devel Subject: Re: [RFC] Handling lobal shortcuts conflicts Message-Id: <200704131059.31958.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117661383930393 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 > : = . > 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@suse.cz , l.lunak@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