On Tue, 05/15/2012 at 08:39:17 +0200, todd rme <toddrme2...@gmail.com>
wrote:
On Mon, May 14, 2012 at 8:55 PM, Rick Stockton
<rickstock...@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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
