[Top][All Lists]
[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