Moveing KDevelop from python

[Richard Dale]

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.

> That's why I already mentioned this before.
No problem with me - I'm always interested in further discussion of these 
subjects.

Ashley Winters has done some *very* interesting stuff in wrapping the Qt api 
(and soon the KDE one) in a language independent manner. Try

export CVSROOT=":pserver:anonymous at perlkde.geo-ip.com:/home/kdecvs/perl"
cvs login
(hit enter)
cvs co PerlQt-3

Have a look at the x_* classes in PerlQt-3/qt. They wrap the Qt 3.0.3 api, but 
they aren't Perl specific.

Ashley wrote this on the kde-perl at mail.kde.org mailing list:

"... However, the kdebindings part of the project need not directly be a part 
of PerlQt. If you look closely, the perlqtaw-3 code has no Perl dependencies, 
and could be used for PerlQt, PythonQt, RubyQt, or whatever. That was my 
intention. If you use kdebindings to generate the x_* code, then use 
autoconf/automake to compile it into a shared library, you can just install 
it globally as a shared library. PerlQt would then just be the interface to 
that global scripting-language-interface-for-Qt-or-KDE library.

Mainly, I'd like this so I could statically link -lqt into -lqtbindings, or
run objprelink on it. You'd still have to put the autoconf/automake binding
business in a subdir of the PerlQt distribution so people won't have to
download it separately, but they *would* have to compile it separately. It
would also mean only one monster binding-interface library would have to be
installed to cover all KDE languages. Just an idea."

I think it's an awsome idea - and it does look as though it will work to me. 
Effectively the whole api has been put through a 'turbo-moc', not just 
slots/signals and properties. David Faure has adapted kalyptus to generate 
the x_* classes, and as far as I know they need no manual correction to 
compile.

-- Richard