From kde-core-devel Mon Mar 17 02:50:00 2008 From: Michael Jansen Date: Mon, 17 Mar 2008 02:50:00 +0000 To: kde-core-devel Subject: Global Shortcuts Message-Id: <200803170350.01180.info () michael-jansen ! biz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=120572186113025 Some ramblings over global shortcuts. I have some problems with the current state of global shortcuts. So i tried to write up what >I< think is correct behavior. Some kind of vision i would say. The things that annoy me currently 1. I don't care for applications registering global shortcuts without telling me and without giving me the oppurtunity to disable them. I start a application i don't know, accidently press some button combination and something happens. Don't like it. No global shortcuts without my consent. Basta. A application is allowed to advertise actions it thinks are appropriate for global shortcuts, and give default values, but after starting the application the first time they arent active. It's opt-in. 2. I don't care for kde shortcut dialogs dictating that having two applications listening to the same global shortcut is a conflict and not acceptable. When i want to configure a conflicting shortcut let me do it. A warning would be ok. Especially when shortcuts are opt in (1). I can imagine use cases were pressing one shortcut should trigger two or three actions and i would want that. And i don't think pointing to khotkeys is the right thing to do in that case. 3. When running a application i do not care for kde telling me there exists a conflict between global shortcuts when the other application isn't running. Warn me when two applications listen to the same shortcuts at the same time. Perhaps give me the option to suppress that warning for selected shortcuts. 4. I don't like having all shortcuts together in kglobalshortcutsrc. Call it personal preference. I think the belong into the kxmlgui.rc file of the application. How i think it could work 1. If a component ( see KComponentData ) registers a shortcut for the first time. kdedglobalaccel registers the component as inactive. The component goes on to registers it's global shortcuts but they won't be active. Code wise i see no changes. Everything could happen behind the scene. ( Where do not kxmlgui applications store their shortcuts? Not kxmlgui kparts are impossible? ) 2. During that registration the component tells kdedglobalaccel the location of its kxmlgui*.rc file ( i think that's possible ). kdedglobalaccel would need that if the user wants to configure global shortcuts and the application is not running. With that information the keys kcm would be able to inform you of conflicting shortcuts during configuration. But only conflicting shortcuts for active components. When the application is active the keys kcm would inform the application via dbus of changes. No problem there. I thinks it's a one component - one kxmlguiclient*.rc file association. Right? 3. Sometimes later the user activates the global shortcuts for this component using the global shortcuts configuration dialog (Some global checkbox). NOW the dialog checks for conflicts with other active global shortcuts. It doesn't matter if the other application is active or not. It's my choice to ignore the warnings. 4. I start a application. It happens that it has a global shortcut conflicting with that of another active application. Warn me. Give me the option to disable global shortcuts for one of the application temporarily, persistent or go to the global shortcut editor. Problems i18n -> How could the kcm know the localized name of the actions? Store it into the kxmlgui*.rc file. Dirty but workable. A additional file? Most client code could stay the same. And now to something completly different: I think there are most probably controversial changes to be made. 1. Currently it's possible to switch a action from one component to another. That is done by putting it into a actioncollection belonging to a different component. That is sometimes done unconsciously during the creation of Action in kparts. new KAction -> action doesn't belong to a actioncollection so it belongs to the main component. Then putting it into the action collection belonging to the kpart ( different component ). I don't think this should be allowed. And it proved very difficult for the global shortcuts handling. Global shortcuts get informed that component main wants to listen to a shortcuts. And then that information isn't worth a cent anymore because the same action belongs suddenly to component kpart_a. We should disallow that. Which means a) KActionCollections component should only be allowed to change when the collection is empty. b) Moving a action between collections should only be allowed when both belong to the same collection. Those changes would break some existing code. And those changes wouldn't be necessary when implementing the changes i proposed above. kdedglobalaccel would only need to know which component wanted to listen to which shortcut. And so it's not as bad as changing the component currently is. I hope all of that makes at least a little bit sense and i do not have to many misunderstanding :-) Mike Thanks if you read that far. And be nice.