Gtk#DataBindings v2.0 rc1 released

[Matjaž Mihelič]

Release notes: http://gtk-databind.sourceforge.net/v2release.html
FAQ: http://gtk-databind.sourceforge.net/v2FAQ.html

have a nice day
m.

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

[Christian Hoff]

Looking at the release notes, Gtk# DataBindings seems to support binding
DataTables and DataViews.

I have implemented a custom tree model for ILists which will probably be
committed to Gtk# soon. It also supports generating columns for lists
implementing the ITypedList interface (for example DataView). For
example, it allows you to bind Array, ArrayList and DataView objects. I
will also backport this to the 2.12 branch.

The patch adds a "DataSource" property to Gtk.TreeView and all other
tree-model based widgets.  I'm wondering if you are subclassing from
Gtk.TreeView and use the same property name  as well? In that case, we
should try to avoid a name clash.

We don't plan to implement a full-fledged databinding API as the Gtk#
databindings provide, but we think that a tree model for ILists would be
useful addition to Gtk#.

Christian

Matjaž Mihelič wrote:
> Release notes: http://gtk-databind.sourceforge.net/v2release.html
> FAQ: http://gtk-databind.sourceforge.net/v2FAQ.html
>  

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

[Matjaž Mihelič]

First I have to apologize to Christian for getting this message twice. I
forgot to add message list to CC. End differs a little.

On Fri, 2009-07-24 at 19:57 +0200, Christian Hoff wrote:
> Looking at the release notes, Gtk# DataBindings seems to support binding
> DataTables and DataViews.
>
> I have implemented a custom tree model for ILists which will probably be
> committed to Gtk# soon. It also supports generating columns for lists
> implementing the ITypedList interface (for example DataView). For
> example, it allows you to bind Array, ArrayList and DataView objects. I
> will also backport this to the 2.12 branch.
>

DataBinding is way more than custom treemodels. For example, I wrote
QueryModel interfaces (datatable/view, hierarchical IList, Array, Enum
and shell model classes with custom registration factory) in one day.
Living and breathing databindings I'm still writing after 2 years.

> The patch adds a "DataSource" property to Gtk.TreeView and all other
> tree-model based widgets.  I'm wondering if you are subclassing from
> Gtk.TreeView and use the same property name  as well? In that case, we
> should try to avoid a name clash.
>

Yes, I am, my bindings are 2 years old and already used in at least 10
commercial applications. It would be better if you do that in subclassed
TreeView, mostly because I'm not the only one using DataSource property.
As far as I know others that made similar solutions also used same
DataSource name.

Introducing non-gtk functionality in base gtk class is kinda strange and
I doubt it is really smart move. It kinda s**ews people who were
subclassing TreeView as it was.

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.

Correct approach from your side would be wither providing something like
BaseTreeView for people who want different functionality or subclassing
original TreeView. But please... don't make another move like
EmitRowsReordered, because this move with TreeView would not be as
simple to solve as previous, but rather brutal.

Besides that. Don't make my mistake. Don't bind DataView in gtk-sharp.
DataView/DataTable are not cleared by MS community promise. If you'd
read my notes, you'd see I have to separate if I want to provide real
FOSS solution. If you do that then it can't be shipped with Fedora and
other foss specific distros.

> We don't plan to implement a full-fledged databinding API as the Gtk#
> databindings provide, but we think that a tree model for ILists would be
> useful addition to Gtk#.
>

Well, I doubt you will even scratch the surface of what my databindings
provide. If you're interested I would gladly explain why and what. And
the fact they provide common functionality over all widgets not just
treeview.

And you're more than welcome to build out of my version instead of
providing just something. Mine already IS full-fledged databinding.
Providing live editing and everything. If you're interested I'll be more
than glad to walk you trough.

matjaz

> Christian
>
> Matjaž Mihelič wrote:
> > Release notes: http://gtk-databind.sourceforge.net/v2release.html
> > FAQ: http://gtk-databind.sourceforge.net/v2FAQ.html
> >  
>

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

[Mike Kestner-4]

On Fri, 2009-07-24 at 21:28 +0200, Matjaž Mihelič wrote:

> Introducing non-gtk functionality in base gtk class is kinda strange and
> I doubt it is really smart move. It kinda s**ews people who were
> subclassing TreeView as it was.

We have added .net extensions to numerous gtk classes where it makes the
binding friendlier to .net application developers.  IEnumerable
interfaces are one example.  

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.  

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.  

Maybe the best way to get an IList into TreeView is to simply implement
the interface on ListStore itself, though.  

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

int EmitRowsReordered (TreePath, TreeIter) was the old signature.  I'm
amazed that invoking that method produced any result that was actually
desirable, since the int return value was really a misinterpreted "out
int" parameter on the generated dllimport.  The signal expects that to
be an int[], as corrected by the patch.

Our general policy of API compatibility related to broken method
signatures has been to fix completely unusable signatures without adding
obsolete methods which only preserve compile-time stability.  Are you
saying the old method signature actually worked for you without being
able to pass the index array?  If so, we should add back obsolete
overloads as you suggest.

> And you're more than welcome to build out of my version instead of
> providing just something. Mine already IS full-fledged databinding.
> Providing live editing and everything. If you're interested I'll be more
> than glad to walk you trough.

If we were to ever integrate full-fledged databinding into gtk-sharp it
would likely be by integrating an external fully-cooked implementation
such as yours.  I'm certainly not interested in reinventing any
wheels.  

I've watched your release announcements and been happy that your project
was there for gtk-sharp users to build on.  I don't really see any
compelling reason for it to be directly in gtk-sharp when databinding is
accessible through an extension library such as yours.  Thanks for
providing this capability to the community.

--
Mike Kestner <mkestner@...>

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

[Matjaž Mihelič]

sorry mike, again I forgot to add list in CC and so you were cursed to
get this email twice. guess I really need to quit computer for today.
twice same mistake in one day... really sorry

On Fri, 2009-07-24 at 16:12 -0500, Mike Kestner wrote:
> On Fri, 2009-07-24 at 21:28 +0200, Matjaž Mihelič wrote:
>
> > Introducing non-gtk functionality in base gtk class is kinda strange
and
> > I doubt it is really smart move. It kinda s**ews people who were
> > subclassing TreeView as it was.
>
> We have added .net extensions to numerous gtk classes where it makes
the
> binding friendlier to .net application developers.  IEnumerable
> interfaces are one example.  
>

lol, IEnumerable and using property name like DataSource when coming
late to the show is something completely different. (more on this later)

> 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

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.

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

since gtk-sharp hasn't had databinding many people started working on
their own solutions (I know at least 5 of such libraries, people simply
had different goals than me or needed some functions before I wanted to
fixate on them). I think I was the first one to take on this and my
implementation probably has most features (250000 lines of code).

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

> Maybe the best way to get an IList into TreeView is to simply
implement

> the interface on ListStore itself, though.  
>
> > 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.
>
> int EmitRowsReordered (TreePath, TreeIter) was the old signature.  I'm
> amazed that invoking that method produced any result that was actually
> desirable, since the int return value was really a misinterpreted "out
> int" parameter on the generated dllimport.  The signal expects that to
> be an int[], as corrected by the patch.
>

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.

this wouldn't be any problem if this move could be planned. But I for
example noticed this breakage when I had to install my application on
new computer at my customer (I don't have windows machine, so imagine my
surprise when my application suddenly didn't work for the first time),
where I obviously installed newer gtk-sharp. Another such example was
auto update on computer, which caused software to suddenly stop running.

> Our general policy of API compatibility related to broken method
> signatures has been to fix completely unusable signatures without
adding
> obsolete methods which only preserve compile-time stability.  Are you
> saying the old method signature actually worked for you without being
> able to pass the index array?  If so, we should add back obsolete
> overloads as you suggest.
>

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");
}

and keep this method all trough release. Introducing api change in
2.12.XX is not really nice. would be much better if you'd keep them as
Obsolete for complete version stack as in 2.X and remove them in 2.X++

> > And you're more than welcome to build out of my version instead of
> > providing just something. Mine already IS full-fledged databinding.
> > Providing live editing and everything. If you're interested I'll be
more
> > than glad to walk you trough.
>
> If we were to ever integrate full-fledged databinding into gtk-sharp
it
> would likely be by integrating an external fully-cooked implementation
> such as yours.  I'm certainly not interested in reinventing any
> wheels.  
>

Yeah, and this is why I rather offered mine than implementation of semi
solution. btw. you wouldn't even need to integrate my implementation.
you could simply pack it beside gtk-sharp. dlls work seemlesly on
windows, linux and osx, even ms.net.

I was thinking about this long time ago if I should propose that and
finally decided it is better if gtk-sharp is cleaner and everything
advanced separated out. More advanced features you impose into base
structure harder it gets for people who need special uses.

> I've watched your release announcements and been happy that your
project
> was there for gtk-sharp users to build on.  I don't really see any
> compelling reason for it to be directly in gtk-sharp when databinding
is
> accessible through an extension library such as yours.  Thanks for
> providing this capability to the community.
>

I'm glad to hear that, thx
matjaz


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

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

[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

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