[Kde-bindings] Re: AW: AW: [Kde-perl] PerlQt port for Qtopia / Zaurus?

[Richard Dale]

On Sunday 26 January 2003 1:40 am, Ashley Winters wrote:
> --- Germain Garand <germain at ebooksfrance.com> wrote:
> > Le Mercredi 22 Janvier 2003 00:04, Richard Dale a crit :
> > > I have done a prototype of proxy based slots/signals that worked
> >
> > with smoke
> >
> > > (I favour this way, and Ashley doesn't..). It would be interesting
> >
> > to
> >
> > > compare a proxy based solution with Ashley's 'hack the metadata and
> > > reimplement moc generated code' type solution.
> >
> > Looking back at your prototype, I think it would be very interesting
> > but IIUC,
> > it would mean having a hundred or so proxy classes, to cover the
> > whole
> > spectrum of possible combination of Sig/Slot basic types (to what
> > depth ? 6
> > or 8 arguments ? )...
> > That sounds hudge and a bit limiting... or am I missing something ?
>
> Only something small. :)
>
> In actuality, you only need one class (ProxySlot, for instance) which
> would proxy all the signal/slot prototypes in Qt. In reality, there are
> only about 70-100 (?) variations of signal/slot arguments in Qt and
> KDE, which is all you'd "need" for a language binding. That's how PyQt
> and Qt/Java work.
Yes, good summary. 

One thing that the QtJava and C# bindings have (not sure about other 
languages), is a table of java or C# slot/signal type signatures against 
their C++ equivalents. Then instead of connecting a 'foobar(const QString&)" 
or 'foobar(char *)', you can connect a "foobar(String)". The bindings runtime 
will look at the QObject emitting the signal and test what signals that match 
a 'String' signal type via the Qt metadata (ie either 'const QString&' or 
'char *' here). Would Ashley's style of slot/signal handling be able to do 
this - I've think I've seen 'char *' used as a signal type in the PerlQt 
examples on the list?

> However, in never-never land, you'll notice something Bad can happen.
> Consider this thought experiment!
>
> class QFoo {
> public:
>     void insertThing(const QString &name, QThing *object, const char
> *);
>
>     // Note: the 'receiver' isn't a QObject! Read on for implications
>     // It's a subclass of QObject, and that's 100% legal.
>
>     // Secondly: the 'member' argument is unmarked. You'd have to code
>     // in by hand that the second object needs a slot proxy and
>     // the third argument is a signal/slot member
> };
>
> # From PerlQt:
> $foo->insertThing('&Foo', $object, SLOT 'whatever()');
>
> In order for insertThing() to connect to the proper slot, PerlQt would
> have to (transparently, AND specified by hand) pass $object's ProxySlot
> object to insertThing(). However, it's perfectly legal for
> insertThing() -- written in C++ -- to call
> object->thingSpecificFunction(), which would die on a proxy slot
> inherited from QObject. Creating 100 little subclasses of all the
> QObject child classes for signal/slot information is impractical, even
> if that could fix it (which it wouldn't).
Interesting problem - I hadn't thought of that. I not sure if it happens in 
practice in Qt/KDE. Maybe there are few enough examples that it could be got 
round by hacking/special casing the affected methods.

I've been converting David Faure's smoke generation code to emit java/jni, and 
I noticed it didn't do any special casing for these 'implied slot target' 
methods. I will probably work round the problem by adding a table of special 
cases in kalyptus, and use that to drive the generation of code to pass the 
proxy slot, rather the C++ instance in these methods.

> This all stems from the fact that connect() isn't virtual, and the
> meta-object interface has no friendly introspective wrapper class we
> can all use like happy lemmings. Here's waiting for Qt-4.x...
>
> Okay, I'm not actually ticked about it, since PerlQt-3's ugly,
> disgusting hack doesn't suffer from those problems. :)
Yes, I'm neutral - both have ugly points. The QtJava slot/signal handling 
works well enough (until I hit the problem you describe above), that I'd 
rather leave it.

I must look at the PerlQt 3 code, but it took me a long time to work out how 
you were doing it via function pointers in PerlQt 2. That would have needed 
rewriting for Qt 3, whereas the QtJava proxy stuff only needed a one line 
change. But then the Qt 3 mechanism is unlikely to change, and I don't see 
'future maintence' as a drawback anymore.

In smoke, I think the the slot/signal handling could be language independent 
and go in the smoke bit, rather that the language specific interface lib. The 
callbacks are much the same as the callbacks for virtual methods, which smoke 
does in a language independent manner.

-- Richard