On Tue, Sep 16, 2008 at 3:48 PM, Sam Thursfield [EMAIL PROTECTED] wrote:
It seems as though the first thing GtkTreeView does on receiving the
model is to iterate through every root node, calling iter_has_child
and iter_next for each until iter_next returns FALSE. This then leads
to my question - does anyone think it possible to modify GtkTreeView
to give it much lazier population? To display itself, surely it only
needs however many rows are visible .. and even these could be left
blank and drawn as its queries return.
But displaying is only a small part of what GtkTreeView has to handle.
If you want to have keynav working properly, columns reasonably sized
and programmatic scrolling working you need a little more information.
Though for fixed height tree views things are a little easier.
My initial instinct is that the only issue would be the scroll bar
going nuts, which I'm sure could be solved with an
tree_model_estimate_n_children or something stupid. Can anyone advise
me on if this seems like a good/bad plan, or a problem that's been
I am not sure how well it would work if the tree view has to estimate
its scroll bar based on an estimated number of rows. That said,
beyond 5 items scroll bars are woefully inaccurate anyway.
Proper lazy loading is still something I would like to have in
GtkTreeView. As far as I know, this is also going to require some
specialized support in the models as well. I haven't gotten to
looking at/implementing this yet myself, but at some point I certainly
will ;) It would be interesting to see what kind of extensions to the
model interface are necessary to make this really work -- I am unsure
if an estimate_n_children will do the trick. Also, before I am
going to make such changes to the tree view code base, I really first
want to have a good set of automatic tests in place.
gtk-app-devel-list mailing list