Moveing KDevelop from python

[Richard Dale]

On Friday 10 May 2002 5:43 pm, Bernd Gehrmann wrote:
> On Monday 06 May 2002 22:05, you wrote:
> > On Monday 06 May 2002 3:43 pm, Bernd Gehrmann wrote:
> > > No, you always pay. Wrappers of any kind that are not automatic suffer
> > > from bit rod over time. See also the java bindings for an excellent
> > > example.
> >
> > I agree the java bindings are difficult to keep up to date. But the only
> > solution that has been suggested is to make the static bindings
> > generation more complete and less error prone, so that less skill is
> > involved in maintaining them. C++ is a static language, apart from
> > Trolltech's extensions (RTTI is no use for dynamic programming). Even
> > Apple's Cocoa Objective-C <--> Java bindings need some static hints,
> > although it can do a whole lot more at runtime.
>
> I'm not sure what exactly you mean by "static hints", but one way to
> influence the code generation would be to add certain kdoc-like
> tags to the header files instead of modifying the code by hand after
> the code has been generated. Don't know if that's possible in the
> cases you are talking about.
I was thinking of the tool on Mac OS X called 'bridget' - it can take .jobs 
files which specify conversion hints. Or it can do the conversion 
automatically, but I don't really know much about it though. But converting a 
C++ api to Objective-C (or Smalltalk) is about the hardest wrapping project 
you can do, because the method naming is so different to everything else. And 
you can't call C++ directly from non-Apple Objective-C at the moment.

I had thought kdoc tags would be a good idea, but the more I find out about 
bindings the less they seem needed. Although one thing that seems difficult 
to identify automatically is what are senders/receivers and slots/signals in 
the C++ methods. 

> > Ashley Winters has done some *very* interesting stuff in wrapping the Qt
> > api (and soon the KDE one) in a language independent manner.
>
> Looking at xdata.cpp, I wasn't aware that C++'s multiple inheritance makes
> so many problems...
Yes, at the moment I think it just handles a maximum of two parent classes. 
But the maximum in the KDE api is about six for some of the xml stuff.

> Anyway, sharing as much as possible between different languages
> certainly seems like a good way to reduce maintainance costs.
Yes, I think it may well leave most previous scripting bindings projects in 
the dust, and looking like amateur hour.

The project has a name now 'Scripting Meta Object Kompiler Engine' or SMOKE 
(verb: to 'smoke' a library). The language independent part is checked into 
kdebindings/smoke, and will build libsmokeqt.so and libsmokekde.so for the 
two libraries. Then you'll need a libperlqt.so and libperlkde.so (or 
librubyqt.so, librubykde.so etc) for perl.

-- Richard