<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
PREAMBLE:<br>
Hi. I'm the X11-oriented "mouse guy" whom Todd mentioned in his
"last call for GSOC, what about shortcuts?" post (Topic #1 in Vol
95, Issue 69).<br>
<br>
His focus is within KDE itself, while I'm focusing from the lower
layers, moving "up" into KDE Development tools, API, and UI from
those lower layers. (X11, the qt-X11 interface, and upwards into
signal handling.) I have some ideas about Co-Requisite enhancements
to the KDE System Settings Mouse/Pointer Module, and uses within
Kwin, Shortcuts, and some other places. This email will NOT address
those higher-level KDE modules. There's a lot of fundamental stuff,
for which which I will need design advice, and I've been unable to
get it so far. I'll be discussing those other areas in follow-up
emails, if that's OK.<br>
<br>
I'm going to need some direction from KDE visionaries, because there
are four alternative "levels" at which we could do this. But first
let me show the naming convention which I will be using.<br>
"ButtonX" means the button number which gets emitted from X11.
Here's the translation layout which I want to use. Please use it,
because we'll get the numbers confused if some replies and new
comments INCLUDE "wheel events" as numbered buttons, while others
EXCLUDE the two pairs. And also, lots of existing hardware is built
with "wrong" numbers.<br>
<br>
Button1 = "left button"<br>
Button2 = "right button", AKA "context menu button"<br>
Button3 = "middle button"<br>
Button4 = "scroll wheel up"<br>
Button5 = "scroll wheel down"<br>
Button6 = "tilt wheel left", AKA "scroll wheel left"<br>
Button7 = "tilt wheel right", AKA "scroll wheel right"<br>
Button8 = "back button", AKA "XButton1"<br>
Button9 = "forward button" AKA "XButton2"<br>
Button10 = first additional "gamer" button<br>
Button11 = 2nd additional "gamer" button<br>
Button12 = 3rd additional "gamer" button ... and so on.<br>
<br>
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. 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.)<br>
<br>
Here are the 3 alternatives (within Qt4.x, using XI 1.5) which I've
identified for KDE to build upon:<br>
<br>
(A) Do absolutely nothing in Qt, simply enhance KWin, KDevelop, and
etc. to "support" the buttons which Qt now provides.<br>
(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.<br>
(C) Use 31, bytes.<br>
<br>
- - - - -<br>
ALTERNATIVE (A): DO NOTHING ALL IN QT.<br>
<br>
I hate this approach, because it's manifestly easy and risk-free for
even a child 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.<br>
<br>
<br>
<br>
<br>
ALTERNATIVE (B): EXTEND SUPPORT FOR MORE BUTTONS, BUT ONLY TO THE
1ST BYTE BOUNDARY IN THE BUTTON MASK.<br>
<br>
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".<br>
<br>
<br>
<br>
<br>
ALTERNATIVE (C): DEFINE AND SUPPORT AT LEAST 31 POSSIBLE BUTTONS.<br>
<br>
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):<br>
<br>
<table class="valuelist">
<tbody>
<tr>
<td class="topAlign"><tt>Qt::NoButton</tt></td>
<td class=" topAlign"><tt>0x00000000</tt></td>
<td class="topAlign">The button state does not refer to any
button (see <a
href="http://doc.qt.nokia.com/4.7-snapshot/qmouseevent.html#button">QMouseEvent::button</a>()).</td>
</tr>
<tr>
<td class="topAlign"><tt>Qt::LeftButton</tt></td>
<td class=" topAlign"><tt>0x00000001</tt></td>
<td class="topAlign">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.)</td>
</tr>
<tr>
<td class="topAlign"><tt>Qt::RightButton</tt></td>
<td class=" topAlign"><tt>0x00000002</tt></td>
<td class="topAlign">The right button.</td>
</tr>
<tr>
<td class="topAlign"><tt>Qt::MidButton</tt></td>
<td class=" topAlign"><tt>0x00000004</tt></td>
<td class="topAlign">The middle button.</td>
</tr>
<tr>
<td class="topAlign"><tt>Qt::MiddleButton</tt></td>
<td class=" topAlign"><tt>MidButton</tt></td>
<td class="topAlign">The middle button.</td>
</tr>
<tr>
<td class="topAlign"><tt>Qt::XButton1</tt></td>
<td class=" topAlign"><tt>0x00000008</tt></td>
<td class="topAlign">The first X button.</td>
</tr>
<tr>
<td class="topAlign"><tt>Qt::XButton2</tt></td>
<td class=" topAlign"><tt>0x00000010</tt></td>
<td class="topAlign">The second X button.</td>
</tr>
</tbody>
</table>
<br>
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. BTW, I don't want to
define or support Button32 in Qt -- no existing mouse needs it, and
it might be useful as some kind of flag bit within a migration of XI
--> XI2.<br>
<br>
Finally, let me describe the special "trick" which I'll be using
within qapplication_x11.cpp, in order to offer an "ALMOST-reliable"
Button State Mask. (As you know, Xinput 1.5 events provide a Button
Sate Mask which is only one byte in length.) Credit for this
suggestion goes to Daniel Stone: After receiving the event (and
deciding not to ignore it), query the state of the core pointer
buttons, and use the response to set the mask bits for higher-order
buttons which are in "pressed" State. The information isn't
absolutely reliable, because Event State precedes Query State in
priority (within X11). We wouldn't want to do anything like this for
pointer motion, or for keyboard ;) But mouse button states,
especially after Qt has "compressed" the X11 wheel events before
pushing them up into the state machine, remain constant for
relatively long time. This makes a query-based mask pretty reliable
-- at least in the *local* case, on a machine which isn't suffering
CPU or memory problems.<br>
<br>
In the remote case, maybe not so good... but I can't do better
without moving to XI2. If the network and machines are really slow,
then users will have to learn to hold down any high-order "modifier"
mouse buttons until they see the App respond on their screen. And
the I think that the situation of an App treating TWO concurrent
high-order buttons as a unique event is going to be uncommon- and
our doco should advise against it.<br>
<br>
Because of the delay, and the lack of reliability, a User who
really, really wants to get the FULL Button Mask should do so via a
separate function call (new API). With Event and Standard Signals, I
think that Qt should present Mask as now stands... with the
reliable, low-order mask included (from X11, in Event State), but
the higher order bits of other buttons zeroed out. This keeps it
fast and efficient for programmers who aren't doing anything crazy.<br>
<br>
- - - - -<br>
This portion of "more mouse buttons", the part within Qt, isn't big
enough for GSOC. Perhaps the KDE follow-ups are, and I will touch on
a few in separate messages. I intend to write and fully document the
Qt Updates myself, after I receive your comments and recommendation
-- and, I hope, a similar input from a Qt person working in the
"input devices" area. (I know that they have other, big things to
think about, but I'd hate to do a bunch of work and be told "this
isn't the right design" AFTERWARDS.) So, if you can link me up with
such a Qt person, please do so. This is a REAL email address and a
good contact point for me.<br>
<br>
Thanks for reading, and all upcoming replies.<br>
</body>
</html>