TreeModel for ILists

[Christian Hoff]

Hi folks,

as you probably have noticed, there already was a discussion about IList
support. I have written a custom TreeModel for my application which is
able to bind any IList (including DataView) and thought about adding it
to Gtk#.

In my opinion it would be a nice addition as there are lots of people
wanting to display a DataView in a widget - Matjaẑ (developer of Gtk#
Databindings) says there are lots of people asking him whether the next
version of his project was able to bind them :-) .

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.

The flaw with the current TreeModel-based approach is simply that it
provides no capabilities of editing the IList and that it is not really
user-friendly.
You just have a TreeModel which is read-only, have to take care of
adding the appropriate number of columns to your TreeView/ComboBox,
filling these columns with a CellRenderer, connect to their "edited"
events to make sure the changes are reflected in the Model/the IList. Uggh.

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. Maybe the best solution would be to have only one
("DataSet"?) property. When being set, it checks for TreeModels being
able to bind this type of data. We could use some kind of pluggable
mechanism to allow registration of other custom TreeModels.

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 would also be great for some feedback from the community, inparticular
whether you would appreciate support for ILists in Gtk#, how your
project displays DataViews, etc. Feel free to chime in :-) .

Christian
_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

[Matjaž Mihelič]

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:

> Hi folks,
>
> as you probably have noticed, there already was a discussion about IList
> support. I have written a custom TreeModel for my application which is
> able to bind any IList (including DataView) and thought about adding it
> to Gtk#.
>
> In my opinion it would be a nice addition as there are lots of people
> wanting to display a DataView in a widget - Matjaẑ (developer of Gtk#
> Databindings) says there are lots of people asking him whether the next
> version of his project was able to bind them :-) .
>
> 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

and use it like
myTreeView.SetItems (myListOrDatabase);

even if it resides in gtk#... although this defeats purpose for
interface as it can't use it. separated assembly in gtk# package with
extension api could do that. and that would really be nice.

> The flaw with the current TreeModel-based approach is simply that it
> provides no capabilities of editing the IList and that it is not really
> user-friendly.
> You just have a TreeModel which is read-only, have to take care of
> adding the appropriate number of columns to your TreeView/ComboBox,
> filling these columns with a CellRenderer, connect to their "edited"
> events to make sure the changes are reflected in the Model/the IList. Uggh.
>

Actually, this is not a bug in my opinion. It is just one helluva
framework to build with it. But it does pose strains on end developer,
that I agree, but for developer like me... there is no better approach.

In case of editing. data binding must also provide api for it.

I'm preparing CompositeView for v2.0. Which is really easy and provides
backward compatibility with my ColumnMappings. It enables nicer and
more .Net conforming approach. Although, people spitting regexx
expresions in their sleep are probably more fond of old one as it is
much faster to create. Biggest problem is lack of editors. Again solving
this for v2

But removing it in any way, would be a serious blow for anyone wanting
to do more. *** there never was talk about removal, this is just my 2
cents on this topic;)

> 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. Maybe the best solution would be to have only one
> ("DataSet"?) property. When being set, it checks for TreeModels being
> able to bind this type of data. We could use some kind of pluggable
> mechanism to allow registration of other custom TreeModels.
>

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

That part was not originally in v2 plan as I didn't know how to do it.
Until me and Christian had our little pissing contests;) which really
bare fruits. We found a way to make external interface which controls
standard widgets without one single line in gtk#. So... that part of v2
needs thanks to Christian... bad thing? v2 got a little sidetracked and
postponed.

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

basically, intention is to write interface (separate assembly) which
provides enough information for any bindings to work and for developer
to be able to control complete process and support enough for data
binding engine to register extensive factory interface

myWidget.DataBinding().Freeze(); // freeze/thaw/start/stop/disconnect

custom commands like
myWidget.Bind (...)
are part of each data binding library, except that by connecting trough
interface it also respects uniform control.

nothing else. but as long as data binding will support this logic,
developer can have uniform control even if he uses different data
bindings for each widget on the form.

best example is probably this... someone decides he would like to bind
data with gst. and makes his data binding library which binds widgets
with gstreamer sinks and everything. now other than movie widget will
probably not use gst data binding but rather conventional... which
already leads to having two engines on the same form.

unique way for controlling tham all? >>>WIN
all widgets respecting signals the same way? >>>WIN

> I would also be great for some feedback from the community, inparticular
> whether you would appreciate support for ILists in Gtk#, how your
> project displays DataViews, etc. Feel free to chime in :-) .
>

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

> Christian

Matjaž

_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

[Christian Hoff]

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


Christian
_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

[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

_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

[Adam Tauno Williams]

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:
> > > 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);

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.

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

> > > 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/> ?

_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

[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.
_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list