added a comment - - edited
- New Edit ***
After some talk on IRC, I've chosen to expand the field up to 16 bits, providing 11 new buttons.
- End of New Edit ***
There are three alternative "levels" at which we could do this. Here's the existing buttons:
Button1 = "left button"
Button2 = "right button", AKA "context menu button"
Button3 = "middle button"
Button4 = "scroll wheel up"
Button5 = "scroll wheel down"
Button6 = "tilt wheel left", AKA "scroll wheel left"
Button7 = "tilt wheel right", AKA "scroll wheel right"
Button8 = "back button", AKA "XButton1"
Button9 = "forward button" AKA "XButton2"
Button10 = first additional "gamer" button
Button11 = 2nd additional "gamer" button
Button12 = 3rd additional "gamer" button ... and so on.
Within Qt, the Devs have recognized that Button8 and Button9 are frequently implemented "backwards". Thus they assigned the more cryptic names "XButton1" and "XButton2". But Qt has not considered the possibility of horizontal tilt wheels (or genuine horizontal wheels) implemented on a different pair of values. And unfortunately, many mice ARE built with "nonstandard" numbers. Even products from a single manufacturer can vary. For example, Logitech emits 6/7 from some models, and 13/14 from different ones- usually older models, but still in widespread use.
Here are the 3 alternatives (within Qt4.x, using XI 1.5) which I've identified for KDE to build upon:
(A) Do absolutely nothing in Qt, simply enhance KWin, KDevelop, and etc. to "support" the buttons which Qt now provides. (Obviously, I wouldn't even be here if I though that this would be a desirable choice.)
(B) Add 3 more buttons (Button10 thru Button12), extending the defined enum and mask bits (Qt::MouseButton and QAt::MouseButtons) until they hit a byte boundary.
(C) Provide 31, or perhaps even 32, buttons.
- - - - -
ALTERNATIVE (A): DO NOTHING ALL IN QT.
I hate this approach, because it's manifestly easy and risk-free for even a child (like me) to "extend" Qt's bit definitions to at least a byte boundary. (With X11; I don't know about other platforms, such as Win32 or OSX, or Symbian. And anyway, OSX support is broken with just 3 buttons, and the authors of the Button8/Button9 updates didn't actually bother with doing the whole job: The automated testing code tools, among other "non-production" parts of Qt, still don't have them.
ALTERNATIVE (B): EXTEND SUPPORT FOR MORE BUTTONS, BUT ONLY TO THE 1ST BYTE BOUNDARY IN THE BUTTON MASK.
Add Button10 through Button12. That's a LOT of buttons (although my "test mouse", like most "gamer" mice, has even more). Very safe, with no possibility of compilers "doing the wrong thing".
ALTERNATIVE (C): DEFINE AND SUPPORT AT LEAST 31 POSSIBLE BUTTONS.
This is my recommendation, but it depends on something I don't know: The current enum for Qt::MouseButton defines all values as 32-bit hex values (with leading zeroes):
Qt::NoButton 0x00000000 The button state does not refer to any button (see QMouseEvent::button()).
Qt::LeftButton 0x00000001 The left button is pressed, or an event refers to the left button. (The left button may be the right button on left-handed mice.)
Qt::RightButton 0x00000002 The right button.
Qt::MidButton 0x00000004 The middle button.
Qt::MiddleButton MidButton The middle button.
Qt::XButton1 0x00000008 The first X button.
Qt::XButton2 0x00000010 The second X button.
I think that an enumerated item with an explicit value will NEVER be compressed, even though a Compiler which wanted to squeeze an enum of 7 items (defined without specific values) into a SINGLE BYTE would be free to do so. If my understanding is correct on all platforms, then we can safely use the entire Uint32. If it isn't, then we'd better stay with ALTERNATIVE-B.
I know that GCC is OK, and MSVC. I don't know about other compilers. << HELP NEEDED >>