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 :))