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.
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.
This is instead of using the initialKeyView property. The latter is more declarative, and thus more abstracted / flexible, but we only need it for a single preferences pane, and the downside is that the generic code to “swap views” has to implement support for it, which I would like to avoid.
Relying on “modern” APIs we can eliminate most of the MASPreferencesViewController protocol:
- viewIdentifier → identifier
- toolbarItemLabel → title
- initialKeyView → call makeFirstResponder: in viewDidAppear
- hasResizableWidth / hasResizableHeight → use auto layout constraints
Furthermore, handling the preferences panes can be done by using child view controllers, and it might even be possible to use transitionFromViewController:toViewController:options:completionHandler: to switch between the views.
The last point is actually the motivation for this change, as I need a playground for animated view transitions.
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.
