[Gtk-sharp-list] TreeModel for ILists

[Christian Hoff]

Adam Tauno Williams wrote:
> On Mon, 2009-08-10 at 16:25 +0200, Matjaž Mihelič wrote:
>   
>> On Mon, 2009-08-10 at 16:13 +0200, Christian Hoff wrote:
>>     
>>> Matjaž Mihelič wrote:
>>>> 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);
>>>>         
>
> I personally like how the ListView in Hyena solves this solution [see
> the thread at <http://www.nabble.com/Re%
> 3A-Sorting-and-Filtering-NodeStore-p20548458ef1367.html>]  IMO, Banshee
> has created some great, and under appreciated, Gtk# code.
>   
You can probably punt all that code when we have IList support in Gtk# 
:-) . Just pass your List<Item> to myTreeView.SetItems and use a few 
CellDataFuncs for the columns.

I see that you have implemented your own IListModel interface and are 
using a custom ListView<> widget to display it. Very interesting is the 
way you generate the columns from properties of the Item class:

ColumnController.AddRange (
        new Column (String.Empty, new ColumnCellCheckBox ("F", true), 1),
        new Column ("Apples", new ColumnCellText ("B", true), 1),
        new Column ("Pears", new ColumnCellText ("C", true), 1),
        new SortableColumn("How Hot", new ColumnCellRating("G", true), 
1, "G", true),
        new Column ("Peaches", new ColumnCellText ("D", true), 1),
        new SortableColumn ("GUID", new ColumnCellText ("A", true), 1, 
"A", true)
       );


Where "A", "B", "C", "D", "E", "F" and "G" are properties of the managed 
type that is displayed in the list. That way you can get rid of some 
ugly CellDataFuncs that get the property value via reflection. But I'm 
not sure if we should add a similar mechanism to Gtk# as it will slow 
the application down. Something like

(cell as CellRendererText).Text = item.A.ToString ();

in a CellDataFunc should be much faster.
>   
>>> 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).
>>>       
>
> Is targeting the current .NET rev really a problem?  Is anyone, in
> practice, actually sticking to older revs?  Especially in regards to
> shipping a new assembly with a new [?] API?
>   
My application still targets .net 2.0, for example. It's wide 
availability is also an asset and apart from extension methods support 
there was no reason to build against the 3.5 profile.

I don't think we would want to generate a 2.0 and 3.5 version of the 
databinding assembly as suggested by Matjaẑ. But since we are talking 
about a new assembly here it might be fine to make it 3.5-only.

I'm just worried about the Windows build where the user can only put one 
csc in the path, but we would need both a 2.0 and a 3.5 compiler :-( . 
It's definetly too early to take a 3.5 dependency for all of Gtk#.
Maybe we could write a solution for that assembly in the MSBuild format 
and specify that we want to target 3.5. Then the Windows user can put 
csc v2 in the path (for the Gtk# core) and building the databinding 
stuff via msbuild should invoke the 3.5 compiler.

Since a 2.0 extension methods assembly won't work with 3.5 (according to 
Matjaẑ), the other option I see is to implement the whole thing as 
static methods and wait until we can take a 3.5 dependency for Gtk# (if 
that time will ever come). But I don't think that would be a good choice.
>   
>>>> 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;)
>>     
>
> I assume we are talking about <http://gtk-databind.sourceforge.net/> ?
>   
Exactly.