[Kde-hardware-devel] Shortcuts on non-keyboard Devices.

[todd rme]

On Sun, Mar 4, 2012 at 8:24 AM, Rick Stockton
<rickstockton at reno-computerhelp.com> wrote:
> I thank both Alex and Todd for exposing the idea of "click-device" shortcuts
> as a GSOC project. Here are my opinions, definitely NOT definitive.
>
> (1) My thoughts WRT Qt and "new pointer devices":
>
> I feel that that notion of 'generic events' falls apart pretty quickly in
> Qt: Right now, touchscreen taps emulate mouse buttons, but they *really*
> shouldn't. And various devices have significantly different capabilities- an
> IR remote (e.g., a Television Remote) has buttons, but no location context;
> while a Wii remote DOES have location properties. So, in a better Qt
> platform, there will (probably) be no such thing as a "generic button"
> event. During the last week, development-request at qt-project.org has
> contained a Thread titled "Need to handle touch events rather than depending
> on mouse event", and many better heads than mine have been cooking up ideas.
> It seems that adding API name/value pairs to supoprt multiple devices,
> within the MouseEvent API, is too risky this late in the game. So perhaps, a
> variety of "DeviceArea" classes, capable of being overlapped, will form the
> foundation of new pointer-type device interfaces while keeping Binary
> Compatibility with 5.0.
>
> In the long term, the concept of focus needs to be considered: Right now,
> there is ONLY pointer focus and keyboard focus, but adding secondary,
> tertiary, and peer-level pointer device foci, all manipulating the same
> program, seems desirable - and very complex to implement.

There are two separate issues here.  There are low-level button events
in Qt, like keyboard button presses and mouse button presses.
Although it might be nice to be able to map these easily as generic
buttons somehow, I think it would be messy.

The second issue is what KDE calls global accelerators.  Basically
these are combination of button presses (or rather, keyboard events)
that are mapped to specific KActions or, in KF5, QActions.  Qt does
not have to be aware of them, the KDE classes take care of focus
issues (at least for global accelerators there is no focus).

It also has no concept of position or movement, it only handles button
presses.  Some sort of global axis handling might be nice, but far
outside the scope of what I am discussing.

Currently the event->action mapping only works with keyboard
shortcuts.  However, there is nothing inherent in how the mapping is
done that requires that the events come from keyboards.  My
suggestions is to divorce the events from keyboards, having a generic
(perhaps dbus-based) event system that the global accelerator classes
can then map to QActions.  It would not know or care where the events
come from, as long as they have the right format.  But none of this
would be in Qt, it would be a rewrite of an existing KDE library for
frameworks.

> (3) And finally, how hard are these devices?
>
> I can convert any Qt Plugin to "push" mousebutton events from my Joystick,
> instead of my mouse, in minutes. (I did so, as an experiment.)  And it is
> not hard to create new API for receiving those events - but the focus issue
> is really complex. My vote is for new API to create alternative, concurrent
> areas to receive GUI events ("JoystickArea", or a generic area with device
> type == Joystick, and etc. for other devices.)IMO, we need these devices to
> be capable of independent mappable areas, rather than mere "alterative
> button sources" which MUST be tied to the same stack of GUI elements and/or
> widgets.
>
> This is not GSOC material, I think: some critical foundation work is TBD
> among a number of Qt experts, so writing a proposal becomes a quagmire.
> Other parts of "the shortcut job" are mere adaptation of code which *IS*
> clever, but easily copied into new classes (and that part is 30-40% done
> already).
>
> I just don't think that shortcuts is big enough to fill an entire summer;
> Qt's schedule doesn't match Google's SOC schedule very well; some is too
> undefined, and a lot of the rest is already done. And I can barely code
> "Hello, World" -- I'm not Mentor material.

Once again, this is an interesting idea, but not what I am discussing.
 KDE already has ways of handling all of these issues, albeit a very
rigid one that is only designed to handled a very specific use-case.
Your proposal is sort of a more generalized superset of what KDE
already does, and I agree doing that is outside of the scope of GSOC.
But I think my, less ambitious proposal would be feasible.

-Todd