Mike,

We have some problems. Some methods are going to return a gtk widget which
will need to be wrapped again into a c# class. This will have a nasty
reaction when callbacks are added to the wrapper, then the wrapper is nuked
when complete. It will leave a rogue pointer of some kind laying around, and
callbacks won't work as expected.

Proposed solution:
Every GTK# class is a wrapper class. With a constructor for a GtkWidget* and
one for a default _new. Events are done as in CVS, except that the events
object will need to be bound to the GtkWidget owning it, and when a wrapper
is created, that Events object is resurected. This way, even if there is no
wrapper in existance, signals will function properly, and multiple wrappers
will work properly too. The event object will register a delete signal with
the widget so that when its nuked, it has a chance to free itself. Are we
going to have to tell the garbage collector to stay away from this class?
We might need our own class for this, and this class might not be able to be
written in c#.


Problem number two is with taking an arbitrary GtkWidget, and constructing a
wrapper as needed. Which wrapper is created? A simple GtkWidget wouldnt work
too well if the GtkWidget is really a button. We need to deside how to
handle this. Should we just return a GtkWidget, and force the developer to
pass the GtkWidget back to a constructor for the desided apon Widget wrapper?
How does gtk itself deal with this? Are we going to need a database of
widget wrappers for this?

Posible solution:
How does (ToType)GtkWidget work in c#. If the type you want to cast from is
not of the right type, but the ToType contains a constructor for GtkWidget,
will the cast succeed? If so, this will work quite nicely. Everything is a
GtkWidget object, and cast bindings as needed. If this does not work, can
the cast operator be overridden some how? If so, good deal. If not again,
see if System.Reflection has anything that will help in conjunction with the
GTK Type system.

Bob