On Wed, Sep 9, 2009 at 4:40 PM, Michael Zanetti
<michael_zanetti@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@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