[Kwintv] kdelirc support

[Zsolt Rizsanyi]

On Sunday 27 July 2003 21.37, George Staikos wrote:
> On Saturday 26 July 2003 20:37, Zsolt Rizsanyi wrote:
> > Hi!
> >
> > I have added support for the new kdelirc project (which will be very
> > probably included in KDE 3.2, but now can be found at kdenonbeta/kdelirc)
> > to qtvision. It fully replaces (in functionality) our current lirc code.
> >
> > Now the question is, what should happen with the old code. Should it be
> > removed completely, or just disabled by default?
> > And if disabled, then via ./configure, or should it be configurable by
> > GUI?
> >
> > Currently the initialization code is commented out, since it would be not
> > too good if both kdelirc and the old code would try to control qtvision
> > simultaneously.
> >
> > I vote to remove the old code. But anybody can veto this :)
>
>   We can't do this until 3.2.0 is in common use.  For now I think it would
> be ideal to use the preprocessor to enable one or the other conditionally
> based on if the user is on 3.1 or HEAD.

I'm currently using kde 3.1 plus kdelirc from kdenonbeta. Kdelirc is not yet 
part of HEAD.
So your solution does not work.
Besides if somebody can compile qtvision from kdenonbeta cvs then he can do 
the same to kdelirc too.

IMO the only reason to keep the old lirc code is to support people who 
explicitly dont want to use kdelirc for whatever reasons (eg. they are not 
running the KDE desktop).
In that case we should add a ./configure option to explicitly enable lirc 
support (eg. --enable-qtvision-lirc-support with a note that it is deprecated 
and they should use kdelirc instead).

>   Thanks for doing this work!  Also thanks for merging with the patch from
> Dirk.
>
>    Dirk: sorry, I was away at OLS and had no time to review the patch.  The
> list is the best place for this stuff though.
>
>    Regarding the ZVBI compile problems, whichever is the most recent has to
> be the one we support.  Anything older, you can make conditional compile if
> you like, but that's a lot of work.  Hopefully they will stabilize their
> development soon.  We should try to put in an autoconf check for the
> libzvbi version number too I think.

I have solved the problem by completely avoiding to declare the function 
pointer whose prototype changed.
Now we only call the function where a const attribute doesn't make such a big 
problem.

Regards
-- 
Zsolt Rizsanyi



____________________________________________________________________
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu