Sorry about the top-posting, but my comments are easier to follow
(better organized) if written all together. Please note right away, that
although I added support for "more mouse buttons" in Qt 5.0, I'm not
very qualified or experienced. My opinions are very possibly wrong
and/or irrelevant. I'm sorry, but I won't attempt to undertake support
for your device.
*** Details:
All such USB devices, supported by Qt 5.x on Linux, should go through
the evdev kernel module. (That's mandatory for Wayland, and avoids
creating weirdness in other Qt Platform plugins.) Most current
mouse+keyboard devices, such as my Logitech wireless receiver, present
_separate_ mouse and keyboard devices at the USB receiver, even when no
keyboard is present. If your shuttle presents multiple USB devices in
the same way, then I'd have one kind of implementation problem. But if
it presents a single USB device, with events re-dispatched by
proprietary Windows or OSX Driver code, then I would have a different
kind of implementation problem. (The latter is much worse.)
Within Qt5, there are two fundamental problems which this device would
have: (1) conflicting input context;and (2) input from a "fake"
keyboard. Qt has only one input context (focus) for the keyboard, and
one for the pointer/mouse. You can't have two "pointer devices" in a
single Qt application - If I add a joystick, and try to use it, the
joystick becomes a replacement for my mouse (and the mouse goes dead.)
The IMPORTANT result of this Qt characteristic is: your shuttle device
can't work *with* a mouse, it can only work *instead* of a mouse.
A Qt Application currently supports only one keyboard. To make use of
"keystroke/keyboard" input from your device, I would have to create
keystroke events from your device - and inflict them to the current
widget or surface which has GENUINE keyboard focus. I imagine that i10n
problems, conflicting modifier key states, and large numbers of other
"issues" would arise from this scheme. My Qt Approvers and Project
big-shots would also kill this. Several months ago, I asked about
implementing mouse shortcuts via emulation of QKeySequence occurences,
and the inventor of QKeySequence saw huge problems from the occurrence
"imaginary, extra" Keystroke Events from other devices -exactly as I
just described, and ordered me to come up with a better way.
Anyway - from my point of view, a "gamer" mouse (which might have as
many as 15 buttons, *plus* the four wheel scroll directions) gives a lot
more buttons to use - without introducing fake, possibly conflicting,
events. Mouse buttons should become shortcut-capable in the Qt 5.1 time
frame. Since I intend to support use of of low-numbered buttons as
"modifiers", a mouse like my own (Logitech G700) is capable of providing
more than 20 easily-pressed shortcut combinations. THAT should provide
for the need of shortcuts from non-keyboard devices, with far less new
code and risk. KDE already provides for Application-specific shortcuts,
and the mouse shortcuts enhancement would fit into the current scheme
pretty smoothly, with far less coding and risk.
*** /Details
Pascal, do you accept my alternative recommendation (i.e., mouse button
shortcuts instead)? Or am I missing some really important, unique
capability of your Shuttle Device?
On 06/21/2012 06:47 AM, Alex Fiestas wrote:
On Thursday, May 31, 2012 10:03:41 PM Pascal Fleury wrote:
Hello,
As pointed out by Kevin, I ask for further information on this mailing list.
I was wanting to add better support for Jog/Shuttle devices (input devices
like this one <http://retail.contourdesign.com/?/products/23> that I own)
and was considering adding this as a new type of device to KDE's Solid
library, to increase support across many programs that may use them. Here
is my proposal:
1. Add a new device type and Interface to the Solid frontend. This would
let Solid notify about such a device being plugged in, and give some
information about it (#buttons, jog resolution, shuttle min/max values,
product name and device name).
We don't have any interface for input devices, in case we decide to go and add
one for Job/Shuttle we should add interfaces for other kind such
mouse/keyboard/touchpads/wacoms...
2. Add a new udevdevice so that the USB device can be detected at least on
Linux. I know too little about other OSs that Solid runs on.
As pointed out by Kevin, actually listening to events and dealing with
input from the device's interaction would be done externally to Solid.
This needs patching in Qt, some effort is going on to supoprt *any* kind of
input for shortcuts as well of supporting any kind of input.
Is such a proposal something you would consider at all ? Also, I have no
creds in submitting code to KDE, I have submitted improvements on the
support of such devices to Kdenlive.
The rule for adding new interfaces is as follows:
We shall add a new interface if and only if more than one application is
interested on it.
So, that's the first question I'd like to ask you: Do you think that
applications should be aware that a Jog/Shuttle is present? can you tell us
some examples?
In case you think it's worth it, how/where would information be stored
about the devices themselves? As it turns out, one can only know that it is
a JogShuttle device from the USB VendorID and ProductID, and I guess there
is no means to get the device to tell us about its capabilities, so that it
would have to be stored in some kind of profile database that would have
the info about #buttons, ranges of jog and shuttle etc.
This sounds like something that should go to either Kernel or X11.
_______________________________________________
Kde-hardware-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
_______________________________________________
Kde-hardware-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
