> On Friday, February 4, 2011, todd rme wrote:
>> I don't want to sound like a broken record here, but this is exactly
>> the sort of problem that being able to use mouse buttons in keyboard
>> shortcuts would solve. Why create an entirely new GUI for this when
>> we already have a GUI that can do this, and far more, and that users
>> are already familiar with?
> is that a different problem?
This is not a "different" project/problem. Rather, it's a previously
unexpected 'sub-task' within the bigger project.
The big project, Todd, is exactly the one you describe: Provide support
for using all these "gamer" mouse buttons into
the KDE shortcut widget, and underlying Qt event and signal library.
But- Qt doesn't support button numbers above "Button8", and KDE doesn't
take advantage of anything above "Button5" (i.e., the vertical wheel
events). In adding this support, Qt has hard-coded that tilt-wheel
"Scroll Left" and Scroll Right" **MUST** come from the hardware as
"Button6" and "Button7". Tilt wheels don't actually have a wheel, with
which can control the amount of distance. Instead, they send ButtonPress
very rapidly, emulating a continuous spin for as long as you hold that
button down.
With a "regular button", if you press and hold it down, there are no
interrupts at all until you let go. But that't not how Tilt wheels work.
The emulation, in hardware, consists of Rapid ButtonPress events (at
least 20/second is typical), for as long as you hold it in the tilted
position. Qt knows that the scroll wheel emulation needs special
treatment- and does it pretty well, making sure that a matching
ButtonRelease evt. is provided at the end even if the mouse didn't send
it, and vastly compressing the number of interrupts into higher code.
But a Mouse which implements on Button12/13 rather than the expected
Button6/Button7, will likely all kinds of breakage. (The Qt guys have
not attempted to support numbers that high-- yet. That's my first job
:)) We'll see the original rate of ButtonPress events, but (possibly)
without matching ButtonRelease. CPU Utilization goes wild with all the
interrupts (worse if they provoke re-paints, and, depending on the
singals being listened for, they might be interpreted as either 10
double-clicks per second OR twently single clicks per second... Or it
might simply break, because we never got matching ButtonRelease Events.
(I don't know exactly what will happen; maybe a wide variety of
different things. But they're all going to be VERY bad.)
- - - - -
> on Friday, February 4, 2011, Aaron wrote:
>
> if understand correctly, the problem Rick is attempting to solve is this:
>
> * i plug in fancy mouse a (FM(a)) and use button N to trigger an action
> * i unplug FM(a) and plug in FM(b), which unfortunately maps the same buttons
> (to the user) to different codes (to the computer)
>
> with Rick's proposed solution, the user wouldn't notice a difference between
> the two mice ... as expected.
>
> Rick: am i understanding you correctly here?
Aaron: yes that's an intended result. But the critical need is a solution for
to make ALL mis-numbered horizontal wheels appear as Button6/Button7. When a
user plugs starts up KDE with a mouse we don't already know about, via<device
name>, then we need to provide a way for s/he to show us which the buttons
which need to be mapped into this standardized pair. ("Please press and hold
the button which you would like to use as "scroll left".) For the UI, this
should be done as an enhancement to the current "Left or Right Handed?" Mouse
configuration. (That's because all of the surrounding Doco and programming
structures are already present, we simply expands them)
Thanks for allowing solution at the X11 layer. Button re-numbering via xinput
set-button-map DOES work for the wheels (I checked before writing yesterday's
initial entry on the subject). And the within-Qt alternative would be quite
nasty. :((
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
