www.michael-jansen.biz

My last two posts about global shortcuts got some comments i want to address now.

Yurij The interesting thing is that this is at least the fourth time I've heard of that particular shortcut conflict in KDE, and have heard of no other examples. Which leads me to think the shortcut situation is pretty good throughout KDE.

That's probably right. But we can't know. We have at least one other conflict in core kde. Plasma uses CTRL+ESC for the system activity dialog. The same shortcut is defined in kde as a standard shortcut for the close action. See kcmshell4 standard_actions.

We will see how many of that shortcut conflicts exist. Since my last post i have a idea how to implement checking local shortcuts against global shortcuts for conflicts. I hope to implement that before 4.2 .

Anyonymous: also, QMdiArea defines ctrl+w as close tab shortcut, and there is no way to change that afaik. (fine with me though)

That's right. QActions and QShortcuts in KDE applications are a problem. They live outside of the framework. KShortcutsEditor won't handle QActions. I have no idea why, but i won't change it until i have an idea why it was decided that way. QShortcuts are completly out of our control. That means noone should use them in kde code. In case of Qt's standard widgets we are out of luck. I see currently no way to get them in line.

One of the comments exactly wished for something like our current system. A central daemon having the control over global shortcuts and checking for conflict. But even that part is really controversial. I was more than once asked why this is necessary at all.

So let's have a look at the future. When the foundation is settled, and it currently is not, i plan to give the power to the user. If i by miracle can convince all developers to respect the global shortcuts api it is possible to let the user decide how global shortcuts should be handled. But this will only work if all play by the rules.

So here is what i want to do for 4.3. Let the user decide what the global shortcuts strategy should be.

• Never ever activate a global shortcut by default. Don't even inform me about global shortcuts. I will go to the kcm if i need one
• Never ever activate a global shortcut by default. Inform me if a new application tries to register new global shortcuts. I will tell you what to do then.
• Activate global shortcuts automatically. Inform me only when a conflict happens. Either on registration of a conflicting shortcut or on triggering a conflicting shortcut.
• i don't care about global shortcuts. Let the anarchy prevail.

But that will not work with applications ignoring the api.

Aaron: the assumption that shortcuts actually outlive the application is simply incorrect and applications like plasma (highly dynamic, shifting components during a session), kwin (highly dynamic, shifting between sessions) and media players (same keyboard controls should work with whatever the "active" media player is, which can change during the session) show this to be true.

Media players are a bad example Aaron. Which media player? I won't count how many have been installed by my opensuse installation. So which one of these should have the buttons. Amarok which is running all the time, dragonplayer when started, mplayer running in the background or whatever you use? Do you expect something to happen magically if you press the media button without any player active? We need a central instance controlling those buttons giving the user the possibility to decide what should happen in case more than one player is active or none.

I solved kwins problem. Lubos explained what the problem is and with a new feature of the api everything works now. Almost. If Lubos somehow could be convinced to unregister the associated Window shortcuts if a window is closed kwin would be a first class user of the api. I would do it myself but i don't know where that code is.

And plasma? Not the slightest hint of an actual problem with the current system. I have once seen a problem but that was because of a wrong use of the api and i admit thats probably because the api isn't currently well documented. But you guys told the same story before that.

And that highly dynamic aspect of plasma is the main reason you should try to use the api correctly. Predictability. That is my pet peeve with global shortcuts. Do you remember my firefox example? I see no difference between applets and firefox plugins. Imagine a user who has applets installed from many different sources. And now imagine all of them trying to register global shortcuts for these important 'About applet' action and/or some more or less useful other actions. Your preferred way of handling would mean the first applet initialized wins. As there is no conflict handling the user will notice when triggering the actions that something unexpected or nothing happens - you remember the kopete shortcut that does nothing when triggered sometimes? That's why we have the global shortcuts kcm. One stop to find out what happens. On stop to remember what the user wanted.

So let's see what is needed for plasma to work correctly. If an applet is added to an containment register the global shortcut. If you have no id to use create one. QUuid is very helpful in that regard as demonstrated by khotkeys. Associate the id with your applet. Optionally write the current set shortcut to disk after calling setGlobalShortcut() with the id. The shortcut you want is probably not the shortcut you get if the user configured it with the global shortcuts kcm. A choice you currently ignore and change back to whatever you have stored in your configuration.

If you want to remember the current shortcut in your configuration subscribe to the KAction::globalShortcutChanged() signal to get informed if the user changes the global shortcut with the kcm. Update your saved configuration if he does.

If the user removes the applet permanently use forgetGlobalShortcut() to free the shortcut.

And now the tricky part. Activities. Is there any consens what should happen to global shortcuts if you switch activities? Let's say all shortcuts from the old containment are disabled and the new containments shortcuts get activated. I expect when switching back to activity one that each and every global shortcut is still the way it was when i left. So i expect the shortcuts from activity one to be still there and to be informed if i want to use one of them for kmail. So let's find a name for that thing and design a api around it.

The idea. An application is allowed to activate something called shortcut context for now because i have no better name. Each and every shortcut registered afterwards is associated with that context. You are able to change the context and register shortcuts with the new one. If you change context the shortcuts from the old one are deactivated. No conflict checking between plasmas global shortcut contexts so you can reuse an shortcut. But other applications shortcuts will be checked against all contexts of plasma. Only one context is active at a time. Doable. Other problems?

Mike