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.
