[Kde-hardware-devel] Data format for RemoteControl events

[Christopher Blauvelt]

On Wed, Sep 9, 2009 at 4:40 PM, Michael Zanetti <michael_zanetti at gmx.net>wrote:

> Hi all,
>
> As some of you may know I'm currently working on a remote control
> integration
> for solid with a lirc backend. Now I have a problem regarding the api.
>
> Until now, lirc remote control keypresses are represented as a free-form
> string containing the button name. The button names are defined in
> lircd.conf
> and for this they vary from remote to remote and from system to system.
>
> As you can immagine this makes it really hard for application developers to
> work with remotes because you need a place where you can map those free
> form
> strings to functions.
>
> It would be very nice to have a set of defined buttons an app developer can
> work with. For example a slideshow tool could just connect to the
> buttonPressed(event) signal and process it like:
>
> switch(event->id()){
>        case Left:
>                showPrevious();
>                break;
>        case Right:
>                showNext();
>                break;
> }
>
> Well, the lirc and ubuntu guys have also recognized this problem and have
> created something called "namespace". This is a defined set of button names
> that tries to stay as near as possible to linux/input.h. [1] Currently
> about
> 60% of lirc remotes are converted and work is going on.
>
> In my opinion it would be a good idea to adapt this. On the other hand, I
> would like to stay compatible to backends not having defined button names.
>
> This means I'd need something like the following:
>
> class RemoteControlEvent
> {
> public:
>  enum ButtonID {Play, Pause ... Stop, Invalid};
>
>  RemoteControlEvent(const QString &buttonName);
>  RemoteControlEvent(ButtonID);
>
>  ButtonID id();
>  QString name();
>  QString translatedName();
> };
>
> If the event is created using the QString c'tor it would set the ID to
> ButtonID::Invalid and indicating the app developer that this isn't a button
> defined in the namespace. He can use the free-form string or just ignore
> it.
>
> If the event is created using the ButtonID c'tor, the id would be set
> accordingly and the name would be set to a nice human readable name of the
> button. Also, the perhas a translated name would be of interest if the
> developer would like to show it in a ui.
>
> However, the lirc namespace contains already about 400 button ids... This
> is
> quite a lot and im in daubt if my approach is really the best in this
> situation. It would require a 400-entries containing enum and some 400
> entries
> containing switch statement for the names and translations... Also, this
> wouldn't be very nice to maintain...
>
> Is there a better way or perhaps already a KDE way of dealing with such
> problems?
>
> What do you think about the situation? Thanks for all your input.
>
> Cheers,
> Michael
>
> [1] https://wiki.ubuntu.com/RemoteControls (Section Lirc Signal Naming)
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>

Your caution in creating an enum for every imaginable button is warranted.
 I can't imagine what LIRC would need over 600 defined buttons for on a
remote control.  If you're going to go that way your idea of creating a
limited subset of those buttons and having a catch-all (Invalid) to go back
to string checking would definitely work.  I would change Invalid to be
Unknown to keep with the Solid naming convention.

Another idea would be to make use of the predicates.  This way relevant
buttons could be checked for as predicates which would be much faster than
string matching.  I'm not sure of the technical issues with doing that, I'm
just brainstorming.

Also keep in mind that any API you choose should be able to be used on other
OS's so while it will be natural to mirror LIRC pretty closely, that might
not be a good API for a backend on other systems.

Don't take it as a lack of interest that nobody had answered you.  Kevin
typically takes weeks to answer emails :)

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20090912/4aa99ac8/attachment.htm