Rethinking global shortcuts

[Rick Stockton]

My only comments are at the bottom, and semi-OT.


On 02/07/2013 05:51 AM, Aaron J. Seigo wrote:
> On Thursday, February 7, 2013 14:32:06 Marco Martin wrote:
>> So an application could listen for global named shortcuts and then register
>> own if those are not enough
> +100
>
>> 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.*)
> nice idea indeed.
>
> though i wonder if we need reverse domain for everything, including built-ins? 
> applications and add-ons would then use reverse domain to avoid collision. sth 
> like:
>
> media.forward
> workspace.*
> org.kde.amarok.shuffle
>
> this is more terse, and prevents the "oddness" of a Qt or other application 
> needing to use "org.kde.common.media.forward". 
>
> if we are concerned about collisions with someone having "media.forward" as a 
> reversed domain (unlikely imho), we could simply preface with a '.' as in 
> ".media.forward"
>
>> when a new shortcut is registered it's checked for duplicates, if found the
>> user gets asked what to do with it:
> i'm concerned this will create a new source of notification spamming, followed 
> by the need to figure out a complex question and give an answer. i just see 
> this annoying more people than helping .. particularly as some people may not 
> even be aware (or care) that some applications have shortcuts. 
>
> so if we can at all avoid bothering the user ...

I imagine that this problem would occur only once per "already taken!"
shortcut with a given application: When it attempts to create a
conflicting App-level shortcut, there are really only 3 choices:

A: this application shortcut should override the "higher-level" default,
but only within THIS application. --> create an
"org.kde.applicationID.shortcutname" with that value, and store it into
the table. More-specific reverse lookups have priority.

B: an alternate shortcut should be used, please enter/select it (and if
it is also a duplicate, go back to [A:] with the provided value.

C: this application should never define a value for that shortcut
(create an entry in the lookup table, and set it to a value with the
meaning "not to be used", which won't match any keyseqence or mouse
input event).

- - - - -

Now, I'd like to advise you of something going into Qt 5.0.2. (It 's
mostly present in 5.0.1, but still borked on Cocoa/Darwin):
Qt::MouseButtons in any event will contain actual State of ALL pressed
mouse buttons, not just LeftButton MiddleButton RightButton. So, we have
a possibility of adding large number of "mouse shortcuts" with various
buttons in held down state while another is clicked or double-clicked
(excluding, of course, hold of the "gestures" button). I'd like to see
that in KF5, between two "semi-confused" BugID's, and their Dups, it's
definitely top-20 among our RFEs.

The problems are : I have no idea how to do the UI, and perform the
invocation.