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

[Matjaž Mihelič]

First I have to apologize to Christian for getting this message twice. I
forgot to add message list to CC. End differs a little.

On Fri, 2009-07-24 at 19:57 +0200, Christian Hoff wrote:
> Looking at the release notes, Gtk# DataBindings seems to support binding 
> DataTables and DataViews.
> 
> I have implemented a custom tree model for ILists which will probably be 
> committed to Gtk# soon. It also supports generating columns for lists 
> implementing the ITypedList interface (for example DataView). For 
> example, it allows you to bind Array, ArrayList and DataView objects. I 
> will also backport this to the 2.12 branch.
> 

DataBinding is way more than custom treemodels. For example, I wrote
QueryModel interfaces (datatable/view, hierarchical IList, Array, Enum
and shell model classes with custom registration factory) in one day.
Living and breathing databindings I'm still writing after 2 years.

> The patch adds a "DataSource" property to Gtk.TreeView and all other 
> tree-model based widgets.  I'm wondering if you are subclassing from 
> Gtk.TreeView and use the same property name  as well? In that case, we 
> should try to avoid a name clash.
> 

Yes, I am, my bindings are 2 years old and already used in at least 10
commercial applications. It would be better if you do that in subclassed
TreeView, mostly because I'm not the only one using DataSource property.
As far as I know others that made similar solutions also used same
DataSource name.

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.

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.

Correct approach from your side would be wither providing something like
BaseTreeView for people who want different functionality or subclassing
original TreeView. But please... don't make another move like
EmitRowsReordered, because this move with TreeView would not be as
simple to solve as previous, but rather brutal.

Besides that. Don't make my mistake. Don't bind DataView in gtk-sharp.
DataView/DataTable are not cleared by MS community promise. If you'd
read my notes, you'd see I have to separate if I want to provide real
FOSS solution. If you do that then it can't be shipped with Fedora and
other foss specific distros.

> We don't plan to implement a full-fledged databinding API as the Gtk# 
> databindings provide, but we think that a tree model for ILists would be 
> useful addition to Gtk#.
> 

Well, I doubt you will even scratch the surface of what my databindings
provide. If you're interested I would gladly explain why and what. And
the fact they provide common functionality over all widgets not just
treeview.

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.

matjaz

> Christian
> 
> Matjaž Mihelič wrote:
> > Release notes: http://gtk-databind.sourceforge.net/v2release.html
> > FAQ: http://gtk-databind.sourceforge.net/v2FAQ.html
> >   
>