For people interested in working on the .NET bindings for tinymail: We should really discuss how we are going to support interfaces. I have a few ideas about this. (The Questions for the Gtk-Sharp people, and therefore the reasons why the list is added in CC, are below).
For example one of my current ideas is to create IDL files, generate my GType interfaces from such IDL files and let your language binding generate interfaces from the same IDL files but into the (higher) language that you are making a language binding for (in this case, .NET). The proxies will need to be smart about which C API to use. This means that the code generator which will generate proxy the instances who will P/Invoke the C code will need to generate the interface API rather than the concrete type's API. For example: A very simple interface in tinymail is the TnyMsgView: http://tinymail.org/API/libtinymail-1.0/libtinymail-tny-msg-view.html http://svn.tinymail.org/svn/tinymail/trunk/libtinymailui/tny-msg-view.c http://svn.tinymail.org/svn/tinymail/trunk/libtinymailui/tny-msg-view.h I'm assuming the generator would generate, from for example an IDL file, a .NET interface like this: namespace Tny.Ui { public interface IMsgView { TnyMsg Msg { get; set; } void clear (); } } It has a default implementation called TnyGtkMsgView: http://tinymail.org/API/libtinymail-1.0/TnyGtkMsgView.html http://svn.tinymail.org/svn/tinymail/trunk/libtinymailui-gtk/tny-gtk-msg-view.c http://svn.tinymail.org/svn/tinymail/trunk/libtinymailui-gtk/tny-gtk-msg-view.h Expected is that the generator would generate an implementation of a proxy for .NET that looks like this: namespace Tny.Gtk { public class MsgView : Tny.Ui.IMsgView { protected IntPtr real; public MsgView (IntPtr real) { this.real = real; } [DllImport("libtinymailui-gtk-1.0.dll")] static extern IntPtr tny_gtk_msg_view_new (); public MsgView () { this.real = tny_gtk_msg_view_new (); } [DllImport("libtinymailui-1.0.dll")] static extern IntPtr tny_msg_view_get_msg (IntPtr real); private Tny.Msg get_msg () { IntPtr local_real = tny_msg_view_get_msg (this.real); Tny.Msg s = new Tny.Msg (local_real) return s; } [DllImport("libtinymailui-1.0.dll")] static extern void tny_msg_view_get_msg (IntPtr real, IntPtr s); private void set_msg (Tny.Msg s) { tny_msg_view_set_msg (this.real, s.real); } public Tny.Msg Msg { get { return this.get_msg (); } set { this.set_msg (value); } } [DllImport("libtinymailui-1.0.dll")] static extern void tny_msg_view_clear (IntPtr real); public void clear () { tny_msg_view_clear (this.real); } } } Note that the constructor uses an API from libtinymailui-gtk but that the get_msg and set_msg API comes from the GType interface TnyMsgView and therefore is taken from libtinymailui, not from libtinymailui-gtk. The proxy code generator should cope with that. My questions for the Gtk-Sharp mailing list: Can the GAPI generator cope with the stuff that I'm doing and expecting? Or isn't it smart about interfaces (and basically simply creates a one-on-one binding for a GObject, not for an implementation of a GTypeInterface)? My questions for the people who are interested in going for this language bindings: do you have other questions and/or is everything clear about what I made as an example here? I mainly get questions about autotools from you guys. But autotools is actually the most easy part of the story you guys are getting yourself into. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be blog: http://pvanhoof.be/blog _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
