RE: SWT issue with current Mono

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Pablo Baena
> Sent: Sunday, October 26, 2003 12:00 PM
> To: [email protected]
> Subject: [Sd-mono-port] SWT issue with current Mono
> 
> 
> I was tracking a bug in SWT that resulted in a mistake on the 
> API when passing 
> strings to g_list. Some imported native functions where being wrongly 
> prototyped so when marshaling was implemented correctly in 
> Mono (latest CVS), 
> some bugs arouse.
> 
> So with the help of the Mono people I now know the way to 
> solve this in SWT, 
> but this got me thinking. Why not use Gtk# to solve the low 
> level stuff like 
> importing Gtk functions, converting back and from unicode, 
> and other millons 
> of issues? (notice that not even Gtk# tackles the conversion 
> of unicode 
> strings correctly yet, but when they do, SWT will have it done right).
> 
> I know this creates a dependancy on Gtk# and adds weight to 
> the API, but how 
> much it would affect the perfomance? Let's say we do (this is 
> a stupid 
> example):
> 
> namespace SWT.Widgets {
> 	class Combo : Gtk.Combo {
> 		// ...
> 	}
> }
> 
> Would this really make the API much slower? You now do all 
> the importing and 
> conversion of native to managed data types...but doing this 
> all that will be 
> done in the Gtk# binding.
> 
> I haven't studied this profoundly, but if it can be done, I 
> think it would be 
> the best way to do it and I am interested on helping with it.
> What do you think? Do you see it possible?

SharpWT on GTK needs to have the native glue library removed, one way or
another.  It's vestigal from SWT I believe (JNI), and probably only
exists as no one had gotten around to doing all the MarshalAs goo
required to stub the more complicated functions, or it didn't work on
Mono at the time.  I'd suspect it'd be a lot easier to finish C#-izing
the remaining stubs in the glue library (and fixing things like missing
uses of IntPtr) than changing it to use GTK#, as the GTK layer assumes a
procedural GTK library, and going forward, merges in from SWT will be a
lot easier if these assumptions aren't changed.