[Kde-bindings] Hacking moc-generated code

[Eric Jardim]

2005/9/9, Richard Dale <Richard_Dale at tipitina.demon.co.uk>:
> 
> Yes, that looks familiar. To emit signals from python you need to 
> dynamically
> add python methods for each signal, which in turn call
> QMetaObject::activated() once they have converted their python args to 
> C++.


Well, this is not necessary, but this is the more natural way. We can create 
a single "emit" method. But we need to somehow register the signal on the 
MetaObject, so there might be a "registerSignal" method too.

Different from SIP/PyQt, there is no distinction from Python and C++ 
signals. This is very good.


I read about Boost::Python, and I'm not sure if the approach of manually
> defining wrapper code for every method and class will scale for a library 
> the
> size of Qt/KDE with about 10000 classes and over 25000 methods. 


10000!?! I taught that it was 400 from Qt and a few other from KDE ;) But 
you are not obligated to do it manually. I prefer doing it manually to 
understand each the nuances of the bind. 

Manually, at the end, you get a more "pythonic" bind of the Qt (and so KDE) 
library. Actually, there is a tool called Pyste, that you write Python code 
that will wrap the C++ classes. But it is not 100% automatic.

But after I got enough "know-how", it will be possible to create some 
scripts to extract the interface. But Pyste itself is not enough the get the 
result that I want. Probably I will need to tweak it and create my custom 
Pyste.


I think you
> might find you need to autogenerate the boost python wrapper code, at 
> which
> point it might have been better to start from scratch with a Qt specific 
> tool
> which knew about Qt memory management policies and calling conventions.


Sure, that's just what I said. 

It will be interesting to compare with the python/SIP with Boost::Python, 
> and
> 
with perl/ruby Smoke approaches being using at the moment.
> 

I don't understand what is Smoke. Sorry, I am new at this KDE bindings ;) 

But if it give us a standard infra-structure to bind the Qt/KDE, we could 
even interoperate between bindings languages!

That's it,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20050909/3c92656f/attachment.html>