31 mouse buttons - a proposal for Qt 5.0; IT'S DONE, IT'S IN THERE :))
-
This replaces my 4.x Proposal, which was titled "I have a way to support ALL MOUSE BUTTONS in Qt, while staying compatible with the 4.x series!" http://developer.qt.nokia.com/forums/viewthread/6547/
Here are the main changes:
(1) Qt 5.0 eliminates a very large number of plugins :)) On Linux (my platform), I propose to implement only XCB and Wayland.
(2) Since Qt 5.0 will require re-compilation of Applications written against earlier versions of Qt, binary compatibility is a non-issue. SOURCE Compatibility remains critical- and so, I will not try to add the button number into the event signatures. Instead, the range of values which Qt::MouseButton (and the corresponding flags) can take will be expanded with new name-value pairs.
(3) XCB does not automatically provide a 32-bit mask field (the kernel evdev driver, which we use for Wayland input, does include the full mask). It is TBD whether our code should:
(A) obtain the full mask automatically, and setting Qt::MouseButtons accordingly; or
(B) leave high-order bits unset in events, returning the full mask as the value of a SEPARATE function call.I feel that alternative (A) is far less confusing, and have been advised by some X11 experts (Peter H., Daniel S.,) that the overhead and reliability of mixing a query-state function call (i.e., to get the mask) into the code path of this Event processing is a non-issue -- as long as we avoid doing it with every single XCB event which occurs on on Wheel "Buttons". (Wait until we're done compressing these low-level events, and acquire the current mask field when we're preparing to create the QWheelEvent.)
The need for this 'enhancement' seems to be even more severe than it appeared to be a year ago -- our current plugin code actually REDUCES the number of Qt-supported buttons, from 5 to 3. We're losing the "Back" and "Forward" buttons, AKA "XButton1" and "XButton2". (IMO, That's not a healthy direction; Qt becomes less attractive for writing web Browsers, FIle Managers, and etc.)
This would be my first submission of code into Qt. If it's no-go, please advise: What are the problems with this approach, and are there ways to avoid the problems which I don't yet see? In any case, you all have my greatest thanks for any advice and replies. ;)
-
I've done it! My updates for the xlib and xcb plugins (files xlibwindow.cpp and xcbwindow.cpp), together with a small update to qguiapplication.cpp and the expanded enum in qnamespace.h, handle every button I have. (And I have 14, plus the 4 tilt-wheel "buttons").
Qt5 only, of course -- I'm breaking BC. And I haven't begun to think about the mask -- Wayland support of the buttons comes next.
-
Great, thanks!
-
thanks, Andre. After the Wayland Platform Plugin for 5.0 again becomes compatible with Wayland GIT, I'll be working through that one as well. It's fallen a bit behind Wayland, some of the library calls are incompatble -- and that's something which should, IMO, be fixed by Trolls who can discuss their options during the day.
If I tried "playing with it", without any discussion, I'd probably end up with a rewrite which wouldn't fit the overall Qt strategy. But I know, almost exactly, how to write my part -- after the rest of the plugin receives an overhaul.
