On Thu, 10 May 2012 23:21:25 +0200, mark...@gmail.com wrote:
Making this quite detailed and long mail as per request from David Faure
(twice);)
So, I've been patching KShortcut up to support multiple shortcuts:
https://git.reviewboard.kde.org/r/104801/ and it's working just fine with
that patch. However, there seems to be some duplication between:
KAction - QAction
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKAction.html
http://qt-project.org/doc/qt-4.8/qaction.html
KShortcut - QShortcut
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKShortcut.html
http://qt-project.org/doc/qt-4.8/qshortcut.html
So lets go back to the basics here and see what is actually required
(K/Q)Action in KDE.
- QAction functionality as a base
- Global shortcuts
- Reset to defaults
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.)
I don't know what setShapeGesture and setRockerGesture are supposed to be
since they have 0,0 documentation. So i'm assuming (for now) that they are
useless.
Gestures become a "bigger deal" in Qt 5.x, of course.
As for "reset to defaults", i don't think that should be stored in a
KAction abject. That feature is only usable in the Shortcut Editor
(assumption) so having this for every single KAction in all KDE
applications is a bit strange. Since the KAction has a name as well (back
button, forward button ... just look at Shortcut Editor) it becomes fairly
easy to simply store the default shortcuts in some config (KConfig stuff)
file somewhere. So we don't need "Reset to defaults" in KAction. That only
leaves Global shortcuts that are not base functionality thus have to be
added.
Note: i actually suggested the inclusion of global shortcuts in Qt by
default. Sadly my knowledge and time was way to limited to implement that.
If it had been implemented then we could have completely dropped KAction
and KShortcut. Right now it's on the "radar" of the Qt devs (Thiago
actually) but i don't know if this is something that will come in Qt 5.1.
Not really expecting it actually.
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
#1 persistent storage of users' Shortcut config info, separate from
the programs and program libraries;
#2 A GUI to modify those shortcut lists (or, as you have noticed as
an "issue" in KDE, the single item key/value pairs.)
"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.
KAction is now defined:
- QAction as base
- add functionality for global shortcuts
Global shortcuts are another story. There is KShortcut, but i really don't
see a point in keeping the current "primary/alternate" (thus only 2
shortcuts) option alive or even supported. I above mentioned patch in
reviewboard is already adding support for multiple shortcuts.For frameworks
i actually want to go a step further. Or a big jump.
Completely get rid of KShortcut and introduce 2 new classes:
- KInputShortcut
- KInputSequence
Right now it's not possible to make shortcuts that use both your mouse keys
and your keyboard keys. For example keeping control pressed and pressing
the mousebutton - something that on windows is quite frequently used to
select some fiels (like in excel),.
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.
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:
https://bugs.kde.org/show_bug.cgi?id=96431 (shortcuts in general) and
https://bugs.kde.org/show_bug.cgi?id=48062 (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.
== KInputShortcut ==
The same ashttp://qt-project.org/doc/qt-4.8/qshortcut.html only with input
from all attached devices.
== KInputSequence ==
The same ashttp://qt-project.org/doc/qt-4.8/qkeysequence.html only with
input from all attached devices.
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?
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?
Back on the global shortcuts for a second. I might be hitting a little snag
there. How are we going to tell that a shortcut is global?
Perhaps like this:
QList<KInputShortcut>
And a getter and setter for KInputShortcut:
bool KInputShortcut::isGlobal()
KInputShortcut::setGlobal(bool)
The list would be passed in
KAction::setShortcuts(const QList<KInputShortcut>& shortcuts).
However, doing this would be easier but you lose the option to set a global
shortcut:
KAction::setShortcuts(const QList<KInputSequence>& shortcuts)
So (for now) i would say: getters and setters for both KInputSequence
and KInputShortcut. Not very sure about this part yet. If KInputShortcut is
used then the user can provide the option to make it global or not.
If KInputSequence is used then the shortcut is just as is and is local
only. Not a fact, just my idea.
As for the current KShortcut and KAction. If you all like this idea and
would include it in frameworks if implemented correctly then i would like
to fully deprecate KShortcut in KDE 4.9 (removed in frameworks) and partly
deprecate KAction where needed. If this idea is accepted then i'm not very
sure about my earlier patch anymore. Since that seems somewhat temporary if
we go by this new structure thus making my other patch(es) useless.
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:
(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.
(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.
(3) Custom Shortcuts (for specific programs).
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
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.)
To get all of this working is quite a bit of work and certainly by no means
easy for me! But i like to do this so why not:) And i have some free time
the coming weeks so right now is the best time to do this.
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.)
I did do a bit of brainstorming in here while typing. I hope it's all clear.
And you did a great job, thanks!
Please do give your opinion/input on how we should proceed with this.
Cheers, Mark
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
