--nextPart1511512.MF9YNZ8BWN
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Just for the record for the reviewers of KRemoteControl: This discussion is=
=20
not really related to the KRemoteControl review process any more as we are=
=20
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
>=20
> <michael_zanetti@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?
> >=20
> > 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).
> >=20
> > After browsing the available remotes you can query each remote for its
> > available buttons. Each RemoteControl provides a signal named
> > buttonPressed(RemoteControlButton).
> >=20
> > 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.
> >=20
> > The purpose is to make using remote controls very simple and independent
> > of the underlaying technique and operating system.
> >=20
> > For example it would need just about 10 to 20 lines of code to make
> > amarok fully remote control aware using this Solid interface.
> >=20
>=20
> 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.
>=20

That would be a somewhat bigger design decision introducing new opportuniti=
es=20
but also quite big limitations.

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

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

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

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

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

Still, I like the idea of a speech recognition backend for the RemoteContro=
l=20
API :)

Cheers,
Michael

--nextPart1511512.MF9YNZ8BWN
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAkuh5G0ACgkQXJwWsxE5x7h9/gCfXR2k+1VMmZc1emUAZeGLEYWa
ZJIAni5+Oslw81B0fwNWwWp3/1Ntiy8Z
=RVDr
-----END PGP SIGNATURE-----

--nextPart1511512.MF9YNZ8BWN--