Hi,
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 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.
regards,
-kris.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
