The submenu now show the immediate children in the first submenu, with parents below these items, although without adding submenus to the parents.
Also show ⌘↑ for the first parent, to improve discoverability of this key equivalent.
Now that we use OakTransitionViewController for toggling the results view, using a stack view provides no real benefits, and are in some ways a little bit more opaque, for example the hugging priority weirdness and what width constraints are setup by the view.
The problem is that we use ⌘F and ⇧⌘F as key equivalents both in the Edit → Find submenu and in the “where” pop-up button’s menu, but as they previously had different action methods, the system would only allow the key to trigger one of these items (and remove the key from the other, as part of menu validation).
Normally not an issue, but when the find dialog is in another space, it appears menu validation would not update the Find → Edit submenu items to get the key equivalents, even though these would be “first responders”.
By using same action method for both Find → Edit submenu items and the “where” pop-up menu items, we avoid the key equivalents being removed from any of the two menus.
This avoids the need to map between the two enumeration constants, although we handle some of the constants before passing them to the find singleton, so the code has not yet been updated to remove the redundant mappings.
When set to NSLayoutPriorityDefaultHigh then it is able to compress text fields. The text field does set content compression resistance to NSLayoutPriorityDefaultHigh, but for reasons I do not understand, this is not enough to keep it from being compressed by the stack view.
The reason I do not understand this is that even with a high hugging priority, we should not make views smaller than their fittingSize, but it appears the stack view will do that.
Only one stack view actually contained a text field, and we already used a priority lower than NSLayoutPriorityDefaultHigh, so this commit does not change anything, but to play it safe, we should probably avoid NSLayoutPriorityDefaultHigh for stack views.
The system will return ‘nil’ for empty text field, which was causing the replace preview in the find dialog to not show any replacements, and if doing actual replacements, 0xFFFF would be inserted for replacements.
The pop-up menu will show shortcut keys next to the items that the keys will trigger, although we are re-purposing File Browser → Back / Forward for these actions, so it is worth considering moving them to the View menu.
Contrary to a previous finding, the NSTextField doesn’t always resize when the content changes, and controlTextDidChange: is only sent when the string is edited by the user (via the field editor), so we must use bindings to be notified about *all* changes.
Currently find window is created during initialization, we should delay that to be when first requested (loadWindow).
Furthermore, some code might be moved out of the FindWindowController, for example more logic related to search results might be moved to the search results view controller.
This encapsulates syntax highlight, history, and auto-resize behavior.
We currently do not call updateIntrinsicContentSizeToEncompassString: when changing the content, but it appears to be unnecessary. It might actually be that with auto-layout, there is no longer any need for repeatedly updating the intrinsic height of the control manually.
But leaving things (more or less) as-is for now.
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.
