[Gtk-sharp-list] TreeModel for ILists

[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ž