Currently this bumping is limited to the Find dialog and happens when executing a search. Selecting from the Show Find History or subsequently using ⌘G, does not bump the date of the selected item (but probably should).
There are two issues here, one is that double-clicking a result sends both “selection did change”, “did single click” and “did double click” messages, which all should potentially select the result in the document, but this does introduce a bit of overhead, although I think this is insignificant.
The other issue is that a “single click” or “selection did change” shouldn’t select in the document when the user is selecting multiple items, which is useful for the various Copy actions.
There was a race-condition since we update it in the background queue, where it could be released, and using it in the main queue does not retain it before use.
We were previously assuming that the viewWillMoveToSuperview: was only called when moving to a view and then later when removed, but for 10.8.5 it appears that it might be called multiple times (with a nil superview), causing us to remove ourself as observer from something we didn’t observe.
Now that documents selected in the file browser can be searched, we can end up with a document path in the ‘otherFolder’ property.
This would happen by selecting a document in the file browser, opening the find dialog, and then selecting this document in the pop-up, as it is listed in the pop-up with a menu item tag of “FFSearchTargetOther”.
The Replace All button’s enabled state is based on count of matches (via bindings), so unbinding would leave it possibly enabled when it should have been disabled.
This is to avoid an exception when the code is used with menu items that have no represented object (which it normally wouldn’t in shipping code, but it seems it should be supported nonetheless).
The system can be updating the menu only to resolve a key equivalent, hence the image is not required. The document icon can be a little expensive to create because of the SCM badge. This would be noticeable when doing a folder search with hundres or thousands of results and then pressing ⌘1, here it would previously need to create all the document icons before responding to the key.
Since we do not load documents before the user selects them, e.g. after session restore or when opening multiple documents, it makes sense to have both an isOpen and isLoaded property, the former means “is shown somewhere in the UI” and would make it appear (e.g. in file browser) with close button etc., whereas the latter means that data has been loaded from disk, and we can safely access the buffer.
It looks better when we have a “full page” of results on the first update, rather than building up the first page of results file-by-file with only 0.03 seconds between each “increment”.
Since the checkbox button shown in the search results had its values bound directly to an FFResultNode instance, it would retain this object for as long as the checkbox was around, which is basically forever, although it could be reused with another FFResultNode instance, in which case the previous instance would be released.
To avoid this, we have introduced an NSTableCellView that stores the FFResultNode instance as its object value, and the checkbox uses a key path that goes via the object value for the bound values. This still creates a retain cycle, but the NSOutlineView will set all object value properties to nil when its data is cleared, thereby at least releasing the FFResultNode objects.
This requires the document search to be stopped explicitly rather than released, but I think this is an acceptable requirement. If it is not stopped, the search will simply run its course, which would also have been the case, if something else was retaining the object.
