There appears to be a problem with floating views (in tables) on Big Sur, so this is an attempt of a temporary workaround. The visual look of group rows is currently not very good (on macOS 11).
I am a little torn about this, as this is basically “revert Big Sur’s UI changes”, but I don’t think the new default look is appropriate for these lists.
I have not found it advantageous to get multiple carets when pasting search results, on the contrary, if we have a significant number of results, the multiple carets may impact performance.
This reverts the change that was made in 82593c8824.
This provided value during early development, but has been unused for years, and it would generate too much noise if converted to os_log.
So better to just remove it all and add os_log statements as needed.
This was required when we linked each framework as its own thing, which we do not do anymore, and if we do go back to this system, we can simply have symbols public by default.
We either set it explicitly or rely on automatic key view loop calculations.
As for the latter: When auto-layout was initially introduced, the automatic key view loop calculation broke, as it used the view frames before layout. It should have been fixed several OS versions ago though, so we can use it again, as long as we are not working with view-based table views.
Several places already used ‘token’ as the name for the result from NSNotificationCenter’s addObserver:… so this change is to be consistent.
While ‘token’ is less meaningful than ‘observerId’, the variable is only used with NSNotificationCenter API where the context makes it clear.
This is to postpone constructing the view: It’s probably not costly to construct it before we need it, but everything adds up, and it just feels proper to avoid constructing the views of view controllers until as late as possible.
We now add some bottom padding to the containing grid view, as it may be oblivious to alignment rectangles, and would therefore snap to the bottom of the checkbox label’s alignment rectangle, clipping anything drawn outside of it.
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.
