[Gtk-sharp-list] Databindig IList to a Gtk.TreeView

[Philip Van Hoof]

On Mon, 2006-04-24 at 14:28 -0500, Mike Kestner wrote:
> On Mon, 2006-04-24 at 20:49 +0200, Philip Van Hoof wrote:

> Everyone seems to jump right to the tree model when they think
> databinding.  I'm not sure this is the best approach, although I
> understand that TreeView/ComboBox are big draws.

> If I were to approach a databinding solution, I would start with
> something like a data bound checkbox and build the infrastructure it
> takes to hook that into a "DataSource" and "Field".  When you start
> thinking this way, it becomes clear that the hooks for this need to go
> deeper, at the Gtk.Widget level, probably.

Probably, indeed.

> While I'm not certain we want to follow the .Net mechanism exactly, I
> want the user interface aspects to parallel the way databinding is
> exposed in SWF.  If we can reuse System.ComponentModel features to make
> our lives easier, so much the better.  We should try to better
> understand how mono's System.Web and SWF databinding works before trying
> to implement a solution for Gtk#.

I agree. But it's not something I can at this moment spend my time on.
But I would like the idea of implementing the ComponentModel stuff in
Gtk#. I once started, I would very likely help out implementing bits and
bytes.

> I think it's good to pursue this is an external project for now as you
> are doing.  The majority of the code should probably be
> internal/non-public API with the exception of the
> DataSource/Field/etc... API.  With proper planning, it should be
> possible to develop as a standalone project to be merged into Gtk# when
> it matures.  Of course, since I'll have to maintain it going forward, it
> will need to meet the standards that typically apply: coding standards,
> readability, etc...

When the time is ripe, I propose doing it in a new namespace and in a
different assembly. Perhaps shouldn't it be called Gtk#: Because it
would introduce drastic changes to the way developers have to look at
Gtk+ development in .NET. Those changes wouldn't be (at all) compatible
with the API documentation of the C Gtk+ API anymore. Nor I think should
Gtk# be very different from the C/Object Gtk+ API.

Whether or not the C/Gobject Gtk+ API is "good" or "bad" isn't something
the 1-1 bindings should fix. However, an library/assembly that imple-
ments a bunch of adapters isn't an ugly solution in my humble opinion.

So .. in a new project/assembly/library/namespace and on-top-of.

> I'll follow your efforts as closely as I can and give feedback.  Please
> keep us posted.

Will do.

-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be