[Gtk-sharp-list] TreeModel for ILists

Christian Hoff christian_hoff at gmx.net
Mon Aug 10 10:13:38 EDT 2009

Matjaž Mihelič wrote:
> Update from my side. I got sidetracked for 6 days with my work and
> vacation. Now, working again on interface and I expect it finished in
> day or two
> On Mon, 2009-08-10 at 09:33 +0200, Christian Hoff wrote:
>> But I still think we should include IList support in Gtk# directly as 
>> there are many users who may only want to show a DataView, but do not 
>> want to depend on a full databinding project that is not packaged by 
>> many Linux distributions.
> yes it is nice addition, as long as we keep it as extension method in
> something like Gtk.Extensions. This way it is easy to include and
> excluded by default
I agree, we have to keep that stuff out of Gtk#. It was a bad idea to 
implement IList support in the gtk-sharp assembly. Data binding and the 
bindings for Gtk+ should be seperated cleanly.
> and use it like
> myTreeView.SetItems (myListOrDatabase);
Good idea :-) . The extension methods approach is still not optimal (we 
cannot add a constructor to the TreeModel-based widgets), but it is 
whole lot cleaner.

I wonder if that can be done without compiling the assembly against .net 
3.5. Apparently it seems to be possible to compile extension methods 
with the .net 2.0 profile, but any application wanting to use them will 
have to target 3.5, if I'm correct (though it would still be possible to 
call them as static methods).
>> The second problem is there are existing databinding projects around. It 
>> will confuse a user of Gtk# DataBindings to see that TreeView has a 
>> "List" and a "DataSource" property. This is a collision that we would 
>> like to avoid.
> this is why extension methods should be used for that.
> for example:
> my extension methods for databindings with original gtk widgets reside
> in (v2 not yet in svn)
> Gtk.DataBindings.Compatibility
> which makes it possible for developer to use original widgets without
> extensions even if he references to my assembly
I agree. Let's keep all data binding stuff outside of the gtk-sharp 
>> Matjaẑ is currently working on a minimal, generic code base for data 
>> binding support in Gtk# using extension methods. I'm excited about the 
>> results. Maybe the best choice would just be to wait until it is ready 
>> and see if we can possibly add it together with the IList stuff.
> I for one love that very much and would love if some light databinding
> would be deployed with gtk-sharp. as long as it is extension and part of
> another assembly (if it would be in gtk#... then databinding interface
> would have no meaning).
Yes, data binding functionality has been neglected for quite some time. 
It is a part of a every good UI toolkit. I'm confident that we can add 
at least some basic stuff in its seperate assembly.


More information about the Gtk-sharp-list mailing list