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

Mike Kestner mkestner at novell.com
Mon Apr 24 15:28:29 EDT 2006

On Mon, 2006-04-24 at 20:49 +0200, Philip Van Hoof wrote:

> No but. Mike Kestner was not allowed to use a keyboard this weekend (ask
> him, and his wife), so he didn't yet take a look at it.

Wow, I didn't think that would get broadcast to the world.  ;-)

>  I don't know
> whether or not it's already ready for inclusion in a future Gtk-Sharp
> version.
> I think it needs some more features and improvements. But your work
> which made it work with combo boxes is a nice step into that direction,
> I guess.

I'll just weigh in here briefly about the expectations from the Gtk#
side.  Don't want anyone to think I'm ignoring the discussion.  We are
definitely interested in a databinding solution for Gtk#.

Some observations:

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 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...

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

Mike Kestner <mkestner at novell.com>

More information about the Gtk-sharp-list mailing list