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.
