Tinymail's .NET bindings

[Philip Van Hoof <spam pvanhoof be>]

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