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

[Rick Stockton]

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.

(2) Now, for mouse shortcuts:

I had delays while working on MouseButton-based Shortcuts, and missed 
the Qt 5.0 API freeze by roughly 2 weeks of calendar time. But, I intend 
to complete this feature quit early in the 5.1 Development cycle. I 
anticipate that feature code will be merged sometime in May.

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

But Todd's other ideas? I think that major improvements in the design 
and implementation of printer "management" would be a FANTASTIC project!


- - - - context below - - - -

On Sat, Mar 3, 2012 at 03:26 AM, Alex Fiestas <afiestas at kde.org> wrote:
> On Fri, Mar 2, 2012 at 11:40 AM, todd rme<toddrme2178 at gmail.com>  wrote:
>> 1. Multiple input devices for shortcuts.  Currently only keyboards can
>> provide shortcut events.  Other input devices like mice, remotes, and
>> voice cannot integrate as deeply with KDE, and it is hard to use
>> shortcuts that combine devices (like mouse+keyboard).  However, there
>> is an opportunity with frameworks to rework the global accelerator
>> classes.  The goal of this project would be to rework the classes into
>> a device-agnostic system where plugins provide generic events which
>> the global accelerator then maps to actions.  The project would also
>> require making at least one plugin (the keyboard plugin).
> There was somebody already working on this within KDE, from my point of view this is something an experience person should do because we will have to modify Qt.