gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] NSOutlineView lazy loading of the outline item tree


From: Fred Kiefer
Subject: Re: [PATCH] NSOutlineView lazy loading of the outline item tree
Date: Sun, 09 Mar 2008 18:11:41 +0100
User-agent: Thunderbird 2.0.0.9 (X11/20070801)

HI Quentin,

I may have missed something in your patch, but to me it looks like your
code may not handle one case correctly:

1. Expand an item (children get loaded)
2. Close this item
3. Children get changed
4. Reload the item
5. Expand the item again.

I did not test this, but by looking at the code I would expect that
still the old children would be displayed.

Could you please make sure that this wont be the case? I think this
should be as easy as to remove the item from the _itemDict, it will then
reload its children when expanded.

What I didn't understand is why in _isItemLoaded: you didn't check for
the result not being nil. When we have something in there, then the item
is loaded, otherwise we need to load its children.

There are also a few commented out lines that could be removed from the
patch.

Cheers,
Fred

Quentin Mathé wrote:
> Hi,
> 
> Here is a new NSOutlineView patch that implements the lazy loading of
> the outline items. Until now NSOutlineView entered in an endless
> recursion on browsing a file system or a not-so-small object graph (by
> trying to create outline items for all the files for example). This
> patch modifies _loadDictionaryStartingWith: to only load expanded items.
> _openItem: has been updated to check whether the item needs to be loaded
> (or reloaded) before retrieving the children of the item and inserting
> them as cells. If the children haven't been loaded,
> -_loadDictionaryStartingWith: will be called for the given item which is
> getting expanded/open.
> This patch is based on Cocoa behavior.
> As a side note, I found this code a bit hard to read, for example having
> better names for variables rather than item, sitem, startitem could
> help. However I don't know which names could work better :-/
> 
> 
> 
> 
> Cheers,
> Quentin.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev





reply via email to

[Prev in Thread] Current Thread [Next in Thread]