[Gtk-sharp-list] TreeModel for ILists

[Matjaž Mihelič]

On Mon, 2009-08-10 at 16:13 +0200, Christian Hoff wrote:
> 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.
> 

Why would you need that? I never need that even for custom models... I
will show you that in example for interface;) custom model taken
directly out of entry assembly

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

Or specifying ExtensionAttribute;) One only problem here is that you
don't know which framework it compiles for. and specifying it in 2.0
while using that in 3.5 causes problems. Simplest solution is to provide
2.0 and 3.5 interface assemblies which only differ in attribute
definition. As soon as you reference 2.0 version from 2.0 extension
methods are visible

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

lol????? Neglected? I wonder what have I been doing for almost 3 years;)

matjaz
> 
> Christian