Friedrich W. H. Kossebau
kossebau at kde.org
Sun Apr 12 18:22:53 CEST 2009
Le jeudi, 9 avril 2009, à 12:09, Michael Zanetti a écrit:
> On Thursday 09 April 2009 00:46:29 Friedrich W. H. Kossebau wrote:
> > > The current state:
> > > - It is fully ported to Qt4/KDE4. No Qt3Support.
> > > - We have heavily refactored/rewritten major parts because the original
> > > code was in a really bad state in terms of readability and
> > > maintainability. - It is basically the same program as before. There
> > > are some new extensions and remote controls.
> > So the idea with moving parts to Solid didn't work out?
> No, unfortunately not. The problem here is:
> - Solid won't make users liefe easier here because users still have to
> configure lircd
Yes, but this is true for some other devices Solid gives an API layer for.
> - Solid won't make developers life easier here because once lircd is set up
> all we need to do is read out everything from /dev/lircd
What about platforms which do not use lircd but something different?
The idea of Solid is partially to abstract the different backends (due to
different os platforms) into a common object-oriented API. And reading
directly from /dev/lircd is not what I as a potential developer who wants
access to an ir receiver subdevice (for something different than kdelirc)
would appreciate. I would rather like to have an QObject-subclass like
QTcpSocket or similar, which wraps the ir receiver device for me, with
> - Introducing lirc to solid seems to be a huge task as also hal doesn't
> know anything about lircd yet. (There is some work in progress but not
> nowhere near finished).
Solid is not restricted to only wrap the things hal offers, I think.
> - If this huge task gets done, in my opinion it should be done creating a
> completely new remote control framework including IR and Bluetooth/AVRCP
> and perhaps some other remote control devices too.
We share some thoughts here, at least :)
Still at a lower layer I see some usage for a Solid wrapper around the ir
receiver. But well, who codes decides :)
Will collect some more reasoning in the meantime... ;)
> - We thought bringing kdelirc back to a usable and maintainable point as a
> first step would make more sense.
Agreed, good approach also in my eyes.
> > > About the documentation: We still have the original one. It is not
> > > perfect but at least not worse that at KDE3 times. Perhaps someone has
> > > the time to help out here...?
> > Perhaps someone, e.g. me, can put this call for help into a blog entry?
> That would be nice!
So I did another exercise in writing english:
But please watch for the comments there yourself :)
> > > Are there any other tasks that I'm not aware of?
> > I just compiled it, besides some "returning reference to temporary" which
> > should be fixed, it could not see any problems in the built. But it will
> > need some checks for the os platform (BSD, Win, OSX), and hopefully get
> > support for the non-linux systems, too. The latter should come, once it
> > is in the module.
> I just have searched google for lircd on Windows. It seems to be
> unmaintained since 2006. I think we need another talk about this later...
Just restrict the compile to platforms supported by lirdc, then. I guess this
will be unix-platforms only, so a
if( UNIX )
endif( UNIX )
in the parent CMakeLists.txt should do. Especially, as IIRC Windows (and other
platforms?) has no /dev to read from, or?
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta
More information about the Kde-utils-devel