Solid::Control::RemoteControl + KDE shortcut system [was: KRemoteControl moved to kdereview]

[todd rme]

>> <michael_zanetti at gmx.net> wrote:
>> 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.
>>
>
> Bluetooth is somewhat special... For example AVRCP 1.4 specifies "player
> selection". That means a remote control is able to specify to which
> application it gets routed. Wouldn't work out with current KHotkeys system as
> it always gets routed to the current input-focus...

Blueooth was just an example of the sort of thing that might
potentially benefit from this.  If it won't work that doesn't really
have any impact on whether it would work with other input devices.

>> 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.
>>
>
> Nope... Also KRemoteControl isn't useful for that. It would require
> Music/Video Players to register at the RemoteControl API so that a Bluetooth
> remote control can browse registered players, and select the target
> application by itself. Each registered application must be able to provide
> Metadata to the remote control system by itself.

Okay, but my point is that anything else any input device needs to do
can be handled elsewhere (what handles it is irrelevant), only
assigning buttons to actions would be handled by the shortcut system.

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

Yes, I understand that.  My point is that the keyboard manufacturer
thought that changing modes on a keyboard was so useful they built it
right into the hardware.  It was support for my assertion that making
the support for modes more generally available to input devices would
be worthwhile.  I know the implementation is different.

> I think we are getting somewhere but there are still many many issues and use-
> cases to work out. Especially the Bluetooth AVRCP things produce some headache
> here...

I don't really think that is that important.  If implementing this for
bluetooth devices is not easy, it can be done later or not at all.
There is no reason every type of device has to be ported over to this
system simultaneously.  That is what is great about providing
pluggable backends, support for new devices can be added when the
backend is completed.  Currently the only devices types that actually
have this capability are keyboards and remotes, so switching to this
system would mean that other device types don't lose anything.

> Also I think even with the mode-switching stuff beeing solved
> underneath the shortcut system, this approach is still way more limited to
> what it is now.

There is no need to even switch the remote control system over right
away.  It might be possible to set up the pluggable backend system
with only current capabilities and port the keyboard system to that.
Then, as capabilities are added, when it gets the point where it has
the features that the remote control system needed it could be ported
over then.  But it means any feature implemented for one input device
automatically benefits all other input devices for free, meaning each
developer doesn't have to re-implement the same things over and over
again.

> For example with KRemoteControl you can assign multiple actions to one button.
> The shortcut system doesn't allow this.

Which I think is a problem with the shortcut system that should be fixed.

> KRemoteControl allows specifying what
> to do when the button is held down or you can launch the target application if
> not already running.

Once again, I think this would be very useful for the shortcut system
(it would probably be a per-application setting in the shortcut
configuration dialog).

> A standard shortcut ends up in nowhere if the respective
> application is not running. With KRemoteControl you can send the action to all
> instances of an application while shortcuts always go to the one having focus
> etc...

Yes, this is something that I think the shortcut system would benefit
a lot from.  I could imagine another column in the application
shortcut configuration for commands that are sent to all instances of
an application.

> As another example you can configure KRemoteControl like this:
> We are in mode "Music" and amarok is running. If the user presses the "TV"
> button, amarok is closed, the remote is switched to the "TV" mode and a TV
> application is launched. All this just with one button press. Don't think this
> would be possible with the shortcut-system-solution.

It would probably be in the mode-switching configuration page.  I'm
not sure what makes remote controls special in a way that would
prevent this from being implemented elsewhere.  Once again, I think
this is something that would be worthwhile in the shortcut system.

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

This would only increase the number of configuration tools that you
would need beyond what we have now.  It would make things worse, not
better, by increasing the number of steps people have to do to get
their device working.

The whole point of this idea is to reduce the number of configuration
tools, reduce the number of steps needed to configure a device,
eliminate the need for application and device configuration developers
to maintain their own separate shortcut system, make configuration of
devices more consistent, make interaction between devices easier,
increase the number of devices users can make use of, and increase the
variety of devices available to applications without the applications
developers having to do anything.

I agree there are limitations in the shortcut system.  But I draw a
different conclusion than you do.  My conclusion from this is that the
shortcut system needs to be improved.  It really hasn't changed much,
if at all, from a user standpoint from the 3.5 days.  Across almost
all of KDE we see a trend of integrating things and making them more
consistent with pluggable back-ends to provide new capabilities in a
consistent and predictable manner.  Solid provides an integrated
method for getting device information, with pluggable backends for
various device types.  Plasma provides a consistent interface and
configuration tools for everything on the desktop, and data engines
allow for pluggable backends for a variety of types of data useful to
the desktop.  Phonon provides a consistent multimedia interface
independent of the multimedia backend.  Akonadi provides a consistent
interface to various pim types with new pim data and pim types being
made available by adding backends.  KIO provides consistent file
manager interaction for a wide variety of filesystems, file types, and
tools, once again with the ability to add new backends.  GHNS provides
a consistent manner to get new content, with application developers
being able to specify which content they want and from where.  There
is an integrated high score system for games.  Some of these are old
parts of KDE, but more and more of KDE seems to be moving in this
direction.

We have been seeing great improvements in consistency and versatility
across KDE software and libraries.  Systems that are similar are being
integrated in order to make maintance easier (it is easier to maintain
one system than many), make it easier to add new systems of the same
type, and make configuration simpler, easier, more consistent, and
more powerful for users.  I don't see any reason why the shortcut
system wouldn't also benefit from this.  I think if we look at how KDE
has been evolving across the board, this is the natural next step for
the shortcut system to bring it in line with the rest of KDE.  The
shortcut system seems to me the only major KDE system that has made
little or no visible outward progress.  I don't mean to denigrate
developers, there may be a lot happening under the hood, but from a
user perspective there has not been much visible change in what the
shortcut system can do.  But I think there is a huge amount of room
for improvement, and taking the same approach used by other KDE
software would be the best way to do it.  Rather than having a fairly
basic shortcut system, KDE could be at the forefront of input device
integration and support like it is in so many other areas.

-Todd