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. _______________________________________________ Plasma-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/plasma-devel
