On Fri, Jun 04, 2004 at 06:51:36PM -0600, K. Haley wrote:
Cool. So if that is the case, then it makes it easier to slap a DB
backend in place, as the GUI already seems to be reading in header
information into widgets in a piecemeal fashion.. which is what one wants.
The GUI should be requesting data from the Article as it's needed for
display. If it's not then I would consider that to be a bug.
To do this:
- create your GtkTreeModel with only one "column", a pointer to the Article
- create your GtkTreeView with multiple columns that each has a custom
"cell data" function:
Another option would be implementing the GtkTreeModel interface on your
article list. This, however, seems to be quite a lot of work. I've
been working on a GtkTreeModel that works with an array (not list!) of
pointers that seems to be quite fast. I typically update in large
batches, so I can reallocate the array once, and I delete rarely; for
other operations the array is much more efficient.
The other major optimization you can do is to use a GTK 2.4-specific
API that sets all of the rows to the same height; this cuts down on
computations significantly. You lose support of differing-height (think
different languages) rows, but that may be acceptable (I don't know
enough about NNTP to know whether you can have non-ascii names/subjects,
etc).
signature.asc