Qt5: ‘QMouseShortcut’ and ‘QMouseShortcutEvent’ Classes [ABANDONED]
The purpose of these classes would be to provide support to KDE for many feature requests- requests which ask that mouse buttons be configurable as shortcut Invocation tools, in a way analogous to QKeySequence keystroke combinations.
I have considered making an attempt to configure buttons into QKeySequence itself, and dislike that approach for 3 reasons:
- QKeySequence is already quite complex for users to deal with; adding Mouse Click, DoubleClick, and (especially!) the holding of one mouse button while clicking ANOTHER mouse button into QKeySequence definitions would be awkward. Powerful, yes. But AWK!
- The Class itself is large and complex, because Qt supports many keyboard layouts. I am simply incapable of enhancing that Class in such a big way, without huge risk of introducing Bugs. (I’m simply not good enough to program all of that.)
- At the UI level, in KDE, Configuration of ‘KHotkeys’ and the ‘Configure your Mouse’ applications are already separate. It would be another large effort in KDE, to put these separate programs together as one module.
In my own mind, I can’t justify the creation of a large, complex, keyboard+mouse combination. Handling shortcuts with the mouse alone, NOT involving the keyboard, seems about 80% sufficient for everything I personally want. (Especially because I’m including Doublick versus Click as separate Shortcut-able Input actions, and with “hold one button, click another” capability providing nearly another full set of ‘virtual buttons’ as Shortcut-able Input actions.) Besides, I don’t have adequate programming skills to do the job. Within Qt5, this needs to be FINISHED in about 3 weeks, in order to fit with the Qt 5.0 Development schedule, there’s no way for me to understand, code and test modifications to the large and complex Classes which control the Keyboard logic..
There is another, completely different idea on the Table, which would present the shortcuts as DBUS messages. I may have the wrong impression of that scheme, but feel that it would take over at the shortcut Messaging level using DBUS as an alternative to Qt Signals/Slots. It would not be using D-Bus at the low level recognition of QKeySequence sequences, and Qt MouseEvent recognition of shortcut button events and combinations. I feel that DBUS messaging at either the character-by-character Keyboard Event layer, or it’s mouse button equivalent, would be too slow, creating massive delays and overhead.
If I’m correct about this other Idea, then it could be done at a later time— still building upon current ‘QKeySequence’ and QMouseShortcutEvent’ processing for doing work at the high throughput, low overhead Device Input layers. If I’m wrong, then someone else needs to step up immediately- because I can’t, and won’t even try, to re-program the shortcut system with D-Bus working at low-level input event layers of Qt. IMO, it’s too radical, AND I’m not smart enough to do that.
Here are some reference bugs from KDE:
https://bugs.kde.org/show_bug.cgi?id=96431 (Shortcuts in general.)
https://bugs.kde.org/show_bug.cgi?id=48062 (Now limited to a particular A18 feature; most of the votes were actually for Bug 96431).
https://bugs.kde.org/show_bug.cgi?id=34362 (The prerequisite, already done in Qt5, to support ALL of the buttons on ‘gaming’ mice.)
And, here is a reference to the D-Bus idea (which I plan to ignore, sorry):
- One goal of this feature would be better A18 (accessibility features). This item, KDE bug 48062, calls for mouse button events to Toggle keyboard modifiers- allowing both one-handed and zero-handed KDE Users to take their time in executing a KEYBOARD Modifier-Key sequence, while pressing with only one finger (OR equivalent button pressing tool) at a time.
Any comments, ideas, or advice on YOUR issues- PLEASE feel free to add a post to this Thread, I WILL read everything! (Todd, inventor of the D-Bus concept- that especially goes for you. Please chat here!) And if there are any volunteers to Lead, or to assist me in stumbling around with this code, my special thanks- in advance :))
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.