Re: [Evolution-hackers] Ditching ETable



On Mon, 2004-09-13 at 14:17 -0500, Hans Petter Jansson wrote: and
> > spending 1-2 man months on the performance issues is less work than
> > doing various bits of etable maintenance work in all likeliehood.

I don't know that I'd underestimate the porting effort required, but
certainly once you're there, you've got a much lessened maintenance
burden.

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

I've been mucking around with GtkTreeView a bit of late. It strikes me
as being a touch on the complex side, but it certainly has a lot of
"just works" going for it if you play by its rules.

If you didn't know already, GtkTreeView (and GtkListView) both work on
top of a GtkTreeModel interface (typically GtkTreeStore or GtkListStore
- I wouldn't be surprised if you ended up creating your own Model,
although the existing one is probably ok). You then use a bunch of
GtkCellRenderers to take data from the model and render it in the view.
Lots of code.

<shrug>

If you've worked with this already, then it's old hat, but if you
haven't I actually heartily recommend the section on GtkTreeView in
Matthias Warkus's "Official Gnome 2 Developers Guide", pages 191-217.
It's a good overview of the breadth and complexity of the API. It's
pretty huge in there, so well worth a bit of reading.

--

In my case, since I already have a representation of the data, I'm
trying to decide whether to just load up the model (so it can power the
view) or whether to actually use the model as my [in memory] data store.
[Nothing says that all data items in the model have to be displayed].
While just passing through (constantly updating) the GtkModel from my
representation would be "easier" in that I would keep my present
mindset, if I just knuckled under and used their Model paradigm then I
wouldn't have to worry about synchronizing (one way sync, but still) and
then updates to the data will "just work" in the display. Means a degree
of lock-in I'm not yet ready to commit to.

R&D.

But I have decided to go with Gtk{Tree,List}View because of what Hans
mentioned - it is the platform's API, and so lots of things just work as
a result of using it (as opposed to custom baking something of my own).

AfC
Sydney

-- 
Andrew Frederick Cowie

OPERATIONAL DYNAMICS
Operations Consultants and Infrastructure Engineers

http://www.operationaldynamics.com/

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]