[Gtk-sharp-list] LibGlade

[Paolo Molaro]

On 08/17/02 Rachel Hestilow wrote:
> > 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#).
> 
> Internal types cannot be used cross-assembly, right? Currently, we have
> a gdk-sharp, a gtk-sharp, a gnome-sharp, etc. Would you have us combine
> all these into a single assembly? That doesn't seem appealing to me.

Handling GSList/GList is 20 lines of code: I would duplicate them in
each assembly and use plain arrays or arraylists in the interface.
Still, the main problem is outlined above: do we want gtk# programs
that can scribble all over the CLR memory or not? Has this been
considered in the design? I think it's an important feature that is
worth achieving.

> > 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).
> > 
> 
> 1) Why should the users of languages that follow the .NET naming
> conventions be penalized for languages that don't? There are many naming
> conventions out there. It is a language's responsiblity to map its
> conventions to .NET conventions, and that includes naming conventions.

There is no additional overhead for the BCL convention in my proposal
(well, at most a -inlinable- function call to get a trustable API).
Plus, you should also consider the overhead for the developers
that know the C, python, perl API and have read the books and the
tutorials on the familiar gtk API and that now have to learn a different
API: developer mental cost is way higher than runtime cost.

> 3) Again, as the bindings near completion, the places in the public API
> where IntPtr is exposed for non-binding usage will approach zero.

If there is _one_ entry point that the user can call that takes a IntPtr
and passes it on blindly to be used as a GList* or GtkWidget* or
something like that, that's enough to make all the CLR security go down
the toilet. Is the plan for gtk# to allow that? 
I think gtk# should provide a trustable interface: if the gtk# team
disagrees, fine, but I think it's a mistake.

lupus

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