kdelirc

[Michael Zanetti]

On Thursday 09 April 2009 00:46:29 Friedrich W. H. Kossebau wrote:
>
> It should move to kdereview in the next two weeks, so it can have the two
> more weeks in there before the hard feature freeze comes.

OK, I'll do my best... :)

>
> > 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
- 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
- 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).
- 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 thought bringing kdelirc back to a usable and maintainable point as a 
first step would make more sense.

> > It is not 100% finished yet, but we're on a good way. All the
> > functionality is restored. We still have to do the following tasks:
> > - Finishing rework of kcmlirc.cpp
> > - Fixing some bugs introduced during rewrite.
> > - creating svg icons
>
> - adding your names to the copyright notes in all files touched and the
> KAboutData
>

Yep. I'll do that.

> > - some general cleanup (krazy checks etc)
>
> E.g.
> * fix "kdelirc/kdelirc/profileserver.cpp:120:
>   warning: returning reference to temporary" & Co.
> * also constBegin() and constEnd() with ConstIterators
> * official writing is "D-Bus"

Yeah, thats what I meant.

>
> > 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!

> > 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...

> Some more comments:
> * Why did you not make ${kdelirc_shared_SRCS} a private shared library,
> instead of compiling the sources into both the settings module and the
> server?
Yes, that would make sence...  Currently it is still the same as it was in 
KDE3. Perhaps I'll change that before moving to kdereview if it doesn't break 
too much.

> * The warning text in the tab "Controller Functions" should be wrappable,
> it is too wide for my screen.
> * Could you perhaps split the "Extension overview" into two tabs, one for
> the controls, one for the applications? Currently the single tab looks very
> complex.
> * The name "Extension" is not used anywhere else in KDE. Perhaps you could
> use another name which matches (no idea right now).
>

Thanks for the hints. I'll look into it.

> Can't check more, for one I have no infrared controller available, for the
> other the builtin infrared receiver seems not supported with my current
> setup:
> --- 8< ---
> #rclirc start
> Starting lircd .....Error: no device found
> --- 8< ---
>
> > If there are no objections, I would move it to kdereview as soon as the
> > above tasks are finished.
>
> Know of no other objections. I would be happy to welcome kdelirc back in
> kdeutils. Good luck with completing the tasks in time :)
>
> I guess you already read
> 	http://techbase.kde.org/Policies/SVN_Guidelines
>  	http://techbase.kde.org/Policies/Suggested_Review_Criteria
>

Sure.

Thanks for your comments,
Michael