[Gtk-sharp-list] Gtk#DataBindings v2.0 rc1 released

[Mike Kestner]

On Fri, 2009-07-24 at 21:28 +0200, Matjaž Mihelič wrote:

> Introducing non-gtk functionality in base gtk class is kinda strange and
> I doubt it is really smart move. It kinda s**ews people who were
> subclassing TreeView as it was.

We have added .net extensions to numerous gtk classes where it makes the
binding friendlier to .net application developers.  IEnumerable
interfaces are one example.  

Christian has been writing an IListStore for his project and has
approached me about possibly adding it to gtk-sharp.  One option I'm
considering is adding an IList property to TreeViews which would utilize
an internal treemodel implementation such as christian's to easily add
data to a view.  

We could also choose to expose a public TreeModel implementation in
gtk-dotnet.dll or an external library such as Stephane's gtk-sharp-beans
project, perhaps, if he'd be willing to accept it.  

Maybe the best way to get an IList into TreeView is to simply implement
the interface on ListStore itself, though.  

> Same bad choice as it was when you corrected EmitRowsReordered api
> correction in 2.12.9 without providing empty method as Obsolete for
> compatibility reasons. That way compilation and execution suddenly
> became broken.

int EmitRowsReordered (TreePath, TreeIter) was the old signature.  I'm
amazed that invoking that method produced any result that was actually
desirable, since the int return value was really a misinterpreted "out
int" parameter on the generated dllimport.  The signal expects that to
be an int[], as corrected by the patch.

Our general policy of API compatibility related to broken method
signatures has been to fix completely unusable signatures without adding
obsolete methods which only preserve compile-time stability.  Are you
saying the old method signature actually worked for you without being
able to pass the index array?  If so, we should add back obsolete
overloads as you suggest.

> And you're more than welcome to build out of my version instead of
> providing just something. Mine already IS full-fledged databinding.
> Providing live editing and everything. If you're interested I'll be more
> than glad to walk you trough.

If we were to ever integrate full-fledged databinding into gtk-sharp it
would likely be by integrating an external fully-cooked implementation
such as yours.  I'm certainly not interested in reinventing any
wheels.  

I've watched your release announcements and been happy that your project
was there for gtk-sharp users to build on.  I don't really see any
compelling reason for it to be directly in gtk-sharp when databinding is
accessible through an extension library such as yours.  Thanks for
providing this capability to the community.

-- 
Mike Kestner <mkestner at gmail.com>