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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
