Re: [Evolution-hackers] ETree and gal

[Not Zed <notzed ximian com>]

On Wed, 2005-05-11 at 07:50 +0200, DINH Viêt Hoà wrote:
> Not Zed wrote :
>
> > > > >   I have some fixes for the example of ETree.
> > > > > And I am planning to use ETree in my own application (because 
> > > > > GtkTreeView/GtkTreeModel) have huge performance problem.
> > > > > I am also planning to add some API (either by not modifying libgal or by 
> > > > > modifying libgal). I would like to know if development of libgal is 
> > > > > opened to changes ?
> > > > 
> > > > We are about to kill development of gal outside of Evolution because no
> > > > one else is currently using it.
> > > 
> > > I was about to use that in my (open source) application.
> > > Should I duplicate the code of GAL into my code ?
> > 
> > Ugh.  I'd highly recommend against it.  You're entering a world of
> > pain ...
> > 
> > We want to try to kill etree as soon as we can; i'm almost inclined to
> > just drop in gtktreeview ASAP, and then hope that this just forces the
> > gtk+ maintainers to fix the performance issues.
> > 
> > Apart from multiline select scaling miserably, if you use a custom
> > model, and not the weird supplied models the performance isn't that much
> > worse than etable.
>
> GtkTreeView/GtkTreeModel design is broken since GtkTreePath is based on 
> indexes of elements in the table. That means that for each element, you 
> have to maintain its index: When you want to add or remove an element, 
> you have to update all the indexes of the elements of the sibling nodes. 
> Imagine you have a big amount of sibling nodes, performances are very 
> bad. The behavior is more correct with ETree.
> Since this broken design of GtkTreePath is related to the API, I have a 
> doubt about GTK developers will change this.

Well, this is also my conclusion - it is broken by design.  I ranted and raved about it but just got ignored as usual.

However, it doesn't update all the indexes all the time - only if you keep track of a path specifically using a treerowreference, which updates itself based on signals.  Which is pretty crap, but is ok for tracking the cursor - and not much else.

Otherwise indexes are just created on the fly when needed.

If you use a custom model, then you have direct access to the model nodes anyway - so it is only the tree view code which is forced to use the indexes, and in many cases it just iterates row by row, so the problem isn't that bad.

> I guess either I have to make my own treeview/treemodel based 
> on ETree ...
>
> > > GAL had the advantage of being LGPL and not GPL.
> > 
> > As opposed to?  Evolution?  I dont see the files changing license, but I
> > also don't see it being usable outside of the tree, if we can help it.
>
> I am currently using it outside of Evolution.
> I have to customize it a little but basically, it works.

I mean, outside of the evolution source tree once we move the used parts of gal into evolution, which is nearly done afaik.