The motivation is not having to know about the interface of the view controller that creates the instance.
It does have performance disadvantages in that collapsing or expanding items in *any* outline view will now trigger notification callbacks for our table header cell views.
In practice though expanding/collapsing is not a common action, and the chance of this being done, while the find window has so many results as to impact performance, is probably small (it’s only the header cells that register for this notification).
That said, it would be good to find a better solution.
Ideally we would also change the enabled state of the “matching” text field, but this is currently handled via bindings, so we cannot fix that without either delaying resizing until next event loop cycle, or by manually updating the canEditGlob property.
The main advantage is that we can let the stack view handle showing and hiding of the stop button and progress indicator.
The height of the status bar (text field) is now fixed at 16 pt. The reason we have to fix it is that we are using a button for the status bar (so that the user can click toggle between showing number of files and number of bytes searched), but a button with an empty string reports a different fittingSize than one with a non-empty string.
Therefore without a fixed height, we need to ensure status bar never gets set to an empty string, which we did before, but I think it is nicer to simply fix the height of the status bar.
Also because the progress indicator and stop buttons might actually be slightly taller than the status bar used to be.
Since 2.0-rc.1 we have received 70 crash reports pointing to nil string being passed to the NSAttributedString initializer.
I’m almost inclined to think that NSString construction fails for other reasons than the data not being valid UTF-8, since both excerpt and replace string, are already passed as an NSString.
When to_ns fails we show a “Please file a bug report!” message on red background in the find window, since I would like to know why this situation arise.
Since virtually all calls to ‘append’ wraps the std::string with ‘to_ns’, we might as well move the wrapping to the function, as this is not public API.
The property is renamed from ‘currentResponderIsOakTextView’ to the more appropriate ‘keyWindowHasBackAndForwardActions’.
Furthermore, the menu items are found via indexOfItemWithTarget:andAction: instead of by title, although the title of the submenus for these menu items is still hardcoded.
The problem is that if shiftLeft:/shiftRight: exist after goBack:/goForward: in the responder chain, we would prefer the former. This can happen because main window is after the key window in the responder chain, so if the former contains an OakTextView, a potential responder in the key window would never be found.
This is simpler than having to proxy the action (and target) for the button.
Previously the button was created on demand, but now that we always create it (and hide it when not required), we might as well have users set action and target directly on the button instance.
Minor downside is that labels for open and closed files are no longer aligned.
It would be nice to find a solution for that, but without dropping the stack view, as it saves us > 100 lines of code.
Previously we fetched items row-by-row from the database, which could be slow even with only 500 entries.
We now fetch everything using a single query. Long-term though we may fetch the strings on-demand but with some prefetch, mainly just to avoid an issue if the user store hundred of megabytes in the clipboard history.
Originally the idea was to store it with the current pasteboard item, so that updating the pasteboard would automatically clear the matches.
But since there is currently only one use-case for this feature, the Find class can simply register for a “pasteboard did change” notification (which it already does for other reasons), and clear the matches if the clipboard changes.
The only downside is that the text view cannot depend on the find framework, as the latter already depends on the former, but we can just import the Find interface, and assert that the class will be present at run-time.
Long-term though, we should refactor this, as we do need two-way communication between these frameworks, for example to make matches live or update the selected match in the Find window when advancing through them in the text view (with ⌘G).
The problem with adding an unchanged string to the pasteboard is that it generates a notification which may trigger other components to drop auxiliary data related to the current pasteboard item, for example the magnifying glass icons in the gutter are cleared each time the find clipboard changes.
