I have established this forum topic for KDE Developers to coordinate enhancements to the core library, Plasma Desktop, and designer tools which add support for additional mouse buttons which are present on "gaming" mice and fully supported by X11 and qt.

Please don't post in this topic unless you're willing to WORK on the code and documentation. To suggest an idea which you would like someone else to implement, use the 'KDE Brainstorm' forum area instead Also, please note that I'm limiting this project to work with the buttons of traditional mice -- not touchscreens, not tablet pointers.

This work depends on successful resolution of my qtbug, http://bugreports.qt.nokia.com/browse/QTBUG-16092

(I intend to write and submit a patch for that bug shortly.)

If you would, please read this blog post I wrote for a detailed proposal on how I think this should be implemented:

A Matter of Control: The State of Input Device Support in KDE

There is also a more concise description of the proposal (with less about the rationale) in the bugs.kde.org wishlist item I submited a few years ago on the same subject: Bug 171295.

What I propose, in short, is an extension to the existing shortcut system, making it so other devices can submit shortcut events in addition to just the keyboard. Device support would be added in the form of plugins, allowing any hardware device anyone cares to support to be added. These wouldn't have to be pure hardware events, for instance voice recognition or gestures could be used, or even non-hardware events like a timer.


I looked into the code used by KDE for the shortcut system and mouse button handling a while back. The shortcut system is dbus-based, so it should be possible for other programs to submit dbus events of the sort that the shortcut system uses currently.


KDE's mouse button handling is pretty tightly coupled to how it is currently handled in Qt. For the most part it uses the same enums Qt does. However, a lot of methods in specific places are tied to specific buttons as presented by Qt.

There would probably need to be some sort of additional signals that solely return presses for buttons past 5, in order to avoid conflicts with signals that look for one of the standard 5 buttons. So we have left mouse press and release event signals, right mouse press and release event signals, middle mouse press and release event signals, scroll event signals. We would probably need to add to that something like n_button press and release event signals that are activated when a button over 5 is provided and give the button number (or enum, I guess). This would avoid conflict with existing signals for specific buttons. Having individual signals for each buttons does not scale, but relying solely on a set of general button event signals would break backwards compatibility.

There should probably also be more generic events that return button presses and button release events that respond to any button events (including wheel events) and give the button enum. A method that gives buttons but not wheel events would also probably be useful, e.g. for plasma.

You need to be careful of overrides or intermediate slots for existing button event signals that may not properly pass along additional button numbers. If I knew what the end goal was and what your changes were I might be able to help with this.

There is also an issue with naming. What are the buttons going to be called?

BlackCat,

I'm doing this as an "evolutionary", rather than "revolutionary", change in the current implementation. The interface between KDE and Qt will be unchanged, except that ButtonPressEvent and ButtonReleaseEvent will be able to indicate that the event has occurred with a much higher button number. (For a shortcut widget, we might need a new API call to query the maximum button number which the mouse provides- but that's a side issue, not the core Development.)

A switch to DBus would be "revolutionary", because X11 is fundamentally designed as a REMOTE Server... while DBus (right now) is tied to the local machine. The concept is straightforward, and X11 Devs are painfully aware of the issues which the Client/Server implementation creates... but your proposal is way bigger, and way more risky, than the project I'm doing.

In short, you've got a fascinating idea -- but it's not the project which I'm doing, the one for which forum topic will serve as an enhanced mailing list.

I've got a scheme to provide FULL support, while staying backward-compatible with the Qt 4.x series. (Old code would continue to work, with no need to recompile.)

"FULL support" includes MouseButtonPress, MouseButtonRelease, and MouseButtonDblClick for raw button numbers up to #32. (Although "raw" buttons 4,5,6, and 7 are translated into wheel scrolling events.) I'm also capable of adding a function which returns a 32-bit set of flags as an upgraded button State mask.

This would provide KWin, Plasmoids, and Applications to use combinations of *multiple buttons* as shortcuts.

Have you talked to any Qt developers about integrating such a patch or submitted a merge request on Gitorious?

bcooksley wrote:Have you talked to any Qt developers about integrating such a patch or submitted a merge request on Gitorious?

I recently became a 'Qt Developer', WRT these enhancements. The 'platform plugins' for XLIB and XCB have been committed already; with Wayland, I'm waiting for a bit more stability in the Wayland API.

Here is the new set of button names within Qt5:

enum MouseButton {
NoButton = 0x00000000,
LeftButton = 0x00000001,
RightButton = 0x00000002,
MidButton = 0x00000004, // ### Qt 5: remove me
MiddleButton = MidButton,
XButton1 = 0x00000008,
BackButton = XButton1,
ExtraButton1 = XButton1,
XButton2 = 0x00000010,
ForwardButton = XButton2,
ExtraButton2 = XButton2,
TaskButton = 0x00000020,
ExtraButton3 = TaskButton,
ExtraButton4 = 0x00000040,
ExtraButton5 = 0x00000080,
ExtraButton6 = 0x00000100,
ExtraButton7 = 0x00000200,
ExtraButton8 = 0x00000400,
ExtraButton9 = 0x00000800,
ExtraButton10 = 0x00001000,
ExtraButton11 = 0x00002000,
ExtraButton12 = 0x00004000,
ExtraButton13 = 0x00008000,
ExtraButton14 = 0x00010000,
ExtraButton15 = 0x00020000,
ExtraButton16 = 0x00040000,
ExtraButton17 = 0x00080000,
ExtraButton18 = 0x00100000,
ExtraButton19 = 0x00200000,
ExtraButton20 = 0x00400000,
ExtraButton21 = 0x00800000,
ExtraButton22 = 0x01000000,
ExtraButton23 = 0x02000000,
ExtraButton24 = 0x04000000,
MaxMouseButton = ExtraButton24,

};
Q_DECLARE_FLAGS(MouseButtons, MouseButton)

You see several 'alias' names in this list. I advise the following usage:

1: Use 'MiddleButton' instead of 'MidButton'.

2: Use 'BackButton' and 'ForwardButton' -- these names are more widely accepted and used than the alternatives (Xbutton1, Xbutton2, ExtraButton1,
ExtraButton2).

3. For all higher buttons, including the so-called 'TaskButton', use the
'ExtraButton_nn' name.

And do remember: This is upcoming in Qt5 ONLY; it will NOT be made available in the Qt 4.x Release Series.

Congratulations.
You have just solved (once KDE upgrades to Qt5 anyway) some of the longest standing feature requests.