Rethinking global shortcuts

[Marco Martin]

On Thursday 07 February 2013, Martin Gräßlin wrote:
> Hi all,
> 
> I just wanted to add another global shortcut to KWin and found the
> situation so disappointing that I think we should do something about it in
> PW2.
> 
> So what happened: I wanted to add a new shortcut for showing application
> menu. Wrote the code, compiled, restarted KWin, pressed shortcut: nothing.
> Went to the keybinding dialog and saw that it belongs to Lancelot - I
> don't use Lancelot.
> 
> Second try: changed to a different shortcut, recompiled, restarted, pressed
> shortcut: nothing happened. Went to the keybinding dialog and saw that it
> belonged to juk - started it exactly once in all time.
> 
> I decided to go for the shortcut also used by juk (it's used for mute), but
> it means:
> * old users don't get the shortcut in KWin if they have ever used juk
> * new users will never get the shortcut in juk, because KWin starts faster
> 
> This situation *sucks*.

yep ;)

> For PW2 I suggest the following changes to the shortcut system.
> 1. Define who gets modifiers. Given the way our shortcuts are nowadays, I'd
> say Alt belongs to Shell (Plasma+KWin) and Ctrl+Function keys belong to
> KWin 2. Allow new shortcuts to be registered if the application which had
> it registered before is not running
> 3. Inform users about conflicts
> (4. Allow multiple applications to have the same shortcut and inform all of
> them if it is pressed, yes it sucks to not be able to use the forward media
> button for all media applications)

I like 4, infrming all applications that registered it if a shortcut has been 
registered.

moreover, a thing i would like is to be able to have global name actions, like 
"muktimedia forward", that media applications can chose to listen (and not 
even worry what the actual shortcut is)

So an application could listen for global named shortcuts and then register 
own if those are not enough

then shortcuts could all have names like

org.kde.common.media.forward
org.kde.common.fullscreen
org.kde.workspace.switchDesktop
org.kde.workspace.closeWindow
org.kde.workspace.executeCommand
org.kde.application.amarok.shuffle (or some other own action that is not under 
org.kde.common.*)

when a new shortcut is registered it's checked for duplicates, if found the 
user gets asked what to do with it:
* forbid binding of the new one
* change the new one to something else
* change the old one to something else
* allow both to be active at the same time

with by default common winning over everything else and workspace winning over 
application or something like that

Cheers,
Marco Martin