[Development] 31 mouse buttons in Qt 5.0

[Rick Stockton]

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/ This 
message duplicates a new forum topic at: 
http://developer.qt.nokia.com/forums/viewthread/10970/

Here are the main changes:

(1) Qt 5.0 eliminates a very large number of plugins :)) making the job 
much smaller.  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, BIINARY compatibility is a non-issue 
(right?). SOURCE Compatibility remains critical- and so, I will not try 
to add the (int) button number into the event signatures. Instead, I 
will expand the range of values which Qt::MouseButton (and the 
corresponding flags) can take, using 31 bits. Should I go ahead and use 
the high-order bit as well?

(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 lower-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 5.0 Wayland/evdev 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. ;)