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

[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