I tried out the “search” functionality and found it to be next to useless for my purposes.
The problem was, my experiments left me with various unwanted searches at the top of the navigator, that couldn’t be deleted.
Being a macOS programmer, I decided to investigate if there was a way to remove these and I found it!
Warning!!! This is only for the brave and experienced in manipulating .plist files
First, quit DxO.
On a Mac the location of the offending file is ~/Library/Preferences/com.dxo.PhotoLab2.plist
You need to open this in a suitable editor and look for the searchLists key; all you need to do to get rid of all searches is to delete this key.
For those times when DxO keeps on unfolding the navigator every time you open it, even though you painstakingly closed all branches:
In the same file, look for the APPStatusExpandedNodes key and delete all its subkeys. This will leave you with only the Favourites section unfolded to the Home level (at least that’s what happened on my computer)
From then on, you should attempt to never unfold nodes apart from under the Favourites section. The end result is that DxO opens and the navigator is usable in a couple of seconds.
Of course, all this would be unnecessary if DxO provided a simple button to clear searches and either, a “collapse all” button, or to remove expanded folders from the .plist file when they are collapsed.
Upon further investigation, it would appear that, at least after clearing the .plist subkeys, collapsing nodes does now remove them from the .plist file.
Except for the path of the last selected folder, which remains appended to both the Devices and the Favourites paths in the .plist file.
Ultimately, the path to a folder that is no longer visible or selected shouldn’t be appended to the collapsed root folder in the .plist.
I’m sorry if that has seemed to be a bit rambling but, sometimes, I have to write things out in order to clarify what’s going on.
As a result, I now understand that the APPStatusExpandedNodes key is needed to remember how the navigation tree was expanded under a collapsed node, so that the same unfolded structure is visible when the node is re-expanded.
The idea of cleaning the array under this key appears to have solved the problem of non-usability of the navigator after starting DxO but there still remains an inconsistency in the unfolding behaviour.
When re-expanding a node after having collapsed it, any sub-nodes that were expanded are re-expanded.
When re-expanding a node after having collapsed it, then closed and re-opened DxO, any sub-nodes are not re-expanded. This is certainly better behaviour, because it avoids that awful wait for the tree to restore all those expansions.
In summary, with the expanding/collapsing of nodes, after having cleaned out all the subkeys under APPStatusExpandedNodes, the navigator now seems to behave better (so far).
I don’t know if you guys at DxO have changed anything to solve the auto-expansion problem; it’s just annoying that I had to dig into a .plist to get it to behave better.
The real cause of all that never-ending auto-expansion stuff is:
If you are working in something like a sub-sub-sub-folder of the root and you have also visited and expanded other branches from the root, the navigator attempts to re-expand all previously expanded branches from the root, not just the branch that you were working on. This is what takes the time.
The answer seems to be to ensure that all other sub-folders, on the root that holds your selected folder, are collapsed before closing DxO. Even then, the list of previously expanded folders remain in the .plist file but are not referred to when re-expanding a root folder immediately after restarting and are not re-expanded (thankfully).
However, I have also discovered that, not only are the expanded folders marked as such in the .plist, the “nearest to root” folders are also marked in the database. This kind of double-source-of-truth is also the cause of a lot of users’ pain with .dop vs database conflicts.
