[Gtk-sharp-list] LibGlade

[Paolo Molaro]

On 08/16/02 Mike Kestner wrote:
> If you look at glib/SList.cs, it is currently a subclass of ArrayList,
> although it will most likely just be an implementor of IList in the end.
> Taking this approach allows us to put all the marshaling logic inside
> the type itself instead of having to generate a lot of ugly code all
> through the binding to accomplish the marshaling from an ArrayList. As
> long as the type exposes the IList interface, I don't see what your
> issue is.  It can be used just like an ArrayList. It's a hand wrapped

My issue is with:
	public class SList 
	[...]
	public SList (IntPtr raw)

If the type is made internal and exposed only as an IList reference
I would have no problems.

> > The same goes for other internal details of the Gtk+ C API, like, the
> > use of IntPtr.Zero should be never required to write a Gtk# program, it
> > just doesn't belong to a C# interface. Also, eliminating it will give
> > us some chance of using Gtk# in untrusted code.
> 
> This is mostly a non issue already.  Null handling has been added that
> maps null parameters to IntPtr.Zero for marshaling.  As new parameters
> are discovered, we are marking them null-ok in the XML.

That is only one of the issues. Look at this:

	public Object (IntPtr raw) (in glib/Object.cs)

What happens if I pass an arbitrary value in there?
I'm just raising the issue: do we want to be able to make untrusted code
that uses Gtk safely? I think it's a worthwhile target.
I don't have a solution, I didn't look at the binding design, but I
think we should take it into account (and the above entry point makes
it impossible to run safely untrusted code that uses Gtk#).

> > Well, I have also a third: C# won't be the only language to use the
> > binding to Gtk. I would be nice to have the binding be a thin wrapper of
> > the C API and have Gtk# on top of that to provide the C#-way of doing
> > things, while other languages will be able to reuse the binding to
> > implement the interface to their language as best as it suits _that_
> > language.
> 
> I don't know if this is a signal handling troll, or what exactly your
> point here is.  :)  There is nothing C# specific that we are doing.  We
> are generating a set of IL classes that correspond to the paradigms set
> forth in the BCL.  It is up to the language implementor to interact with
> these classes in a manner stylistically correct for that language.

Exactly. The binding is made to match the BCL rules (i.e. the C#
paradigms), instead of following the Gtk API and exposing a
BCL-conforming interface based on that.

From a purely hypothetical point of view: I'm porting jpython to run on
the mono CLR and I want to be able to run existing python gtk programs.
Of course it would be very silly to write a new binding to libgtk that
follows the (established) python way of doing the binding (usually a
thin wrapper on the C API).
With the current gtk# binding, the call chain for the python code:

	win.show_all ()

will look like:

	win.show_all ()
	-> win.ShowAll ();
	   -> gtk_widget_show_all (IntPtr raw);

Now, there are three issues with that:
1) an extra method call (minor, I know, but why impose it?)
2) mapping name issue: the python binding needs to map its
method names based on the C API to the almost arbitrary BCL-compatible
name (when it would be enough to just s/gtk_widget_//)
3) it would not be enough to make gtk_widget_show_all() public, because
of the IntPtr type that is exposed (again, I think exposing methods that
take IntPtr is dangerous and I would limit it also in the internals of
the binding).

So, my suggestion is to have the binding expose a thin wrapper over the
C API and have the C# side of it provide the BCL-conforming method
names, permitting other languages to reuse their existing mapping of the
Gtk+ API without adding an extra layer that maps to the BCL-accepted names
(the imposed layer is a slight overhead at runtime, but a big wall to climb to
have an existing binding work within the CLR).

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better