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 > > > _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
