[Kde-bindings] Hacking moc-generated code

[Richard Dale]

On Friday 09 September 2005 16:34, Eric Jardim wrote:
> 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.
You need some syntax to emit a signal:

emit foobar("hello", 5)

So emit() would be a method which doesn't actually do anything, then foobar() 
might actually map onto a common method for all signals. You then look at the 
current stackframe to find the name of the actual ruby method, then look up 
it's id number via the QMetaObject.

> Different from SIP/PyQt, there is no distinction from Python and C++
> signals. This is very good.
Yes, it's better to have exactly the same syntax for using both python and C++ 
signals.

>
> 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.
Oops, typo make that just 1000 classes.

> 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.
That sounds interesting. I'm pretty sure your shouldn't have to intervene to 
make the binding more pythonic

> 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.
Yes, it sounds worth experimenting with.

>
> 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 ;)
Smoke is a language independent auto generated library used by the QtRuby and 
PerlQt bindings at the moment. It could be used by java, C# and possibly 
python too. At the moment its main problem is that it's too monolithic, and 
everything is all in one big library. It stands for 'Scripting Meta Object 
Kompiler Engine', and is a sort of 'moc on steroids' - it adds an 
introspection layer for the complete api, and a language independent way of 
invoking methods dynamically, or virtual methods callbacks.

> But if it give us a standard infra-structure to bind the Qt/KDE, we could
> even interoperate between bindings languages!
Yes, that's the idea. Otherwise, you need a large library for each language, 
instead of a single wrapper library like Smoke, with a smaller 'adaptor' 
layer for each language. A future version of Smoke could use the Qt4 moc 
format, but include ordinary methods as well as signals and slots, along with 
a way of adding virtual method callbacks so you can override them in the 
scripting language.

-- Richard