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

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


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.


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


Andrew Frederick Cowie

Operations Consultants and Infrastructure Engineers

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]