<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
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 <span
class="st"><em></em></span>Qt::MouseButton enumeration byte as
actual button numbers.<br>
<br>
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.<br>
<br>
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.<br>
- - - - - <br>
<br>
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:<br>
<br>
enum MouseButton {<br>
NoButton = 0x00000000,<br>
LeftButton = 0x00000001,<br>
RightButton = 0x00000002,<br>
MidButton = 0x00000004, // ### Qt 5: remove me<br>
MiddleButton = MidButton,<br>
XButton1 = 0x00000008,<br>
BackButton = XButton1,<br>
XButton2 = 0x00000010,<br>
ForwardButton = XButton2,<br>
Button10 = 0x00000020,<br>
Button11 = 0x00000040,<br>
HigherButton = 0x00000080,<br>
MouseButtonMask = 0x000000ff<br>
};<br>
Q_DECLARE_FLAGS(MouseButtons, MouseButton)<br>
<br>
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".<br>
<br>
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:<br>
<br>
int QMouseEvent::ButtonNumber () const<br>
<br>
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.)<br>
<br>
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.<br>
-----<br>
<br>
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?<br>
(a code snippet from gitorious):<br>
<br>
....<br>
void QWaylandInputDevice::inputHandleButton(void *data,<br>
struct wl_input_device *input_device,<br>
uint32_t time, uint32_t button, uint32_t
state)<br>
{<br>
Q_UNUSED(input_device);<br>
QWaylandInputDevice *inputDevice = (QWaylandInputDevice *) data;<br>
QWaylandWindow *window = inputDevice->mPointerFocus;<br>
Qt::MouseButton qt_button;<br>
<br>
if (window == NULL) {<br>
/* We destroyed the pointer focus surface, but the server<br>
* didn't get the message yet. */<br>
return;<br>
}<br>
<br>
switch (button) {<br>
case 272:<br>
qt_button = Qt::LeftButton;<br>
break;<br>
case 273:<br>
qt_button = Qt::RightButton;<br>
break;<br>
case 274:<br>
qt_button = Qt::MiddleButton;<br>
break;<br>
default:<br>
return;<br>
}<br>
....<br>
(end of snippet). Is qt5 going BACKWARDS, rather than forwards, on
this "mouse buttons" issue?<br>
<br>
<br>
</body>
</html>