[Kde-hardware-devel] Solid::Control::RemoteControl + KDE shortcut system [was: KRemoteControl moved to kdereview]

[Michael Zanetti]

Just for the record for the reviewers of KRemoteControl: This discussion is 
not really related to the KRemoteControl review process any more as we are 
talking about a Solid API not beeing part of KRemoteControl.

CC-ing kde-hardware-devel because I think the discussion better fits there.

On Wednesday 17 March 2010 22:03:58 todd rme wrote:
> On Wed, Mar 17, 2010 at 12:47 PM, Michael Zanetti
> 
> <michael_zanetti at gmx.net> wrote:
> >
> > todd rme wrote:
> >> Sorry for my ignorance, but what is the purpose of this?  Does it just
> >> handle identifying devices or is mapping button presses to commands
> >> also handled by this?
> > 
> > You can query the RemoteControlManager for available remotes on the
> > system. Additionally you get signals when a remote control has been
> > connected or removed (e.g. lircd has been started or a bluetooth remote
> > connected).
> > 
> > After browsing the available remotes you can query each remote for its
> > available buttons. Each RemoteControl provides a signal named
> > buttonPressed(RemoteControlButton).
> > 
> > RemoteControlButtons handle the transition between the backend
> > representation of buttons and the KDE representation consisting of a
> > unique ID for the button, its name and a translated human readable name
> > for representing buttons in UIs in a unified and translated manner.
> > 
> > The purpose is to make using remote controls very simple and independent
> > of the underlaying technique and operating system.
> > 
> > For example it would need just about 10 to 20 lines of code to make
> > amarok fully remote control aware using this Solid interface.
> > 
> 
> What about just integrating it into the normal KDE shortcut system, so
> that remote control buttons could be used the same way keyboard
> shortcuts are now?  A pluggable system where people could provide new
> backends for the normal KDE shortcut system would be very handy in my
> opinion.  It wouldn't just be useful for remote controls.  For
> instance I imagine the simon speech recognition software being
> discussed on the mailing list right now could probably use such a
> system to allow voice commands to be integrated into KDE's shortcut
> system.  It could also be used, with the appropriate backends, for
> mice and joysticks, both of which KDE applications currently need to
> program their own shortcut system for (as plasma does now for mice and
> some games do for joysticks).  It would mean people would only needs a
> single, consistent interface for assigned functions to all of their
> input devices.
> 

That would be a somewhat bigger design decision introducing new opportunities 
but also quite big limitations.

+ It would be nice for people with simple use cases to set up their remote 
controls. Just open your media player app, configure shortcuts, and select the 
desired buttons. No need to use apps like KRemoteControl/KHotKeys.

* KRemoteControl and KHotKeys would merge. In my opinion, while they have some 
common stuff, they are still quite different and I cannot yet immagine a way how 
to combine all the use-cases of keyboards and remote controls in one app.

- People lose the ability to use their remote control as a multi-purpose 
remote. KRemoteControl has a mechanism named mode-switching. Using this, you 
can switch a remote to different modes. This lets you configure an unlimited 
number of actions with very small remote controls. You can find more 
information about this in the KRemoteControl handbook, sitting in kdereview 
currently :) Integrating remotes into the shortcut system would kill this, for 
remote controls quite essential feature. I hardly would use my remote control 
any more if the Play button could only launch/play/pause a single application 
or I would need to grab the keyboard/mouse to change the input focus. Well, I 
actually could set a button on the remote to do Alt+Tab, but still it would be 
way more limited than what its now.

- Another problem is the future of such an interface. With AVRCP version 1.3 
and greater, a remote control has the ability to query the controlled target 
for the the current audio/video metadata, browse the filesystem etc. (they 
might have displays nowadays :). While the current 
Solid::Control::RemoteControl doesn't support this yet, the api coud be 
extended. I guess there wouldn't be any reasonable way to introduce such a 
feature into the shortcut system.

In my opinion the shortcut system in its current state does not really fit into 
the purpose of remote controls. For example you cannot use button combinations 
on a remote control while it doesn't make really sense to have a number of 
modes for a keyboard, just to get more virtual buttons. However, lets see what 
the metalworkers think about this.

Still, I like the idea of a speech recognition backend for the RemoteControl 
API :)

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100318/7c9b0b39/attachment.sig