This is because we may sometimes want to enable implicit animations when updating this property, by making it read-only we limit places from where it can be updated, to make it easier to audit the code.
Currently no-one outside the class actually uses the property, so we could (and may) make it private.
For users on an OS earlier than 10.12, the tab bar will always be visible, even when configured to not show for windows with only a single document (tab).
This makes the title bar render in the same color as it did prior to building on 10.14, so that the current tab colors match.
It does however make sheets appear from “above” the title bar and makes the Dark Mode style darker, so this is just an intermediate fix until the tab bar gets revamped for 10.14.
Also, switch to use the new divider styles in most places. The remaining usage of the old "OakCreateLine" functions are in the OakChooser windows. These will be refactor for better dark mode support next.
For example when implicitly opening documents because we are duplicating the active document in the file browser, or closing a document because its file got deleted in the file browser, we want focus to stay in the file browser.
Previously we refocused the file browser when closing documents as a result of deleting files.
For duplicating files, this seemed to work because the file browser would not start editing the new file name until it had detected disk changes, thus it would happen after a slight delay.
The issue is that we call NSWindow’s makeFirstResponder: with the old field editor, but there is no guarantee that the old field editor is still part of the window’s view hierarchy.
This avoids having to support editURL: as public API for the file browser and limits the use of OakFileManager to OakFileBrowser (except for the “deleted item” notification being observed by the document window).
Versions of the OS X 10.11 SDK prior to 10.11.4 require this to
be done explicitly. This fixes the build on OS X 10.10 when
using the OS X 10.11 SDK from Xcode 7.2.1 and earlier.
When executing a bundle item without any default document open, we may first “load” the document, which is done via a callback (for when the document is loaded), and at that time, the bundle item reference has become invalid.
Previously the save dialog would update encoding settings solely based on the path, but the user could set different line endings or character set for a file type (rather than extension).
I see the following exception from macOS 10.12 users: Cannot update for observer <DocumentWindowController 0xhhh…> for the key path "selectedDocument.documentEdited" from <DocumentWindowController 0xhhh…>, most likely because the value for the key "selectedDocument" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the DocumentWindowController class.