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?
