[Gtk-sharp-list] Gtk#DataBindings v2.0 rc1 released

[Christian Hoff]

Hey Matjaz,

first I want to apologize for the tone of my initial e-mail. Sorry, I 
really didn't mean to offend you in any way.

Some comments below.

Matjaž Mihelič wrote:
>> Christian has been writing an IListStore for his project and has
>> approached me about possibly adding it to gtk-sharp.  One option I'm
>> considering is adding an IList property to TreeViews which would utilize an internal treemodel implementation such as christian's to easily add
>> data to a view.  
>>     
>
> yeah, I never said I'd mind that. I just think that TreeView which
> exposes 3 different ways to introduce list would be confusing 
> Model+gtk-sharpDataSource+assemblyDataSource
>   
I agree. However, the alternative would be to expose the IList model. We 
decided not to follow that approach since it would make the API less 
user-friendly. Instead of constructing a TreeView directly with the 
IList as argument, the user would have to create the model and an 
adapter for the model:

new TreeView (new TreeModelAdapter (new IListStore (my_list))); uggh.
> and lol, that would make my DataBindings (and others) really confusing.
> Current TreeView already has Model and all external databinding
> implementations are using at least DataSource property. I use
> (DataSource and ItemsDataSource) for widgets with lists. DataSource for
> storing results like for example data of the current selection and
> ItemsDataSource as source from which items are taken.
>   
Maybe we could work together and implement something like an "IList" 
property for IList and other tree-model-based widgets which can not only 
deal with ILists, but also with enums and all other types you support in 
Gtk# DataBindings. The method could be declared as "virtual" and you can 
provide your own implementation in your TreeView. It could be something 
like:

public override IList {
       get { [....] }
       set {
             base.IList = list;
             // Do your stuff here, add columns to the tree view, ...
       }
}

That way we the light-weight models could reside in Gtk#.
> Meaning gtk-sharp would hit their users just to introduce this semi
> capability. I doubt this is your wish. If you introduce DataSource into
> treeview this will be exact result. 
You're right that this approach is cannot replace a full-fledged 
databinding library. Nevertheless, I think a model for ILists would be a 
benefit for the community.
Maybe we can split devide the people needing IList support into 3 groups:

Developer A only wants to display IList data, such as an array, in a 
TreeView. He will be great if there's a need TreeModel ctor taking an 
IList. Maybe he needs to know which items have been selected, but not 
much more.

B wants to display a DataViewto the user and allow him to edit the data. 
He will probably use Gtk# DataBindings and the TreeView it provides. He 
will be happy that he does not need to write any additional code with 
everything (auto-generated columns, sorting) being implemented.

C would need the user to edit the data as well. But he wants to have 
more control over the view. That's why he decides not to use Gtk# 
databindings, but instead writes his own TreeView subclass perfectly 
uited to his needs.
> I for example don't even care if you
> introduce this as long as there is clean TreeView accessible for
> inheriting or inherited class is used for this. This way simple
> databinding and real databinding can coexist without single problem. You
> could do this in either way of these:
> - Make BaseTreeView (pure gtk TreeView) for people like me and then you
> can do with TreeView anything you like. As long as this is not
> introduced as backport (backport would break api)
>   
I don't think something like BaseTreeView would really be necessary. It 
is something I would like to avoid.
> - Leave TreeView as it is in gtk and provide some ModelTreeView (or
> whatever) and do databinding functionality there, this would pose no
> problem even in backport
>   
No, this "ModeltreeView" would have nearly the same functionality as 
TreeView. We do not intend to create a 2nd GridView/DataGrid, just a 
minimal solution that can be extended by
- the application developer (type A,C);
- Maybe Gtk# DataBindings (as suggested in the comment about the IList 
property above)

And BTW, we have decided against backporting that functionality to 2.12. 
It will most likely be released with Gtk# 3.

> - move databinding in some other assembly like everyone else (which
> would probably be best). Usually people tend to use the first solution
> they find and it would be shame that semi solution would eat other
> solutions just by having the advantage of being preinstalled. think of
> IE and windows.
>   
As Mike said, we don't intend to provide a data binding API in Gtk#. The 
only thing we consider is implementing IList functionality as that would 
help users who don't need a full data binding solution (type A) or who 
want to write their own stuff (type C).
>   
>> We could also choose to expose a public TreeModel implementation in
>> gtk-dotnet.dll or an external library such as Stephane's gtk-sharp-beans project, perhaps, if he'd be willing to accept it.
>>     
>
> Much better solution as many people are counting on gtk-sharp API
> stability. I know I am.
>   
The IList API is not buggy and its trivial as well. I don't think that 
we should put this into a 3rd party assembly as the current approach is 
lightweight, minimal and will help a lot of people.
>   
>> Maybe the best way to get an IList into TreeView is to simply implement the interface on ListStore itself, though.
>>     
I doubt this will be useful. The ListStore approach is much more limited 
as it won't work if the list is created by a method outside of your 
application. Besides, it would require me to rewrite the whole code for 
a feature that nobody will use.
>>> Same bad choice as it was when you corrected EmitRowsReordered api
>>> correction in 2.12.9 without providing empty method as Obsolete for
>>> compatibility reasons. That way compilation and execution suddenly
>>> became broken.
>
> lol, it only was usable with Zero, where it exposed ** list completely
> changed **. And all my applications broke because of that after update.
> even few users of my lib also complained about the same problem.
>   
I didn't think know that the old method would work in any case. The zero 
thing isn't documented anywhere.
>>
>>     
>
> It would be nicer if you'd provide something like 
>
> [Obsolete ("Wrong implementation")]
> oldResult NameOfTheBrokenMethod (... old parameters ...)
> {
>         Console.WriteLine ("Fix this for this and that reason");
> }
>   
We certainly would have done that if we knew that the old signature was 
usable in that case.

Christian