[Gtk-sharp-list] TreeModel for ILists
christian_hoff at gmx.net
Tue Aug 11 03:48:11 EDT 2009
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:
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,
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/> ?
More information about the Gtk-sharp-list