X11 mouse buttons in qt4, qt5, and KDE: please, PLEASE review this design.

[Rick Stockton]

This is inspired by Todd RME's post in Vol 99, Issue 83. Todd's post in 
kde-core-devel refers to the original bug number, QTBUG-16092, but that 
bug is so riddled with unworkable baggage that I cloned another. The 
real work will be in QTBUG-19238. QTBUG-19238 currently contains 
start-up work on defining the 3 remaining bits in the //Qt::MouseButton 
enumeration byte as actual button numbers.

Blind-siding qt Devs on IRC, with no actual document to look at, led to 
the unworkable code of QTBUG-19238. (We fell into a frenzy of incorrect 
'Rah, rah, YES WE CAN group-think with each other.) And 
bugreports.at.nokia.com is fine for reporting bugs, and submitting code, 
but I've never received a response to my requests for design 
hints/review before starting to write code. (I got nothing from Devnet, 
either.) I'm unable to even get a tentative estimate for the API changes 
cutoff date on Qt 4.8.

And so, I'm asking for a design review on these two lists. My idea might 
not be quite right, let's get it in order BEFORE I start writing code! I 
know that this isn't the right place for such a "Design Review", but qt 
appears to offers no viable alternative. Please feel free to ignore this 
entire post if the particular details of my design aren't of interest to 
you.
- - - - -

We have 3 bits available for enumeration of additional buttons without 
breaking compatibility. I think that the key to getting all 31 possible 
X11 buttons into qt is this: Use only two of them, for the buttons sent 
up from X11 as "Button10" and Button11". (Those are the raw numbers from 
X11, in which the four wheel-scroll "buttons" DID appear as button 
numbers.)  Then, instead of using the last bit (x80) to define 
"Button12", give it a name (e.g., Qt::HigherButton) which indicates that 
the Button number (from X11, or another platform interface with good 
button support) is GREATER than the one that which I've tentatively 
enumerating as "Button11". BTW, here's the entire enum which I propose 
to use:

     enum MouseButton {
         NoButton         = 0x00000000,
         LeftButton       = 0x00000001,
         RightButton      = 0x00000002,
         MidButton        = 0x00000004, // ### Qt 5: remove me
         MiddleButton     = MidButton,
         XButton1         = 0x00000008,
         BackButton       = XButton1,
         XButton2         = 0x00000010,
         ForwardButton    = XButton2,
         Button10          = 0x00000020,
         Button11         = 0x00000040,
         HigherButton      = 0x00000080,
         MouseButtonMask  = 0x000000ff
     };
     Q_DECLARE_FLAGS(MouseButtons, MouseButton)

I tossed in alternate names for 'XButton1' and XButton2', which were 
introduced in 4.7): By convention, they are almost universally used as 
"BACK and "FORWARD".

When a User wants to receive MouseButtonPress, MouseButtonRelease, or 
MouseButtonDblClick events from higher-numbered buttons, it becomes a 
two-step process: First, receive the event, and recognize that the 
'HighNumberedButton' value is generic. Then, call a new function which 
I'll add into the class:

int QMouseEvent::ButtonNumber () const

which shall return the INTEGER Button number of the most recent 
Press/Release/DblClick event. BTW, I feel that this function should also 
report the integer values for events which occur with lower-numbered 
button values: It would allow programmers to define their Button-based 
code blocks by branching on integers. (The alternative is to have one 
set of branching control statements built for "low-numbered" buttons, 
using the Enum values; plus another set of branching control statements 
built for high-numbered buttons, using Integers. Code like that would 
look ugly.)

The whole idea of using an enum which couldn't contain any more buttons 
than the miserable XI V1.x Button MASK was a *BAD DESIGN* from the 
beginning. Let's support old code without changes, but lets also solve 
the problem by making the design correct.
-----

I am confused by the "plugin" design which appears to be present in both 
qt4 and qt5. Is the qt5 Wayland plugin really supporting only  only 
THREE mouse buttons, per the following code from 
qt5/qtbase/src/plugins/platforms/wayland/qwaylandinputdevice.cpp?
(a code snippet from gitorious):

....
void QWaylandInputDevice::inputHandleButton(void *data,
                         struct wl_input_device *input_device,
                         uint32_t time, uint32_t button, uint32_t state)
{
     Q_UNUSED(input_device);
     QWaylandInputDevice *inputDevice = (QWaylandInputDevice *) data;
     QWaylandWindow *window = inputDevice->mPointerFocus;
     Qt::MouseButton qt_button;

     if (window == NULL) {
     /* We destroyed the pointer focus surface, but the server
      * didn't get the message yet. */
     return;
     }

     switch (button) {
     case 272:
     qt_button = Qt::LeftButton;
     break;
     case 273:
     qt_button = Qt::RightButton;
     break;
     case 274:
     qt_button = Qt::MiddleButton;
     break;
     default:
     return;
     }
....
(end of snippet). Is qt5 going BACKWARDS, rather than forwards, on this 
"mouse buttons" issue?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110727/44e06499/attachment.htm>
-------------- next part --------------
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback