[Gtk-sharp-list] Databindig IList to a Gtk.TreeView
Philip Van Hoof
spam at pvanhoof.be
Mon Apr 24 15:49:46 EDT 2006
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.
> 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
> 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.
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
More information about the Gtk-sharp-list