Re: [Evolution-hackers] Ditching ETable

[Not Zed <notzed ximian com>]

On Mon, 2004-09-13 at 14:17 -0500, Hans Petter Jansson wrote:
> On Mon, 2004-09-13 at 13:45 -0400, JP Rosevear wrote:
> > What would people think if we replaced the remaining etable usages (mail
> > and task/calendar lists) with GtkTreeView?  The advantages are:
> > 
> > 1) One less big piece of complicated code to maintain
> > 
> > 2) Bi-directional text will just work
> > 
> > 3) A11y work will be easier
> > 
> > The disadvantages are:
> > 
> > 1) Potential performance hit (really only matters for mail, unlikely to
> > have 10000 tasks or events in a month), NotZed said that performance
> > wasn't bad in his eplugin test (improved from earlier gtk's anyhow) and
> > spending 1-2 man months on the performance issues is less work than
> > doing various bits of etable maintenance work in all likeliehood.
>
> FWIW (the component I maintain doesn't use ETable a lot) I think moving
> to GtkTreeView is the only way forward. We'll be using one table API,
> and it'll be the platform table API. If it sucks, we help fix it. And it
> isn't fundamentally broken IMO, so whatever problems exist should be
> fixable.
I'm not convined it isn't fundamentally broken myself.  At least the supplied models.  The mailer would need its own model for each folder, and probably an incremental threading algorithm, which is a bit of a pain to write.

The 'built in' model api's are fine enough for write-once tables, or simple tables, but once you start having to keep track of rows from other data handles, things get nasty.  You can't keep around gtktreerowreference's for example, for more than a hand-full of items.  So you have to do manual searching or other nasty crap which doesn't scale.  And/or write your own model which is a lot of work since none of the interfaces are re-usable.

It still suffers from the problem of having to supply all items all the time, and sorting messing up updates (i.e. if you delete parent rows, the subtree gets moved).

But having said all that, I don't see any practical alternative either!