Theme is now stored only with OakTextView (observed by OakDocumentView) and the “global” setting is stored in user defaults (not Global.tmProperties), though it is still possible to override theme on a file-by-file basis via .tm_properties files.
This is because OakDocumentView is not in the view hierarchy and it obtains the theme via settings_t, so there is no way to notify about theme changes.
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.
Main reason I picked the named styles was that a time interval of zero would show as “in 0 seconds”, but we now check if check was less than 5 seconds ago and use “Just now” for that case.
To get scroll content behind title/toolbar we need to set NSWindowStyleMaskFullSizeContentView which appears to have been inferred with the old (deprecated) WebView.
If the window already has keyboard focus, sending it an “open” will instead close it, similar to pressing escape.
This might be useful for touch bar users.
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.
We now always return an NSToolbarItem instance, even when we don’t actually have a view controller for the identifier.
This should not arise in practice, but it makes it easier to test new items in the toolbar (by only adding the identifier).
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.
