[Development] Shortcuts via Mouse Buttons, etc.

Rick Stockton rickstockton at reno-computerhelp.com
Tue Dec 27 22:53:21 CET 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 Development mailing list