[Kde-bindings] Common work for Qt4 bindings

[Richard Dale]

On Tuesday 20 September 2005 20:32, Simon Edwards wrote:
> On Tuesday 20 September 2005 19:33, Eric Jardim wrote:
> > 2005/9/20, Simon Edwards <simon at simonzone.com>:
> > > Are Java and C# bindings really worth the effort? Would they be used?
> > > Sure it
> > > looks good for KDE if more languages are supported, but can't say I've
> > > seen
> > > much demand for Java/C# in the KDE community itself.
> >
> > IMO, this can only be anwsered by time. I also think that static
> > languages, like Java and C#, will not take advantage over the already
> > standard static C++.
>
> I agree. The mindshare market segment for a C++/Java/C# style language is
> already taken on KDE. => C++ is it.
>
> While for the Gnomes it is a different story. They started with C. Not even
> OO in that case.
>
> > Firstly, what are the benefits of Smoke over SIP? I know that Smoke
> > offers
> >
> > > the
> > > possibility of one library being reused for multiple languages, but
> > > other than that what's the difference?
> >
> > I think it is different. For what I know SIP is not completely automatic,
> > and only works for Python. Smoke will be an intermediate solution for all
> > languages. Besides, I think SIP binds each method of each class, while
> > Smoke is more dynamic and queriable (more slow, specialy to load). Well,
> > I am not very sure of this.
>
> I thought Smoke did this too.
>
> > The good points of SIP is that it is ready and on the road for a long
> > time. I don't know the end of this story, but if we can do it better, why
> > not? The worse that can happen, is to be the same it was.
> >
> :) All I ask is that Python (or whatever language) bindings stay compatible
>
> with each other. The last thing I want to see is SIP+KDE Python programs
> and Smoke+KDE Python programs.
Yes, I agree. There are very few people who work on KDE bindings projects, so 
the most important thing is that we ensure we cooperate as much as possible, 
and not step on each other toes. I think the best approach is to make sure 
that every viable language binding is ported from Qt3 to Qt4, and only then 
talk about some  way of integrating them for KDE 4 if that seems a good idea.

-- Richard