kdelirc

[Friedrich W. H. Kossebau]

Hi Michael,

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 
signal/slots etc.

> - 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:
http://frinring.wordpress.com/2009/04/12/infrared-control-coming-back-to-kde4/

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?

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta