Shortcuts for Pointer Devices in KDE (was: KAction and KShortcut in frameworks)

[todd rme]

On Mon, May 14, 2012 at 8:55 PM, Rick Stockton
<rickstockton at reno-computerhelp.com> wrote:
> On Mon, 14 May 2012 13:59:43 +0200, todd rme <toddrme2178 at gmail.com> wrote:
>
>>  It sounds like this is being limited to just mouse and keyboard
>>  shortcuts.  Is there a reason this can't be made more general, so
>>  other devices can provide shortcuts as well?  Currently we have a
>>  variety of devices with their own unique button and action-handling
>>  systems.  Being able to provide a plugin-based system that anyone can
>>  write an additional backend for would allow us to unify these
>>  interfaces.
>
>
> -Todd
>
> 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. Creating
> lower-level Classes for those devices is simply copy-paste-rename-simplify
> from the keyboard Classes. But I don't see a lot of Bugzilla Votes such
> support.
>
> For mice, at the Qt level, I'm intending to provide unique back-end classes
> (QMouseSequence, QMouseShortcutMap ...). These "Sequences" and Map" can
> result in some of the same Action as keyboard-only shortcuts, or they can
> perform new ones. many or all of thesmexecute the same Actions. I still need
> to look, play and think about possible re-factoring within the "higher"
> Classes (e.g., QShortcut itself).
>
> Please remember that we can NOT support another Device with location
> coordinates and "automatic" context! Devices which behave as a mouse, with
> location and scrolling  (e.g., a JoyStick, a game console Remote, etc.)
> cannot be done in Qt5. Qt is built with the assumption of just one Pointer
> context, it would require multiple person-years of effort, and huge API
> changes, to support multiple pointer contexts on Widgets. (QML is probably
> easy to implement, via overlapping "MouseArea" Elements. It might even be
> possible to add into Qt5.x as a feature, without breaking BC, using the kind
> of API trickery which we did in adding Global Coordinates into QMouseEvent
> signatures. Otherwise, it's a Qt6 item.)
>
> I own a Joystick, and I modified Qt to use it as an alternate mouse device.
> Movements are slower and much less accurate than mouse movements; it's a
> strain to "drive" or "fly" for long periods; and it's a strain to reach some
> of the buttons down on the "hat". In Qt, you can pretty easily have either
> the Joystick or Mouse, but not both. And mice are far more ergonomic
> general-purpose Pointer devices.
>
> In any event, the fundamental need (with thousands of bug votes) is for
> mouse-button-based shortcuts. That can go into Qt 5.1, supporting both
> Widgets and QML MouseAreas, so I'll do that first. Support of Remote control
> devices remotes, if we do them at all, becomes a question of priority. And,
> IMO, it's contending at a much lower level of Awesomeness.

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.

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).  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.

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.  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.

-Todd