Just kwin, or do the whole thing?

[Rick Stockton]

A kde-core post as well, because I'm offering to resurrect the Dead. ;)

Looking ahead, it's going to be awkward mixing Qt names for Buttons <= 
XButton2, while using X11 names for higher numbers. I'm new to C++, but 
pretty solid on everything except polymorphism and certain asepcts of  
inheritance.

Should we create our own 32-bit-wide Button State field, and enumeration 
of 'Higher-Button' names, as an extension of Qt's MouseEvent? There's 
not enough time (before code freeze) for me to write, and test, such an 
extended MouseEvent Class on the *ENTIRE* set of plugins which exist in 
Qt 4.x -- but I could do that job for an extremely limited number of 
plugins and higher-level interface Classes. That would give you and me, 
(and all other KApplication  programmers) the full set of buttons. Some 
X11 big-shots (Peter H, Daniel Stone) have advised me that they 
anticipate no problem in "mixing" Query State versus Event State in the 
way I'd be doing it - as a separate function call, not automatically 
done with every mouse event.

This would provide the 'not limited to just kwin only' feature which we, 
and a couple thousand KDE bug voters, have wanted for about 10 years. It 
becomes a ongoing maintenance issue for qt-copy, and/or kde-core :( I'd 
be DELIGHTED to volunteer as THE MAINTAINER of such code -- but I'm 
limited to the Linux platform. (I've got no Windoze compiler, or Windoze 
input driver API competence, or even a Windoze computer.) If you can 
identify which plugins (xcb, glib, ....) we would need, and if they turn 
out to be VERY few in number, then I could probably attack and kill the 
ENTIRE shark within the next two weeks- instead of limiting us to 
Workspace Window Actions and compositing Effects.

In the longer term, there's probably another need for this, WRT Wayland: 
On the input side, Wayland "1.0" is a quick-and-dirty project with no 
intention of supporting input pointer devices in a complete manner. They 
anticipate an aggressive schedule for Wayland V2 -- but if Qt intends 
the Qt5 API to last "virtually forever", with binary BC, then Qt users 
are probably stuck with the limitation sof Wayland V 1.x for a long 
time. (Features such as: multiple pointers on the same App window, 3d 
pointers, and so on could only be done with the kind of messy BC tricks 
which I'm proposing to provide "more buttons" here.) The last time I 
looked at Wayland (August), they had support for only 3 buttons.

Two questions:
(1) If you 'masters of KDE' would like me to cancel the kwin-only 
project and jump into the bigger 'Shark Tank' (with an actual KDE place 
to put the resulting classes), please advise which qt4 plugins would be 
needed. (Remember, I CAN'T DO THEM ALL, there are too many for this time 
frame.) And where the module would go (qt-copy, or kde-core, or some 
add-ons library ???). The Qt code which I showed in last night's post is 
unchanged from Qt4 to Qt5, so I'll SWAG that those plugins which survive 
into Qt5 on the traditional graphics stack (as "X11, non-Wayland 
platform input support") are virtually unchanged as well. I could be 
wrong, of course. I have NO IDEA what Nokia's upcoming Beta versions 
might have.

For Kwin only (follow-up with Martin):

(2) elseif kwin-only: Then how/where to define the enumeration of 
buttons above XButton2 (Button 9). My scheme, using only the first 3 
buttons as "modifiers", completely avoids the issue of a full-width 
Button State mask, because we'd only be using the button number, event 
type, and "skinny" State Byte which we have already. Am I correct in 
assuming that I should I execute effects and actions in the Qt way 
(i.e., on button RELEASE, rather than Button Press)? Are there any 
exceptions?

Thanks for everything! Real Life will keep me away from that "XButton1, 
XButton2 mis-identified' Update until this evening (USA), but it should 
be there before tomorrow.