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

[Phil Thompson]

On Sunday 26 January 2003 3:11 pm, Richard Dale wrote:
> 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.

There are 16 occurences (I think) in Qt v3.

Phil