[Gtk-sharp-list] NodeStore and lazy loading

[Jeroen Zwartepoorte]

The FileSystemModel example is a bad one. I'm very rusty wrt JTree,
but afaics this model *only* works with a custom JTree. The example
model doesn't return instances of TreeNode, so a standard JTree
doesn't work with this model.

Using an hourglass and a "Loading..." node are really implementation
specific. In the GnomeVfs TreeView i coded, performance was pretty
good, negating the need for an hourglass or "Loading..." node.

The example only works as long as JTree initially only queries for the
root nodes and if those are leafs or not. I don't recall offhand how
Gtk does this.

Anyway, is this really something worth taking the time to
discuss/possibly implement? For the GnomeVfs tree, i basically had
something working after half an hour of hacking. Just lookup which
events tells you when a row is expanded and go from there. I can try
and see if i still have this example lying around somewhere.

Jeroen

On 8/18/05, Ben Maurer <bmaurer at ximian.com> wrote:
> > I don't believe this is wrong: from an MVC point of view, the model
> > shouldn't know/care about which branches are visible or not. Ideally
> > you'd just add an event handler for the expand/collapse events and
> > *tell* the model to load the specific branch for real.
> >
> > This is also how the Swing tree widget works btw (for reference, see:
> > http://java.sun.com/docs/books/tutorial/uiswing/events/treeexpansionlistener.html)
> 
> That's one way of doing it, and it is doable with the swing api. But
> consider this from the java documentation:
> 
> http://java.sun.com/products/jfc/tsc/articles/jtree/src/FileSystemModel.txt
> 
> The lazy load structure is implemented without any need to look at the
> view. IMHO, this method is easier to reuse (the code for using the model
> is alot easier). Also, we could do some fancy things this way. Imagine we
> have a property in TreeNode
> 
> protected virtual bool ShouldLoadAsync { get; }
> 
> A class could override this to say "hey, I will be slow to load". The
> person coding the tree view could set a property (or maybe we just do it
> by default) that would cause the hourglass cursor and a new tree node that
> says "loading...' to be created when such nodes are created.
> 
> The "wait for a listener" model is also messy because non-leaf nodes need
> a dummy child. As a consequence of this, people have two options: they can
> either load all the children of visible nodes. This can hurt performance,
> but is often simpler to implement. For example, monodoc does this. The
> other option is to create a dummy child node. This is messy code wise, but
> helps out performance alot. With the swing model in the above url, one
> does not even need to think about this.
> 
> -- Ben
> 
> 
>