[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-hardware-devel
Subject: Re: [Kde-hardware-devel] Data format for RemoteControl events
From: Michael Zanetti <michael_zanetti () gmx ! net>
Date: 2009-09-12 10:51:37
Message-ID: 200909121251.39573.michael_zanetti () gmx ! net
[Download RAW message or body]
No ideas, anyone?
Michael
On Wednesday 09 September 2009 22:40:13 Michael Zanetti 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@kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>
_______________________________________________
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic