[Qt5-feedback] Some questions about Qt-5 input

[Rick Stockton]

About me: I am delighted to see that a mailing list has been created for 
'qt5-feedback', because my hours are not very "compatible" with EU 
people on IRC. I would be delighted to listen, with care, on any other 
mailing lists and 2-way blogs concerning input devices. (If Gitorious 
provides ML-like communications, I have not seen where they are.) I 
apologize in advance for awkward words, I'm not a good communicator in 
writing.

I have the impression, from my 'barely-qualified-to-comment' view, that 
qt *must* target migration to XI 2.1 as an underlying X11 input stack. 
(X11->Wayland would seem to be later, and an underlying platform option 
and neither prerequisite nor related to updating the Qt User/Developer 
API.) On this list so far, we have lots of good discussion about the 
migration to OpenGL, and other issues ...

Which leads to the "fresh food" of my post: XI 2.1-based input, both for 
touch and primitive (keyboard, pointer) devices.

I worry that our Qt-MT and input stack binding API and bindings could 
turn out to be a semi-compatible collection of "Fresh-Baked Tastiness" 
(uTouch-geis versus Qt-"almost-like-geis", leading to all kinds of 
"Surprise! You can't do that in Qt or KDE!!" unpleasantness. (In the 
same manner as our "Invented-Only-Here" Mouse Event API made higher 
numbered mouse buttons totally impossible in Qt-4). As far as the Geis 
people are concerned, it looks like the relationship with us (Qt) is 
somewhat hopeful, but mostly dark and murky, undefined "magic". If any 
of their team members are Qt people, I did not recognize their names. :(
E.g., https://lists.launchpad.net/multi-touch-dev/msg00863.html

Closer is better, I think. (And my opinion applies both to GTK and the 
X11 interface). Painting is huge -- but so are problems caused by our 
primitive implementations of "Mouse", "Pen", and "Keyboard".

There are many challenges:

(1) What's going to happen to legacy Apps when they start getting 
KeySyms > 255 ? Many keyboards dedicated to "larger" character sets, and 
many "multimedia" keyboards, will be trying to send them right away. 
Perhaps we need to provide some sort of 'useLegacyKeyboardEmulation()' 
capability to translate, and/or "vaporize, we never got it" such KeySyms 
when they are received, to prevent them from being hacked off and 
re-interpreted as the WRONG 8-bit value.

(2) XI 2.1 allows for a device with "Buttons" to have an UNLIMITED !!! 
number of buttons. Should we support additional CARD32 button sets, or 
support only the first one? (I personally feel that 32 buttons is 
sufficient, but I could be wrong about this.) As some of you know, the 
current 1-byte mask "button number" in button events makes it impossible 
to add more buttons without creating a new Class. Our current 
presentation of the "button number" as a value from our 8-bit mask is 
horrible. (XI, in *ALL* versions, gave us an integer, but we (ahem) 
FUBARed.) What do we propose as the new API, and how will we promote 
compatibility with old code?

Maybe we should keep the current craziness, translating the integer into 
a single bit within a CARD32 mask return. Such translation wastes CPU 
power, but most ButtonPress and ButtonRelease events will involve low 
numbered buttons... buttons which are handled relatively early and 
efficiently in the IF-ELSE structure.

(3) Touch devices, and others as well, are going to deliver RAW Events 
to all Windows. (For example, the "I'm not getting any RAW Mouse moves 
in other Windows which want to know, because XServer created an implicit 
Grab when a button is pressed." ) Will Qt provide an API to explicitly 
request notification on such Raw events?

My thanks for any reply in advance. My even greater thanks if you can 
point me towards a more specific ML which addresses such input device 
support for Qt-5. I already know the appropriate persons on IRC, 
attempting to scribble updates to allow ButtonPress and ButtonRelease 
events for higher-number buttons in Qt 4.x. But I'm too crippled to use 
IRC very effectively. (And it's physical, not just "bad attitude".) 
Private replies? This was my REAL email address- go ahead and use it.