Shortcuts via Mouse Buttons, etc.

Mario Fux kde-ml at
Fri Jan 6 16:26:21 GMT 2012

Am Dienstag 27 Dezember 2011, 22.53:21 schrieb Rick Stockton:

Morning Rick

> 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.

As there were no further mails to this thread and you seem to do some great 
work here (and on other lists) just go on as you seem the expert. If there is 
no further mail on this in the next days just do the work which is great I'd 
like to thank you.


More information about the kde-core-devel mailing list