Shortcuts via Mouse Buttons, etc.
Rick Stockton
rickstockton at reno-computerhelp.com
Tue Dec 27 21:53:21 GMT 2011
Partly in reply to Albert Astals Cid and Thomas Zander, on the KDE list
(December 26):
I am aware of the timing requirement (But Thomas- thanks for the
reminder, in case I HADN'T been.) Since I'm the person who will write
the code and doco, I HAVE TO have an idea how to make it work ;) I've
looked at some existing code, and I see two ways to get this done. One
is a variation of my original thinking, and comes from the inventor of
Qt Shortcuts and KeySequence management. The other suggestion, also from
one of the greatest Qt experts, is quite unexpected, and looks plausible
too:
(Alt 1) Slightly higher risk of falling on my face, but "better
integration": Create a QInputSequence Class (The current QKeySequence
class would exist as a keyboard-only instance within the new, larger
class.) An input sequence could include keys which are simultaneous with
a mouse button State (the full State of all buttons, not just the XI 1.0
mask of Buttons 1-5). And ultimately, "InputSequence" could support
events from other devices as well.
(Alt 2) A shockingly easy kludge to write, but less ensible in concept:
Just derive one (at most, two) new Classes from QGesture. Right now
(4.8) we have QSwipeGesture, QTapGesture, and so on ... which are
invoked, on a traditional Desktop, with one mouse button in pressed
State. I could add QMouseButtonGesture, or extend Swipes and Taps to
have Button State properties. Just about everything above is already
built! But... is it just too weird for me to give people the option of
handling buttonpress, buttonclick, and buttondoublelick (with single AND
multiple buttons buttons) via 'gestures', as an alternative to the
normal 're-implement Widgit Mouse Event handlers' and scene-based mouse
programming schemes which we all use now?
Approach #1 stays focused on Shortcuts, AND allows for future device
classes to be added via 'Copy and Paste a device instance, then modify'.
But my scheme for #2 would also give us the ability to create multiple
instances of Gestures from the same motion (e.g., horizontal swipe),
differentiated by button number. That's a pretty powerful upgrade too.
Your votes? I'm favoring #1, even though it's possibly a bit harder,
because #2 is so strange. And #1 can have a 5.x upgrade to add the TV
remote control, or whatever, while #2 is pretty much stuck with gesture
input ONLY.
More information about the kde-core-devel
mailing list