KAction and KShortcut in frameworks

[Rick Stockton]

Mark, your responses improve on my ideas, and leads to a more solid 
"shared vision". (That's Awesome!) Here's a "brain dump" of my thoughts 
- some responding to you, some others not yet discussed:

Within Qt, there are a couple of reasons why I don't want to create a 
generic "all-shortcuts" set of Classes. There are two reasons behind my 
preference:

*FIRST REASON: * The "input evt. matches a shortcut" determination 
differs a lot. With Gestures, we need to instantiate intermediate 
gesture-recognition Classes. (Qt "Gestures", on a mouse device are, are 
only recognized by holding a particular mouse button in pressed State 
during a drag.) With Keyboard shortcuts, we use a binary search of a 
single large table (i.e., the QKeySequencePrivate::keyBindings[] array 
to match on QKeySequence::StandardKey. It's very fast, sorting on the 
modifier bits as primary, and sorting on the actual Qt::Key value as 
secondary. (It's like a "wide" integer field, with the modifier keys 
setting high-order bits.) Mouse shortcuts, in my view, are a lot more 
like keyboard shortcuts:

- they support KEYBOARD modifier keys.
- they also support mouse button modifiers, held down while another 
button is clicked or double-clicked. (LeftButton, RightButton, or 
MiddleButton).
- But, unlike QKeySequence-based shortcuts, the mouse has only a very 
small number of possible non-modifier buttons. (Generally less than 16, 
it varies according to platform.)
- And also, one of the "modifier buttons" (Qt::MiddleButton) could be 
used as a shortcut all by itself. (Not LeftButton or RightButton, they 
do other things.)

However, because the button number is the most basic property of the 
click or double-click event, I'm inclined to use that as my high-order 
sort key (The Qt::MouseButton bit value). Then, within the following 32 
bits, we have the button mask State (but using only 3 of the 5 "buttons- 
ignoring the wheel-up and wheel-down "buttons") and the keyboard 
modifiers. This is a simple Class, because I'm not seeing a need for 
platform-dependent "StandardKey" equivalents - situations where we want 
one ButtonSequence, on OS-X, do _always_ do the exact same thing as 
another ButtonSequence on Windows (or Gnome, or KDE Desktop.) Does 
anyone disagree? Because I need to know of such a requirement right 
away. Don't forget that Windows only supports 5 non-wheel buttons, 
that's a pretty severe limitation which won't be present on other 
platforms. So maybe we need a "StandardButton" implementation, for the 
sake of providing some different mouse-shortcut assignments on 
Applications running under Windows (versus the same applications running 
on "smarter" platforms).

*SECOND REASON: * Smarter people than I chose to separate "Gestures" 
from the Keyboard-Based shortcuts, almost completely. I'm inclined to 
follow that strategy again. Some of the "magic" with QKeysequence and 
QShortcutMap is quite ciomplicated and breakable, so I'd prefer to touch 
them as little as possible. This also follows for other devices:

*THIRD REASON* Qt5 Widgets can't support multiple pointer focus (and 
never will). So future shortcut Device Support is more like additional 
keyboards, and less like additional mice or touch screens. Joysticks 
have relatively few buttons, and they don't point as accurately as mice, 
and they are large/inconvenient.  (My own Logitech Joystick, IIRC has 6 
buttons. My Logtech mouse has 10, and it scrolls vastly better.) I think 
that Joystick is permanently DOA as a QT5 input device.

Devices which could be supported, in a manner much like "alternate 
keyboards", include things such as TV remote controls (IR). They provide 
an awful lot of buttons, but would need implementation through the 
entire hardware stack. (X11/XCB, Wayland, and etc.; plus proprietary 
Windows, OS-X, etc. where I can't/won't submit code myself.) That's a 
future item, and IMO of far less value than multiple pointer focus (== 
two mouse devices on the same Desktop, or even within the same Window; 
that's QT6 or later.)
- - - - -

Changing topic, getting back to a question of yours: Per above, when I 
talk about a 'QButtonSequence', the fact that a 'QButtonSequence' may 
have Keyboard Modifiers _as portion of the sequence definition,_ is 
already built-in. So is the use of optional Qt::LeftButton, 
Qt:RightButton, and Qt::MiddleButton as "mouse modifiers". We both saw 
the need for Keyboard Modifiers right away ;)
- - - - -

At the next layer, I plan to implement 'QMouseShortcutMap'. This is the 
layer at which I would implement the "guts" of Shortcut definition. Each 
entry contains a reference to a QMouseSequence table entry, but a given 
physical QMouseSequence would be able to appear in many Map entries. (It 
will be analogous to the struct QShortcutMap::QShortcutEntry.) Some 
issues which are a concern in the keyboard-oriented QShortcutMap won't 
be relevant. I imagine that KDE Frameworks Classes and Applications will 
request the creation of new entries from this Class, rather than the 
underlying QMouseSequence API. Reading in a table of new entries from 
persistent storage (re-read of default values, 'Global' Runtime 
initialization, and App initialization of specific Shortcuts) ... a lot 
of that will happen here, if we attempt to push it downwards into Qt. 
Otherwise, KDE will want to initialize application in the same manner 
which it does now: Reading shortcuts from KDE-defined persisent storage, 
and/or API defaults, and tossing a bunch of QMouseSeqence::AddSequence() 
requests into my class.

Mark, David, and other interested KDE "shortcut" experts: Please take a 
look at Qt's QShortcutMap class, and see if the scheme I'm proposing 
would meet your needs. If so, I'll start preparing API -- but remember 
that my scheme is a multi-month project for Qt 5.1, and definitely 
doesn't fit the 4.9 time frame. You could undertake _two_ projects, of 
course....

BTW, I must remind you all, since this sounds somewhat competent: I know 
almost nothing about KDE's API and strategic goals; and even _less_ 
about programming. I only "play around" with mice in my spare time.