Version: (using KDE 4.4.0) Installed from: Ubuntu Packages It would be very nice if KDE could provide a GUI to configure additional mouse buttons. While this is certainly system specific, from an end-user point of view, it would be a useful addition to KDE that would improve its competitiveness with respect to OS such as Windows. Under Linux at least, the infrastructure is already there and it is just a matter of integration. That might call for distrib-specific addition, however as few distribs take KDE as their primary desktop, it would help to implement this feature upstream. Existing software to provide this feature exists, for instance: - btnx (http://www.ollisalonen.com/btnx/) - easystroke (http://sourceforge.net/projects/easystroke/) KDE currently provides gesture detection. While I understand that, because gesture recognition does not depend on the underlying hardware, it is easier to implement than multiple mouse buttons. Yet, from the user perspective, gestures are just a toy while multiple mouse button would really bring a benefit.
We would need the custom mouse configuration. Maybe by the way you first click all the buttons in wanted order (left, middle, right, wheel up, wheel down, back, forward, extra 1, extra 2, extra 3) and then you can select from dropdown list a wanted features for every one of them or bind own shortcuts etc.
I guess systemsettings is the right component for that report. In any case, kst is *not*. kst is a plotting tool! The idea sounds cool, it would be a pity if it passes unnoticed because it's attached to the wrong place.
I don't know how kde's "bug arbitrage" works, but comment 2 should have led to an action item. kst@kde.org is not the correct assignee, this bug needs to be re-assigned. With regard to the topic in question, I have comments. The fundamental problem lies in qt, which refuses to support the X11 button press/button release events which are emitted with "big-numbered" buttons. Since KDE tries to use qt as a wrapper for native mouse I/O (X11, win32, etc.), it needs to be done there. This bug, asking for a GUI to remap the buttons, depends on bug 34362 (the bug to actually IMPLEMENT all these "extra" buttons). Once the buttons are supported, it's very easy to provide the GUI -- we'll just be creating GUI programs to put wrappers around the "xmodmap" program. Gestures are related, but they're not implemented in the same way. I understand why a user would expect them to be together, but they should probably be as two separate little programs: first map your buttons, THEN define your gesture preferences.
I explain my decision to mark this bug as a duplicate: The description refers to software (e.g., easystroke) which translates mouse events into keyboard sequences. Such a change WILL NOT be acceptable to the Maintainer and relevant Reviewers of Qt. (I asked, during the time when I was creating support for more mouse buttons.) And so, mouse buttons as shortcuts, and/or mousebuttons within "shortcut sequences" is the possible enhancement. Fri13 gave an excellent example of a GUI for defining such a "sequence". Bug 96431 is the relevant BugID for such requests. I note that wheel actions are not the same as buttons, and not the same as gestures either. But those "Wheel" events perhaps SHOULD be included, along with "Mouse Events", in a GUI of the type described by Fri13. When it comes to implementation, I'm closing this as a duplicate of 96431, although some aspects of Bug 171295 may apply as well. 96431 has upstream prerequisites, in Qt. *** This bug has been marked as a duplicate of bug 96431 ***
slight mistake: this can be left "Open", with "Depends On 96431".
while we are at it... there are some very compact keyboard and touchpad combos out there, e.g. by Rapoo Inc., which require a way to disable the touchpad, which shows in xinput as a mouse, in order to be able to type without accidental touches on the pad being located right next to the enter-key. currently, a scheme.khotkeys file can be imported to use like F1 and F2 to do this. But when KDE drops the whole "KCM Shortcuts" due to lack of maintainers, a gaping usability problem will suddenly rip open!
As announced in https://pointieststick.com/2023/07/26/what-we-plan-to-remove-in-plasma-6/ and https://community.kde.org/Plasma/Plasma_6#Removals, I'm afraid KHotKeys has reached end-of-life in Plasma 6. Accordingly, all bug reports and feature requests for it must be closed now. Most of what KHotKeys could do can already be done with the newer KGlobalAccel system in Plasma 6. A few features such as mouse gestures and triggering conditions based on changes to window states are not yet implemented in the new system. These will be added in the future if and when resources materialize for them, and/or when a kind soul submits patches to implement them! :) Meanwhile, the 3rd-party "Mouse Actions" app (https://github.com/jersou/mouse-actions) may be usable for implementing your own mouse gestures again. Thanks for your understanding, everyone.