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

[Matjaž Mihelič]

On Sat, 2009-07-25 at 10:25 +0200, Christian Hoff wrote:
> 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.
> 

I'm never offended. But I did/do hate how easy it is for some people to
forget other peoples work.

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

all right here... just as you say YOUR TreeView wouldn't be cluttered,
MINE and all other derivatives providing real databinding would.

hell, that must be one nice world where you live. you seem to notice
only your self and what you wanna see.

> new TreeView (new TreeModelAdapter (new IListStore (my_list))); uggh.

and your solution is still not even nearly as nice as subcassing
TreeView to provide your functionality.

and... sorry for this... but wtf? there is at least zillion better
solutions where this is not needed, but at the same time you don't need
to scr** over other people.

I can walk you trough all of them if you'd like.

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

IList won't work, believe me. I tried that for pre-v1. There are real
deficiencies in that approach. For example IList only exposes
Items[int], while TreeView exposes hierarchy and so on. Believe me, at
best it is handicapped solution which will be imposed on all TreeView
users.

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

yeah, so one will be able to do:

myTreeView.Model = ...
myTreeView.IList = ...
and then for databinding
myTreeView.ItemsDataSource =

3 ways for same solution? and 2 SHOULDN'T be touched? Isn't that
awesome?

not even nearly nice. I already have problem explaining why users
shouldn't be touching model. foss world is already suffering "lack of
documentation" and by providing another confusion you just make my life
even harder than it already is.

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

There already is ListView. Maybe you'd rather impose IList there. And
ListView is made for linear lists

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

So what stops you to subclass TreeView? You seriously screw sanity for
developer B (or even more for developer who is providing solution for
developer B) as you impose 3 ways to do the same and lol, 2 are wrong
and should not be touched (how nice is that?). So... you only care about
A and C because they are in your range?

If you'd actually read my mail, you'd see I have nothing against
implementation. I'm only saying that enabling 3rd way to do the same
(and guess what, the one actually doing 3rd way is me and others who
work on similar solutions not you) is not sane. That would practically
force me to keep my own treeview implementation in my library if I want
to have sane api. I don't wanna work on pop quiz where 2 doors are wrong
and 1 is right.

[sarcasm] Thanks for that:( I'd probably rather choose another toolkit
and stop working on gtk part. simply because last thing I'd like to see
is seeing me starting to maintain my own gtk-sharp because you decided
to impose something like this on other widgets too which made all my
work confusing.

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

Then make LISTView which is used for lists, not TREEView which is used
for hierarchy.

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

like 99% of foss? foss is suffering from documentation deficiency and
documentation practically doesn't exists.

lets look one example right from gtk-sharp. You (or someone else at
gtk-sharp) implemented GInterfaces and provided CellEditableAdapter and
CellEditableImplementor, if what you say would even mean something I
wouldn't need to search net for days to find example, just to realize
there isn't one and more... there is not one single line of
documentation. 

based that those two classes aren't documented, they don't exist? and
you can simply change them as you like?

I'm in the middle of writing examples for mono wiki how to use those
classes, since I wouldn't like to see one poor soul to go trough what I
had to go.

matjaz

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