Bug: Icon-view reset its selection on reload

[benuri]

After the file watcher sends a notification about change in a path of the currently selected node, the node is being reloaded, and so the icon-view which lose its selection and reset its scrollers.

Many times (at least on my 10.8) it seems that nothing was really changed, so for the user it looks that the selection was just reset without any reason.

I think that when data is reload the icon view selection and its scroller location must be preserved (if the selected object(s) still exist).

To reproduce:

1. Open iMedia
2. Navigate to a folder that contains some photos
3. Select the second photo
4. Open the selected photo in another application, and re-save it.
5. Go back to iMedia and notice that the second image is no longer selected.

[benuri]

This seems to be a result of the node reloading policy which replace the all objects in the node's subtree with new instances, as explained here:

// If the delegate allows reloading, then create a background operation that causes the parser to create a new node. 
// Please note that this method causes the node (and all its subnodes) to be replaced at a later time in the main 
// thread (once the background operation has concluded). Afterwards we have a different node instance! That way
// we can handle various different cases, like subnodes appearing/dissappearing, or objects appearing/disappearing.

Can any one please give some additional details? Why is it important to create a new objects rather than modifying the subnodes/objects that need to be updated?

[mikeabdullah]

iMedia 2 creates and populates nodes/objects on a background thread so as to avoid blocking the main thread during any long-running operations. If the existing nodes/objects were to be re-used, there would be both the main thread and background accessing them at the same time, necessitating some sort of locking mechanism. Creating fresh nodes/objects each time avoids that threading issue.

[benuri]

I see. Thanks for the explanation.
So basically, it's possible to collect all information needed to update the node in a background thread but performing the actual updating in the main thread.
For example, in IMBFolder, one can prepare all IMBObject files in a background thread and then set the node's object property to a new array in the main thread (while trying to reuse objects from the old array when possible).
I believe this should solve the bug.

[mikeabdullah]

It certainly sounds possible. I didn’t design iMedia’s architecture though, so there may well be good reasons why it’s not doing this that I haven’t thought of.