[Mono-list] Re: Status of the Qt c# bindings

[Richard Dale]

On Tuesday 05 March 2002 8:36 pm, Adam Treat wrote:
> > Have you got C to C# callbacks working yet? I've seen the P/Invoke code
> > which calls C from C#, and then in turn calls C++. But can you call C
> > from C#? For example, is it possible to do this?
>
>  ....
>
> > Event handlers can be nested too with drag and drop, and slots/signals
> > can also be nested. There are event handling and slot/signal callbacks in
> > the QtC bindings that it should be possible to use for this - I don't
> > know how far you've got..
>
> Haven't looked at this.  I don't think Mono contains the ability for native
> code to call managed code at this point.  It is rather, a one way
> relationship ;-)
Oh dear - I did wonder about whether Mono could do that. Is it a feature which 
is on the way, or is there some technical reason why it won't be done?

> > More virtual method callbacks in the QtC bindings are needed if you want
> > to do more than just customize event handling though.
>
> This is not on the horizon yet.  I am going to try and fix all the kinks in
> the bindings first and then worry about more advanced aspects like this a
> little later.
The extra callbacks aren't too difficult to generate, I had thought they would 
make the libraries too large, but it doesn't add too much (eg third Mb for 
Qt). If I do that for java, it should be simple to add much the same thing to 
the C bindings.

> > > 2.  Several Qt classes are missing methods and constructors because...
> > > 3.  The type mappings are not completely fleshed out
> >
> > Do you mean you need to complete the runtime conversion functions to
> > convert between C# and Qt types?
>
> No, I just need to complete the mappings and deal with things like multiple
> methods with C parameter types that map to singular C# parameter
> types.  For instance QString has duplicate methods 'contains' and
> 'section'. I say they are duplicate because one takes 'const char' and
> other 'char' for C parameters but currently these _both_ map to the C# type
> 'string'.  This is probably an incorrect mapping, but that was what I was
> referring to.  We also have the issue of using QString at all or
> engineering the bindings in such a way that you would just use the C#
> 'string' type and then map that to QString behind the scenes and use that
> to call the C function.  These are issues I'll be dealing with now that the
> bindings compile.
I prefer to hide QString. If there is more than one method with the same name 
taking different sorts of C++ string args and mapping onto a single 
java.lang.String method in Java, I go for the one with a 'QString' arg and 
junk the others.

> > If you can do it for 300+ Qt classes, then it's just more of the same for
> > KDE.. You can convert KDE kdoc comments to C# style xml, which should be
> > fun though.
>
> Yah, the KDE classes are next.  I am going to refine the qt bindings first
> though.
>
> > > Congratulations!  Would you like to put this on CVS?
> >
> > Yes, agreed! And the code is also most welcome in the kdebindings CVS
> > too. Maybe it wouldn't do any harm to have it in both places. But if you
> > check in the kalyptus C# + P/Invoke bindings code generation option into
> > kdebindings, I would be happy to help tweak it.
> >
> > Please add the QtC bindings to the Mono cvs too, if people want them
> > together, that's fine with me.
>
> I will be happy to put this in cvs.  The qtc# bindings will require the qtc
> bindings so... to go in mono's cvs would probably require those qtc
> bindings. Either way, let me polish up the bindings and I'll have something
> to put in there very soon.
OK good. The QtC license is LGPL (is that ok with Mono?), and I noticed you 
had a GPL header in the example you sent me.

-- Richard