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

On Thursday 18 March 2010 17:23:40 todd rme wrote:
> On Thu, Mar 18, 2010 at 4:29 AM, Michael Zanetti
>=20
> <michael_zanetti@gmx.net> wrote:
> >> 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
> > opportunities but also quite big limitations.
> >=20
> > + 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.
> >=20
> > * KRemoteControl and KHotKeys would merge. In my opinion, while they ha=
ve
> > 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.
>=20
> No, this is not really what I am proposing.  My thinking was that
> KRemoteControl would remain around for things like setting up remotes,
> assigning names to buttons, and so on.  The only thing that would
> change is that you would not use KRemoteControl for assigning actions
> to buttons.  That would be done within the normal shortcut system.
> KRemoteControl would maintain all its own functionality for stuff
> related specifically to remote controls, but it would send out all of
> the button presses it receives to the shortcut system so they could be
> used by KDE applications without needing any extra work on the part of
> application developers.
>=20

Assigning actions to buttons is actually the only purpose of KRemoteControl=
=2E=20
There is no such configuration as "assigning names to buttons". This is don=
e by=20
the backend without any configuration on the KDE side.

However, I can immagine now what you are talking about.

> So in other words, what I am suggesting is a separation in the
> configuration of input devices.  Everything that is specific to a
> particular type of device would be in that device's configuration.
> However, things that are more general across input devices, like
> assigning buttons to KDE application actions, would use a single
> interface for all devices.
>=20
> For example, with the voice recognition you will still need the module
> to learn voice commands and assign names to the voice commands that
> the shortcut system can make use of, so it would need its own module
> for that sort of thing.  However, once that is done, you would use the
> normal shortcut system for actually getting those voice commands to do
> something useful.
>=20
> Similarly, you would still need a joystick configuration module for
> things like calibration.  But assigning actions to joystick buttons
> would be done within the shortcut system.
>=20
> You would still need a bluetooth configuration module for pairing
> devices, setting trust, handling audio and data, etc, but assigning
> actions to bluetooth device buttons would be done within the shortcut
> system.
>=20

Bluetooth is somewhat special... For example AVRCP 1.4 specifies "player=20
selection". That means a remote control is able to specify to which=20
application it gets routed. Wouldn't work out with current KHotkeys system =
as=20
it always gets routed to the current input-focus...

> You would still need a mouse configuration module for things like
> mouse speed, left vs. right-handedness, double click speed, etc, but
> assigning actions (besides the normal left/right/middle mouse clicks
> and scroll wheel) would be done within the shortcut system.
>=20
> So in other words, things that are the same across all input devices,
> like the need to assign actions to buttons, would use a common
> interface.  The configuration of device-specific properties, however,
> would use device-specific modules.
>=20
> There is another potential benefit as well.  If the shortcut system is
> aware of all the buttons available to each device, it might be
> possible to set it up to map the buttons from one device to the
> buttons of another.  Like mapping the buttons on a bluetooth phone
> (that supports it) to numbers and letters on a keyboard, or mapping
> remote control buttons to mouse presses.  This is not essential to my
> idea, but it could potentially be a side benefit of this sort of
> implementation.
>=20
> > - 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.
>=20
> Yes, this is the sort of thing you would need to keep KRemoteControl
> around for, because it is unique to remote controls.  But that doesn't
> mean KRemoteControl should duplicate the functionality of the shortcut
> system when it comes to assigning buttons to ordinary actions.
>=20

Anyone knows if it would be possible to domething like this:
Button "Music" is used to switch the remote to the music-mode. So when you=
=20
press the "Play" button while the remote is in the "Music" mode, the shortc=
ut=20
system gets a key combination like "Music + Play". In other words, is it=20
possible to specify additional modifier keys like Ctrl, Alt, Meta etc?

> In this case, actually, this something that I think the entire
> shortcut system could benefit from.  For instance I think multimedia
> keyboards would benefit a lot from this, as would joysticks in more
> complex games.  So this may be a case where I think, rather than it
> being something that should be kept unique to remote controls or
> something that should be done away with, it is something that should
> be incorporated into the shortcut system as a whole.
>=20
> > - 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.
>=20
> Yes, once again this is something that would require KRemoteControl to
> stick around.  I am not suggesting replacing KRemoteControl, I am
> saying KRemoteControl should hook into the shortcut system just for
> the purposes of making shortcuts.  It can keep doing anything else it
> needs to do on its own.
>=20

Nope... Also KRemoteControl isn't useful for that. It would require=20
Music/Video Players to register at the RemoteControl API so that a Bluetoot=
h=20
remote control can browse registered players, and select the target=20
application by itself. Each registered application must be able to provide=
=20
Metadata to the remote control system by itself.

> > 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.
>=20
> Why doesn't it make sense for a keyboard?  My multi-media keyboard
> already has a built-in mode switching ability (although it only works
> on some keys and only has two modes).  I think it would be very useful
> for a number of buttons on my device.  All in all the use cases for
> multimedia keys on a keyboard I would say would be fairly similar to
> the use-cases of remote controls, anything you would want to do with
> one you would probably also want to be able to do with the other.
>=20

The main difference here is that your keyboard handles this mode switching =
in=20
its hardware. The software just receives some different key presses. While =
for=20
remote controls the mode switching stuff is done completely in software (As=
=20
long as you haven't got a real multi-purpose-remote). This means that remot=
e=20
controls can have an unlimited number of user-defined modes, but the softwa=
re=20
receives always the same button name from the hardware, regardless of what=
=20
mode it is currently in.

>=20
> There is one detail I forgot to mention: devices would have to be able
> to deny certain button presses or button press combinations.  For
> instance KRemoteControl would have to be able to tell the shortcut
> system that it can't use the buttons used for mode switching.  The
> mouse backend would have to be able to say you can't use the left
> button, right button, middle button, or scroll wheel on their own (but
> it would allow, say the left button combined with one or more
> non-mouse buttons, such as left mouse+keyboard meta).  This shouldn't
> be too difficult because it should only be limited to blocking one or
> more of the device's own buttons in combination with or not in
> combination with the same device or a different device.  So the
> backend could just provide a list with some or all of these values:
>=20
> Buttons that cannot be used for shortcuts: a,b,c
> Buttons that cannot be used for shortcuts unless combined with another
> button from any device: d,e,f
> Buttons that cannot be used for shortcuts unless combined with another
> button from this device: g,h,i
> Buttons that cannot be used for shortcuts unless combined with another
> button from this device type: j,k,l
> Buttons that cannot be used for shortcuts unless combined with another
> button from a different device: m,n,o
> Buttons that cannot be used for shortcuts unless combined with another
> button from a different device type: p,q,r
>=20
> Or, alternatively, the shortcut system could send any proposed
> shortcuts to the backends that provide buttons used in that shortcut
> (along with data like source device and source device type for each
> button press in the shortcut) and the backends could all report
> whether that shortcut is acceptable.  That would allow for more
> complicated rules to be implemented inside the backends.
>=20

I guess this would just be same as currently the modifier keys for keyboard=
s.=20
Try setting a shortcut by pressing just ctrl without any other button. The=
=20
same could be done with Mouse buttons. Mode switches for remote controls ar=
e=20
somewhat special here. They shouldn't just be passed up to KHotKeys but=20
instead directly switch the remotes mode inside the backend. The next butto=
n=20
press should be send up like there were two buttons pressed (ModeName +=20
ButtonName).

I think we are getting somewhere but there are still many many issues and u=
se-
cases to work out. Especially the Bluetooth AVRCP things produce some heada=
che=20
here... Also I think even with the mode-switching stuff beeing solved=20
underneath the shortcut system, this approach is still way more limited to=
=20
what it is now.
=46or example with KRemoteControl you can assign multiple actions to one bu=
tton.=20
The shortcut system doesn't allow this. KRemoteControl allows specifying wh=
at=20
to do when the button is held down or you can launch the target application=
 if=20
not already running. A standard shortcut ends up in nowhere if the respecti=
ve=20
application is not running. With KRemoteControl you can send the action to =
all=20
instances of an application while shortcuts always go to the one having foc=
us=20
etc...
As another example you can configure KRemoteControl like this:
We are in mode "Music" and amarok is running. If the user presses the "TV"=
=20
button, amarok is closed, the remote is switched to the "TV" mode and a TV=
=20
application is launched. All this just with one button press. Don't think t=
his=20
would be possible with the shortcut-system-solution.

Another approach I could think of would be some sort of special mode in=20
KRemoteControl whitch doesn't send out D-Bus calls but generates key presse=
s.=20
This way, you could use KRemoteControl as usual but when switching the remo=
te=20
to the according mode all button presses are routed to the shortcut system.=
=20
This even could be the default if the user doesn't set up any actions in=20
KRemoteControl.

Cheers,
Michael


--nextPart2515798.oyF8ogRJsG
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)

iEYEABECAAYFAkujvdUACgkQXJwWsxE5x7gEsgCdFJVkY0EHxd80gSxWmdIeI7QZ
2NcAnROyv+FdC+qzOqRgcg4B8kOGLQDO
=yz3G
-----END PGP SIGNATURE-----

--nextPart2515798.oyF8ogRJsG--