[Kde-bindings] Qyoto: SIGNALS/SLOTS

[Adam Treat]

On Monday December 19 2005 7:02 am, Richard Dale wrote:
> In Qyoto the '_smokeObject' is a pointer directly to the C++ instance, it
> is a struct which contains that pointer, along with several other things.
> So it is the direct equivalent of the Qt# QtSharp class.
>
> From qyoto.h:
>
> struct smokeqyoto_object {
>     bool allocated;
>     Smoke *smoke;
>     int classId;
>     void *ptr;
> };
>
> The 'ptr' field is the C++ instance. 'allocated' is true if the C# instance
> was allocated from the C# side, or false if an existing C++ instance was
> wrapped, and the C++ instance shouldn't be deleted on garbage collection.
> 'classId' is a numeric identifier that is used in the lookup tables inside
> the Smoke library. 'smoke' is a  handle to the Smoke library instance being
> used for the class (always the same for every class in the current
> implementation).

Ahh, that is cool.  I had something similar for libqtsharp.  So, Arno, it 
looks like the problem you were having was you were trying to connect the 
smoke object directly, instead of the underlying QObject which is the void 
ptr.  However, I think Richard is absolutely right, you don't want to be 
using Qt#'s libqtsharp for signal/slot connections on the C/C++ side of 
things when SMOKE will provide this for you.  Better to do it the SMOKE way 
since that is the binding library.

> The underlying slot/signal implementation and marshalling from QtRuby will
> work fine with Qyoto, and so we don't want to rewrite that without good
> reason. But you might be able to get some ideas about how to combine
> delegates with slots/signals from the Qt# stuff. I learned about the
> 'internal' keyword, and 'as' casts anyway, which we can maybe use in Qyoto.
>
> -- Richard

Yah, that's what I had in mind.  Not so much anything from libqtsharp would be 
of use, but that Qt# would come in handy for clues on the C# side of things.

Adam