Shortcuts for Pointer Devices in KDE

[Rick Stockton]

On Tue, 05/15/2012 at 08:39:17 +0200, todd rme <toddrme2178 at gmail.com> 
wrote:
> On Mon, May 14, 2012 at 8:55 PM, Rick Stockton 
> <rickstockton at reno-computerhelp.com> wrote:
>>
>> Todd, we_could_  attempt other devices at the same time. But these other
>> devices must be analogous to a keypad-like "keyboard" (although they'd be
>> much easier to support than THE keyboard, because there aren't i10n and
>> layout issues). The Best example is a TV remote control....
> 2 things:
>
> First, I was specifically referring to buttons, not axes (or other
> analog devices).  Although having classes that allow for
> general-purpose axis devices would be nice, it is obviously outside
> the scope of shortcuts.
Thanks for clarification! (I assumed otherwise, thinking of Wii 
controllers and etc.)

> Second, I was not really suggesting we implement support for other
> devices now.  My point is that we should make the system flexible
> enough that third parties could write their own backends that provide
> button events (remote control buttons, joystick buttons, etc.) or
> button-like events (speech recognition, gestures, network signals from
> a smartphone).....
Gestures and Speech recognition are not like buttons. Button Events are 
instantaneous singletons, while Gestures and Speech are recognized over 
a period of time. (Gestures are already present and fairly easy to use 
in Qt 5.0, of course.) Speech would need to be implemented like 
Gestures, and the scope of work is large.
> So as long as the event could be treated as a single,
> discrete, instantaneous event, someone could write a backend that
> provides that event as a shortcut.
If the interface of the Device can be fit into QPA (Qt Platform 
Abstraction Layer), then I will personally take responsibility for those 
interfaces. But QPA is Internal to Qt, it's not public API... and so, 
such code goes through the Qt Contributor Process. "Issue", which I will 
worry about: Wayland is primitive, VERY primitive, and XCB adds another 
layer to the structure on Linux/X11. I'll almost certainly have to 
submit code for 2-3 products underneath Qt. LIRC isn't a very active 
project; in order to use it, I'd need to do significant API work to help 
it enumerate non-mouse devices and use non-mouse interrupts/events.
> There are already groups working on remote controls (kremotecontrol)
> and speech recognition (simon), even someone working on KDE
> integration with android devices over the network.
Even if Simon is suitable as a "platform" plugin for 
frameworks/shortcuts, it's out of scope for my strategy. OTOH, I'll 
start lurking and looking at kremotecontrol immediately, thanks.
> The idea here would be to make it easy for these groups to tie into the shortcut
> system and provide their own shortcut events so they don't have to use
> their own incompatible shortcut handling system or fake keyboard
> button events.
I agree - if it's not the REAL keyboard, then create a real event 
handler. keyboard emulation leads directly to device layout and i10n 
problems. (e.g., "What is the code for MOD5 in Myanmar/Burma - for 
Burmese, and  Shan, and Karen, and maybe we should support Kachin and 
Chin, too, and should I be using UTF-16 instead?" YUK!)

Per previous, I might be re-factoring the 
QShortcut/QShortcutMap/QKeySequence class to provide common Methods for 
Mouse, Keyboard... or I might link the "QMouseShortcut" table entries 
directly to QActions, as we do with Gestures. (But without the need for 
an intermediate GestureRecognizer implementation.) That's still TBD.