[Kde-bindings] KDE4 Smoke ideas
Richard_Dale at tipitina.demon.co.uk
Fri Jun 10 08:46:15 UTC 2005
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.
> 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
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
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
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.
More information about the Kde-bindings