Re: [Evolution-hackers] Re: Why GtkTreeView sucks.

[Not Zed <notzed ximian com>]

On Fri, 2004-10-29 at 20:43 -0500, Federico Mena Quintero wrote:
> 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 :)
Well even a discussion, it shouldn't need discussing :-/  Its a pretty fundamental widget.

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.
But there's no way to do this, unless you use gtktreerowreferences, which would just scale worse.  There is simply no api on the model that says 'give me a direct, low-cost pointer to this tree node, even if it moves'.

If the GtkTreeSelection was an abstract class somehow linked to the model or view then perhaps, or if it provided extra signals so you could just ignore it and 'proxy' the information yourself, then that could solve that issue too.

> 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.
Well when you dereference it its a lot of work too.  Unless you've got some sub-optimal-as-a-tree array or tree-on-tree based tree which makes your model more complex, error-prone, and slower for everything else.

When, yes, a simple pointer would work.
> We should definitely talk about designing a Better(tm) tree/list widget.
> Mono needs one :)
Unfortunately, Evolution needs one now.  We need features that we're either going to have to do in etable - and it wont be easy (least of all reasons being that nobody has ever worked on etable for more than 6-12 months before leaving the project entirely, so its a mess, and a mess nobody understands or thinks they deserve to have to - it feels like punishment for being committed to something long-term rather than benefiting from a short attention span mental disorder), or make GtkTreeView fast enough.  I can't see writing a new one as a practical alternative - although it's crossed my mind on more than one occasion.

The current message selected is only one problem - this could be optimised internally in gtktreeselection for example by just using gtktreerowreferences even for multi-select mode, if you only have a hand-full of rows selected.  But, if you do something like ctrl-a, ctrl-t, it selects everything - easy, it then throws the model away and builds a new one for a threaded/non-threaded switch, then it needs to re-select what you had selected before (which might not necessarily be everything).  That will really blow with gtktreeview too (it blew in etree until we added api for bulk programatic selections).  And apart from all these issues with the gtkselection thing, I don't know what other ones will crop up.

--

Michael Zucchi <notzed ximian com> "born to die, live to work, it's all downhill from here" Novell's Evolution and Free Software Developer