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
> tackled before?

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

Reply via email to