<div class="gmail_quote">On Fri, May 11, 2012 at 8:10 PM, Rick Stockton <span dir="ltr"><<a href="mailto:rickstockton@reno-computerhelp.com" target="_blank">rickstockton@reno-computerhelp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, 10 May 2012 23:21:25 +0200, <a href="mailto:markg85@gmail.com" target="_blank">markg85@gmail.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Making this quite detailed and long mail as per request from David Faure<br>
(twice);)<br>
<br>
So, I've been patching KShortcut up to support multiple shortcuts:<br>
<a href="https://git.reviewboard.kde.org/r/104801/" target="_blank">https://git.reviewboard.kde.<u></u>org/r/104801/</a> and it's working just fine with<br>
that patch. However, there seems to be some duplication between:<br>
KAction - QAction<br>
<a href="http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKAction.html" target="_blank">http://api.kde.org/4.x-api/<u></u>kdelibs-apidocs/kdeui/html/<u></u>classKAction.html</a><br>
<a href="http://qt-project.org/doc/qt-4.8/qaction.html" target="_blank">http://qt-project.org/doc/qt-<u></u>4.8/qaction.html</a><br>
<br>
KShortcut - QShortcut<br>
<a href="http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKShortcut.html" target="_blank">http://api.kde.org/4.x-api/<u></u>kdelibs-apidocs/kdeui/html/<u></u>classKShortcut.html</a><br>
<a href="http://qt-project.org/doc/qt-4.8/qshortcut.html" target="_blank">http://qt-project.org/doc/qt-<u></u>4.8/qshortcut.html</a><br>
<br>
So lets go back to the basics here and see what is actually required<br>
(K/Q)Action in KDE.<br>
- QAction functionality as a base<br>
- Global shortcuts<br>
- Reset to defaults<br>
<br>
</blockquote></div>
I'm not sure that 'QAction' classes are a sufficient result. Would there be advantages to an event-based structure? IIRC, Qt has gone both ways (Gestures-->Actions, but Shortcuts-->Events-->Actions). I think that the events are better for listening, especially since Qt tries to manage Pointer Focus auto-magically. (And it's propagation decisions, from children to parents, are pretty much flawless.)</blockquote>
<div><br></div><div>I don't understand you here. Please do clarify. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't know what setShapeGesture and setRockerGesture are supposed to be<br>
since they have 0,0 documentation. So i'm assuming (for now) that they are<br>
useless.<br>
</blockquote></div>
Gestures become a "bigger deal" in Qt 5.x, of course.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
As for "reset to defaults", i don't think that should be stored in a<br>
KAction abject. That feature is only usable in the Shortcut Editor<br>
(assumption) so having this for every single KAction in all KDE<br></div>
applications is a bit strange. Since the KAction has a name as well (back<div class="im"><br>
button, forward button ... just look at Shortcut Editor) it becomes fairly<br>
easy to simply store the default shortcuts in some config (KConfig stuff)<br></div><div class="im">
file somewhere. So we don't need "Reset to defaults" in KAction. That only<br>
leaves Global shortcuts that are not base functionality thus have to be<br>
added.<br>
<br>
Note: i actually suggested the inclusion of global shortcuts in Qt by<br>
default. Sadly my knowledge and time was way to limited to implement that.<br>
If it had been implemented then we could have completely dropped KAction<br>
and KShortcut. Right now it's on the "radar" of the Qt devs (Thiago<br>
actually) but i don't know if this is something that will come in Qt 5.1.<br>
Not really expecting it actually.<br>
</div></blockquote>
If Qt "Glbal Shortcuts" will ever be done, it will be done by us (and in the 5.1 timeframe, I think.) There's certainly great maintenance and programmer/user training benefits in having fewer layers and classes implementing "shortcuts" and their supporting/resulting behaviors. But the two big things which KDE has, and Qt doesn't, are<br>
#1 persistent storage of users' Shortcut config info, separate from the programs and program libraries;<br>
#2 A GUI to modify those shortcut lists (or, as you have noticed as an "issue" in KDE, the single item key/value pairs.)<br></blockquote><div><br></div><div>True</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"Global shortcuts" require, at a minimum, the first of these things, with a fully documented schema for defining the storage contents. The second could be a user application (written in Qt, or written in KDE.) A new feature, which _could_ be added as well, would be to notify running applications of Shortcut changes- Global, and application specific, via DBUS or equivalent.<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
KAction is now defined:<br>
- QAction as base<br>
- add functionality for global shortcuts<br>
<br>
Global shortcuts are another story. There is KShortcut, but i really don't<br>
see a point in keeping the current "primary/alternate" (thus only 2<br>
shortcuts) option alive or even supported. I above mentioned patch in<br>
reviewboard is already adding support for multiple shortcuts.For frameworks<br>
i actually want to go a step further. Or a big jump.<br>
<br>
Completely get rid of KShortcut and introduce 2 new classes:<br>
- KInputShortcut<br>
- KInputSequence<br>
<br>
Right now it's not possible to make shortcuts that use both your mouse keys<br>
and your keyboard keys. For example keeping control pressed and pressing<br></div>
the mousebutton - something that on windows is quite frequently used to<br>
select some fiels (like in excel),.<br>
</blockquote>
To me, this looks like a violation of Layers: hardware belongs to Qt, except where the WM (Kwin, in our case) needs to intercept raw events BEFORE they get to windows (for window-switching and desktop-switching shortcuts.) More importantly- this particular combination (and other combinations of mouse button + MODIFIER KEYS on the keyboard) - don't need to look at Keyboard events separately: We're given a mask of modifier key States within the Button Event signatures. Mouse button plus a "normal" key Event is way different of course. I wouldn't want to go there.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And so, although you're paying attention to the keyboard, touching what you're talking about is purely mouse shortcuts - using the pointer device by itself. (One-handed, not two-handed.) I've been thinking about this for Qt 5.1. It corresponds to two of our all-time, top-20 RFE's: <a href="https://bugs.kde.org/show_bug.cgi?id=96431" target="_blank">https://bugs.kde.org/show_bug.<u></u>cgi?id=96431</a> (shortcuts in general) and <a href="https://bugs.kde.org/show_bug.cgi?id=48062" target="_blank">https://bugs.kde.org/show_bug.<u></u>cgi?id=48062</a> (now re-defined as a particular A18n feature... most of the comments and votes were really asking for # 96431.) That should be our #1 priority, I think.<br>
</blockquote><div><br></div><div>Ahh, so you're already working on this for Qt 5.1! Nice to know. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
== KInputShortcut ==<br>
The same ashttp://<a href="http://qt-project.org/doc/qt-4.8/qshortcut.html" target="_blank">qt-project.org/doc/<u></u>qt-4.8/qshortcut.html</a> only with input<div class="im"><br>
from all attached devices.<br>
<br>
== KInputSequence ==<br></div>
The same ashttp://<a href="http://qt-project.org/doc/qt-4.8/qkeysequence.html" target="_blank">qt-project.org/doc/<u></u>qt-4.8/qkeysequence.html</a> only with<div class="im"><br>
input from all attached devices.<br>
</div></blockquote>
I don't like the idea of extending a more specific QKeySequence class into a LESS-SPECIFIC, MORE GENERAL child class. And I don't like mixing all input devices together. We have QKeySequence separate from QGesture, and I think we should do the same for Button Clicks: Add a new, specific class, "QMouseSequence". And possibly re-factor, creating a new parent for both QKeySequence and QMouseSequence, and making that new Class the working "friend" of QShortcutMap?<br>
<br>
But in any case, I' feel that I'd like the Mouse Shortcuts to create instances of "QMouseShortcutEvent" on the focused widgets and surfaces. Does this sound good to you, or should we attempt a "pure KDE" resolution?<div class="im">
<br></div></blockquote><div>I have a slightly different opinion here. Yes, in reality the *Sequence and *Shortcut classes are just Keyboard and Mouse, but i'd like to give them a generic name. Thus "InputShortcut" and "InputSequence" prefixed by either a "K" or a "Q" depending on where it's going to be placed (In Qt or KDE). My intention would be to first do this in KDE since the Qt 5.1 release is still quite far away and doing this in KDE first allows me (us) to see if there aren't any nasty side effects of doing it this way before adding it to Qt. But sure, you're solution works just as fine as well even though your suggested QMouseSequence is going to do more and also accept keyboard keys.. That might be a bit confusing since the name doesn't imply that.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Back on the global shortcuts for a second. I might be hitting a little snag<br>
there. How are we going to tell that a shortcut is global?<br>
Perhaps like this:<br>
QList<KInputShortcut><br>
And a getter and setter for KInputShortcut:<br>
bool KInputShortcut::isGlobal()<br>
KInputShortcut::setGlobal(<u></u>bool)<br>
<br>
The list would be passed in<br>
KAction::setShortcuts(const QList<KInputShortcut>& shortcuts).<br>
<br>
However, doing this would be easier but you lose the option to set a global<br>
shortcut:<br>
KAction::setShortcuts(const QList<KInputSequence>& shortcuts)<br>
<br>
So (for now) i would say: getters and setters for both KInputSequence<br>
and KInputShortcut. Not very sure about this part yet. If KInputShortcut is<br>
used then the user can provide the option to make it global or not.<br>
If KInputSequence is used then the shortcut is just as is and is local<br>
only. Not a fact, just my idea.<br>
<br>
As for the current KShortcut and KAction. If you all like this idea and<br>
would include it in frameworks if implemented correctly then i would like<br>
to fully deprecate KShortcut in KDE 4.9 (removed in frameworks) and partly<br>
deprecate KAction where needed. If this idea is accepted then i'm not very<br>
sure about my earlier patch anymore. Since that seems somewhat temporary if<br>
we go by this new structure thus making my other patch(es) useless.<br>
</blockquote></div>
The fundamental question is: create a scheme for Qt to have dynamic, persistent storage of 'Global Shortcuts', or simply extend the current KDE scheme with a new "Class" of of shortcuts? KCM already separates "Gestures" under the label "Custom Shortcuts". The design which I would propose contains:<br>
<br>
(1) "Standard Shortcuts", including (1A) standard keyboard shortcuts; (1B) standard gestures (if any); and (1C) standard mouse shortcuts (if any). These would be designated by a HIG team, not the programmer.<br>
(2) "Global Shortcuts", with the same sub-categories. standard values should be pre-defined for many actions, but I don't think we should have separate GUI categories for standard versus custom Global Shortcuts.<br>
(3) Custom Shortcuts (for specific programs).<br></blockquote><div><br></div><div>Yes and no. I would threat keyboard and mouse equally since you use them simultaneous as well (one hand on the keyboard, one on the mouse..). So imho it should be like this:</div>
<div><div>1 "Standard Shortcuts"</div><div> .. 1A Input Shortcuts (keyboard and mouse)</div><div> .. 1B Gestures</div><div><br></div><div>2 "Global Shortcuts"</div><div> .. 1A Input Shortcuts (keyboard and mouse)</div>
<div> .. 1B Gestures</div><div><br></div><div>3 "Other Shortcuts"</div><div> .. 1A Input Shortcuts (keyboard and mouse)</div><div> .. 1B Gestures</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, I think that the KCM shortcut scheme needs a complete rewrite: In addition to viewing and modifying shortcuts by type, I think that we need to offer Users the ability to view ALL shortcuts which are effective on a specific program, and also view ALL shortcuts (across all programs) invoked by specific QKeySequence, KKeySequence, QGesture, KGesture, QMouseSequence, or KMouseSequence invocations. (Assuming that the creation of persistent, but dynamic, shortcuts and equivalent "seqences" within maic but "Global olbal<br>
<br>
What do I mean by a "MouseSequence"? It's a button event (button press or doubleclick) with optional keyboard modifiers, AND with optional "mouse modifiers". The mouse modifiers are those 3 keys which are given to us with every Mouse Event, in the "State" byte. (LeftButton, RightButton, and MiddleButton). Holding RightButton down, while clicking another button (e.g. ForwardButton) constitutes a different QMouseSequence than clicking the button alone. (With a gamer mouse like mine, this helps to provide for a very large number of unique "QMouseSequence" instances.)<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To get all of this working is quite a bit of work and certainly by no means<br>
easy for me! But i like to do this so why not:) And i have some free time<br>
the coming weeks so right now is the best time to do this.<br>
</blockquote>
<br></div>
And so, I feel that this is not KDE-only, and not short-term: It involves new QT Classes and API, targeting 5.1 and KDE frameworks at a level based on that Qt. I also feel that the specific list of default mouse shortcuts should be designed first, by HIG people. Let's focus on an optimal UI first, for both shortcut usage (in production, under the hands) _and_ for shortcut management (giving KCM more "View" capabilities, not just more "Controller" capabilities.)<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I did do a bit of brainstorming in here while typing. I hope it's all clear.<br>
</blockquote></div>
And you did a great job, thanks!<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please do give your opinion/input on how we should proceed with this.<br>
</blockquote>
Cheers, Mark<br></div>
______________________________<u></u>_________________<br>
Kde-frameworks-devel mailing list<br>
<a href="mailto:Kde-frameworks-devel@kde.org" target="_blank">Kde-frameworks-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/kde-frameworks-devel</a><br>
</blockquote></div><br><div>So, to sum it up.</div><div>1. There really is a big preference to get combined input (keyboard and mouse) in Qt and not in KDE. You (rick) are even working on that and it should (or could) land in Qt 5.1.</div>
<div>2. There needs to be a HIG designed standard for a range of predefined keyboard shortcuts in Qt, not KDE.</div><div>3. There needs to be some way of storage for keys, give them a default value and restore that value on the user request. This is what KDE has with Shortcut Editor. The app itself should not be in Qt, but the storage of the data should live in Qt to make it platform independent.</div>
<div><br></div><div>Once the above 3 things are done then the following can be done in KDE</div><div>1. Full deprecation of KAction and KShortcut in frameworks</div><div>2. Shortcut Editor to be based on Qt's standard keys dataset which should be designed by a HIG.</div>
<div>3. Let all KDE SC apps use QAction and Q_something_Sequence, Q_something_Shortcut rather then KDE specifics.</div><div><br></div><div>I personally do not want make the Qt specific parts. It's simply way to difficult for me to start. Qt doesn't even have a 5.0 final release yet. I just like to stay away from it till that is done. I do want to work on the KDE parts.</div>
<div><br></div><div>As for making a "HIG" keyboard standard list. A very good starting point is:</div><div><a href="http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts">http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts</a>
</div><div><br></div><div>Every single line where the same key combination is used in both: Windows, Mac, KDE en GNOME can be considered as de-facto standard key imho. Though the list has to be viewed with care since the very first item "Activate current application's Menu bar" is already wrong for KDE. It's not just ALT. It's ALT + M iirc.</div>
<div><br></div><div>While looking at that wiki list i'm quickly realizing that we're never going to get a standard keyboard + mouse mapping for generic keys across all major desktop environments.. Perhaps this should (sadly) be platform specific thus probably be done through the Qt platform plugins... And this is certainly not going to work in a few weeks..</div>
<div><br></div><div>Cheers,</div><div>Mark</div>