[Kde-bindings] KDE4 Smoke ideas

[Richard Dale]

On Friday 10 June 2005 07:43, Ashley Winters wrote:
> As I promised earler, I threw up my ideas for a Smoke based off Qt4's
> meta-calling conventions. It's long and technical.
>
> http://jahqueel.blogspot.com/2005/06/smoke-for-kde4.html
>
> The cliffs notes version:
> * Every function should be made a slot
>   - that means you can connect() to anything
>   - only one function call implementation required to use regular
> functions, virtual functions, and signals/slot
>
> * non-QObjects should have QObject proxy classes
>   - QString/QRect/etc functions would be slots, and called the same way
> as everything else
>
> * Virtual functions in C++ should emit themselves
>   - that probably means you can have multiple mouseMoveEvent handlers
>   - you can handle virtual functions in ANOTHER object
>     + $foo->connect($bar, mouseMoveEvent => 'doSomething')
A good read! These are my thoughts so far:

We couldn't use the metaobject system before in Qt3 because slots didn't have 
return types.

How would the size of the generated code compare with the current Smoke 
versions? I think we can do some tests on that to get estimates. We still 
need a slot for every inherited virtual method in the scripting proxy class. 
I imagine the size should be much the same.

I like the idea of having a signal connected to itself as a slot, which you 
disconnect and connect instead to the method in the scripting language to 
override. At the moment, the ruby bindings use a 'respond_to?' test to see if 
a virtual method has been overriden at runtime. But in ruby you can implement 
hook methods which are called whenever a method is added to a class or an 
instance. That could mean that we could intercept in the hook, and if virtual 
methods are overriden, do the disconnect/reconnect there.

I wasn't sure about the bit at the end about slots and signals, and it doesn't 
solve the problem of resolving ambiguous arg types in any C++ slots or 
signals you might want to connect to. Only for slots/signals defined in the 
scripting language.

If every method was now a slot, would that make debugging confusing? At the 
moment the QObject heirachy, and slots/signals look just the same in QtRuby 
as they do in a C++ app. That would change with the new Smoke, which may well 
be an improvement anyway - or it might be confusing.

I think basing Smoke on the standard Qt4 metaobject system would go down very 
well with Trolltech, which might make them more enthusiastic about commercial 
versions.

I don't think it will be too much work to get the current QtRuby bindings to 
Qt4 using qt_metacall(). We will probably need to be able to create 
QMetaObjects on the fly still, whichever Smoke version we use. Although they 
can be created at code generation time for Smoke version 2, it still seems a 
useful thing to be able to do.

-- Richard