Re: [Evolution-hackers] Ditching ETable

[Hans Petter Jansson <hpj ximian com>]

On Tue, 2004-09-14 at 10:27 +0800, Not Zed wrote:
> On Mon, 2004-09-13 at 14:17 -0500, Hans Petter Jansson wrote: 

> > 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.

Yeah, we will have to write our own model. The built-in models are
clearly made for simple stuff, while the mailer's requirements are more
complex.

I don't think it'll be a lot harder vs. the ETable implementation,
though. Some boilerplate, ok. But apart from that, the "supplying all
items all the time" requirement is the only complication I can think of
(though it's admittedly a big one), without being intimate with the
mailer code.


> 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).

Having to supply all items all the time is a pain, I agree. I'm not sure
what you mean by sorting messing up updates - we could conceivably wrap
our models in the GtkTreeModelSort adapter model, which would do sorting
for us, at the expense of memory overhead. (Of course, doing our own
sorting would be better performance-wise).

-- 
Hans Petter