[Kde-bindings] Blowin' smoke your way

[Richard Dale]

On Wednesday 10 September 2003 21:01, Ashley Winters wrote:
> --- Adam Treat <manyoso at yahoo.com> wrote:
> > How about Qt signal/slot mechanism... have you found a way to connect
> > a Qt
> > signal to a function pointer?
>
> Umm... harder question. Signals/slots is uniquely suited to marshalling
> since Qt does it internally (Qt-3.x always pushes the arguments into an
> array and tosses them around to the dispatchers).
>
> In order to provide a generic signal => function pointer converter, it
> would probably require ~200 generated functions to handle every
> combination of signal/slot arguments and pass them to a delegate
> pointer. It's very doable -- just steal the code from PyQt.
That's what Qt# has already got - one problem is that the underlying C 
bindings have a pretty poor slots/signals support. 

I'll keep the existing style of java delegate signals/slots for the Smoke 
based QtJava, because you can't add methods to an existing class (nor can you 
in C#), and the implementation in PerlQt or QtRuby depends on that.

I think the big problem with the slots/signals implementation in QtRuby is 
that it uses the original C++ types - it should be possible to specify Ruby 
types instead:

'setText(String)', and not 'setText(const QString&)'

'myButton(Qt::PushButton)', and not 'myButton(QPushButton*)'

I think I'm going to customise the QObject::connect() methods so that they 
examine the target signal and the slot together, and generate different 
QMetaObjects according to what they find. So that a ruby signal with a String 
arg type might map onto either 'const QString&' or 'char *' in the target C++ 
slot, and a slightly different metaobject would be constructed to match. If 
the target slot was ruby, the type in the metaobject would always be 'const 
QString&'. A similar matching process would be needed in reverse where a ruby 
slot was connected to a C++ signal, and for C++ to C++ connections. Once, the 
actual call the QObject::connect() is made via smoke, the overidden 
metaObject() virtual method would return the metaobject just constructed.

What if someone wants to use the ruby signal 'foobar(String)' to match both 
C++ slots 'setText(char *)' and 'setText(const QString&)' in the same 
program? That should probably be an error.

-- Richard