<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
My thanks to you, MGrasslin, Aaron, Todd rme, and Thiago for
coaching me towards this achievement. The new code is small, and
VERY simple. We have no API changes (at least, not yet--- we should
implement a mouse button mask "getter" as a new feature, but that's
for later in the 5.x series. It won't have any BC issues.) I will
need to write doco of the new Qt::MouseButton values, and others
will need to translate that material.<br>
<br>
My "qt5_MouseButtonTester" is a QTextEdit window, with Mouse events
(Click/Release/DoubleClick) extended to show some qDebug() on the
parent console. Basically, it's an "xev" program for Mouse Buttons
in Qt. This tester, on Qt::MouseButton events, translates the button
value back into the raw X11 number. I verified the button locations
on my mouse to be correct, using xev itself.<br>
<br>
My mouse has "only" 14 buttons, plus the tilt wheel, for a total of
18. I know that the Razr 'Naga' has even more, but it's too small
for my hand. (And the one I've got cost me enough money, already.)
The logic works for up to 31 "button numbers", with 4-7 taken for
the four possible directions of wheel motion. Just for fun, here's
my output from clicking the buttons in order. I did perform a few
DoubleClick events during the test:<br>
<blockquote><tt>rick@x2:~/qt_projects/qt5_MouseButtonTester>
qt5_MouseButtonTester</tt></blockquote>
<blockquote><tt>No platform plugin argument was specified,
defaulting to "xcb".<br>
Successfully connected to display :0<br>
<br>
Information of screen 346:<br>
width.........: 1920<br>
height........: 1200<br>
depth.........: 24<br>
white pixel...: ffffff<br>
black pixel...: 0<br>
<br>
Running window manager: KWin<br>
MousePress: button 1<br>
MouseRelease:<br>
MousePress: button 2<br>
MouseRelease:<br>
MousePress: button 3<br>
Mouse Wheel Event: UP<br>
Mouse Wheel Event: DOWN<br>
Mouse Wheel Event: LEFT<br>
Mouse Wheel Event: RIGHT<br>
MousePress: button 8<br>
MouseRelease:<br>
MousePress: button 9<br>
MouseRelease:<br>
Mouse DoubleClick:<br>
MousePress: button 10<br>
MouseRelease:<br>
MousePress: button 11<br>
MouseRelease:<br>
Mouse DoubleClick:<br>
MousePress: button 12<br>
MouseRelease:<br>
MousePress: button 13<br>
MouseRelease:<br>
Mouse DoubleClick:<br>
MousePress: button 14<br>
MouseRelease:<br>
rick@x2:~/qt_projects/qt5_MouseButtonTester></tt><br>
</blockquote>
xlib runs the same, as far as my mouse buttons are concerned. But
the App Window fails to repaint when I move it, or when I resize it.
I'll SWAG that we've got an issue there, not the fault of kwin
4.6.5. (I can try running it from another User in which my desktop
is fresh kwin 4.8-pre from GIT, if you think that the WM should be
getting the blame for this behavior. Let me know on that, thanks.<br>
- - - - -<br>
<br>
FILES CHANGED:<br>
<br>
qnamespace.h:<br>
(The expanded enum/flags is prerequisite for all other code
changes). DOCO IS NEEDED, I can write it in En-US.<br>
<br>
qguiapplication.cpp:<br>
(This contains a redundant check on button numbers being passed
up from plugins. I made a one-line change, upping the high-limit to
be 'Qt::Button31'.)<br>
<br>
qxlibwindow.cpp, qxcbwindow:<br>
(I added cases to the ev->button 'switch' block, for all of
the new buttons. In this file, and qxcbwindow.cpp, I also eliminated
an unnecessary multiply in the calculation of 'delta' -- simply
setting values 120 : -120 as the hard-coded results of the "?"
operator (rather than multiplying 120 * .... ? 1: -1).<br>
<br>
Should we do them all as one update, or do xlib first -- and add the
more widely used xcb as a separate update, after the first one is
found NOT to cause regression test failures over the next weekend?
(BTW, I don't know how to do the Git Clone and Request procedure,
and I'm a slow learner-- it would REALLY be better if I simply
emailed these files to you.) Changes are public domain, of course -
I think that I've already certified acceptance of the Qt license
exceptions for my Contributions.<br>
- - - - - - -<br>
<br>
Now, for Wayland:<br>
I can create alternate UserIDs on my PC, of course. But the plugin
fails to compile, issuing the following message:<br>
<blockquote><tt>..... -o qwaylandinputdevice.o
qwaylandinputdevice.cpp</tt><br>
<tt>qwaylandinputdevice.cpp:527:1: error: too many initializers
for ‘const wl_input_device_listener’</tt><br>
<tt>make: *** [qwaylandinputdevice.o] Error 1</tt><br>
</blockquote>
Not a missing library or header, my hand-edit of the Makefile was
correct. I suspect that this results from my use of a fresh 'Pull'
of Wayland, per the README instructions. I don't have time for this
one (and I'm a slow learner), can you or another 'Grandmaster' take
care of it?<br>
<br>
<br>
</body>
</html>