[Gtk-sharp-list] Recent changes to the API

[Mike Kestner]

A couple of API changes have landed in the last two days that I thought
warranted some announcement.  

The first is that I have removed all the "stubbed" protected ctor ()
declarations.  If there is a "no param" ctor in the API now, it actually
instantiates an object.  Chaining is now predominately accomplished
through protected ctor (IntPtr).  If you are setting Raw in your
subclass's ctor, you will want to chain with base (IntPtr.Zero) from now
on.  This change was made primarily to avoid leaked objects when
subclassing a ctor () that set Raw right before you clobbered it with a
new object in your own ctor.

So if you are getting errors for subclass ctors that say there is no
parameterless ctor in the parent, you probably want to chain to base
(IntPtr.Zero).

The second change is that GLib.Value is now a struct type, to take
advantage of the faster/less memory intensiveness of value types.  This
will most likely creep into your world if you are customizing GObject
property declarations in a native wrapper.  The new generated code
paradigm is this:

public bool AllowGrow {
  get { 
    GLib.Value val = GetProperty ("allow_grow");
    bool ret = (bool) val;
    val.Dispose ();
    return ret;
  }
  set {
    GLib.Value val = new GLib.Value(value);
    SetProperty("allow_grow", val);
    val.Dispose ();
  }
}

val.Dispose calls g_value_unset on the value.

The GLib.Value patch was a rework of the patch submitted by Ben a month
or two ago.  I'm also currently reworking the concept he proposed in his
GType boilerplate elimination patch into a more robust version. 
Hopefully that will land in the next day or so.

The interesting feature of this next patch is that it will be adding
code to the generated ctors to detect subclassing scenarios and either
handle them silently if possible, registering necessary GTypes on the
fly, or throw an exception if the generated ctor can't perform the
chaining.  This exception scenario will happen when ctor parameters
can't be mapped to construct properties for a g_object_newv call.  There
will also be a mechanism added to specify this mapping via metadata so
that we can implement valid ctors everywhere.

Sorry for the breakage these changes will produce, but I believe it's an
important step forward for the overall speed, reliability, and
"subclass-friendliness" of the binding.

Regards,
-- 
Mike Kestner <mkestner@ximian.com>