[Evolution-hackers] Re: Why GtkTreeView sucks.

[Federico Mena Quintero <federico ximian com>]

On Fri, 2004-10-29 at 11:11 +0800, Not Zed wrote:

> I just read your "blog" - you're wrong about how ETree works, or
> mistaken about what evolution mail uses (some things have changed
> since you last looked at it).  It only uses an ETreeModel, even for
> the flat view.  I'm not responding on the "blog" since I don't think
> that is very appropriate, or very polite.  I don't really want to get
> into an argument either, but I guess I have no choice.

Sorry if it sounded like I was trying to raise an argument; I wasn't :)

I didn't mean to say that GtkTreeView doesn't have performance problems;
it certainly has them, and it blows big fat goats that we can't fix some
of them due to API/ABI compatibility requirements.

> ETreeSelectionModel subclasses ESelectionModel directly, it doesn't go
> anywhere near ESelectionModelArray.  When you ask for the selected
> rows, you get the result of a g_hash_table_foreach.  So first point,
> GtkTreeView's selection retrieval interface is O(N) on the number of
> rows, and ETree's is O(N) on the number of rows selected.  Obviously
> in almost any real application you're looking up the selected row(s)
> constantly, so its something which should be fast in the common case
> (i.e. 1 row selected).

You are right, of course.  I was looking at ETableSelectionModel, not
ETreeSelectionModel.

I quite like the idea of using a hash table for tree selections... maybe
GtkTreeSelection could be made better with one.  All the red/black tree
stuff is private, anyway, so we could make it no longer keep the
selection data there.

> Second, and this is also a factor that helps the selection model work
> at all, ETree doesn't use this GtkTreePath indirect
> reference-to-a-pointer crap (and it is crap).  The ETreePath's are
> pointers to the actual tree nodes used in the tree.  And dereferencing
> an ETreePath is O(1) (where 1 is close to 0), whereas it's O(N) for a
> GtkTreePath - depending on the tree implementation, and for most
> practical tree implementations it is O(N).  This means you don't need
> this GtkTreeReference stuff, since all Paths are already 'static'
> references.  Some of the performance issues from using GtkTreePath's
> for most uses (not the selection stuff) can be mitigated by vastly
> complicating your tree model, but that seems an expensive cost for
> something which doesn't add any value to start with anyway.

Yeah, I'm not sure that GtkTreePath and GtkTreeRowReference are a good
idea for the abstract models.  They may be useful for GtkTreeStore if
you want to make it totally anal-retentive model/view.

But in the abstract model, I agree that opaque paths are better.
GtkTreeView uses row references for the cursor row, for example, so that
if you insert/delete rows above it then it will still be easy to find.
But I guess the tree could just as well keep track of that by itself.

We should definitely talk about designing a Better(tm) tree/list widget.
Mono needs one :)

  Federico