[Gtk-sharp-list] LibGlade

[Mike Kestner]

On Mon, 2002-08-19 at 09:51, Paolo Molaro wrote:

> 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.

The reality is that we are going to have to look at each instance of
S?List in the API and determine whether we can treat it as an opaque
type or whether we have to create a custom IList implementor to marshal
its elements. Don't get your undies in a bunch over SList.cs. It was a 2
minute hack to get around a build problem early on.

> 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.

Dude, please.  Would all the folks who have actually used Gtk# and feel
it was a huge pain to adapt to the paradigm shift please step forward?

> 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?

Widget*?  The GObject pointers are only used to invoke native methods. 
The native methods have all manner of cast/type checking built in. It's
not like Gtk# is using the handles to indescriminately "scribble" across
the heap. If we want to be completely anal-retentive, we can always add
a little glue check to call G_IS_OBJECT in the base GLib.Object(IntPtr)
ctor.  

> I think gtk# should provide a trustable interface: if the gtk# team
> disagrees, fine, but I think it's a mistake.

Impressively melodramatic.
-- 
Mike Kestner <mkestner@speakeasy.net>