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 not made clear from the documentation, however, the documentation does state that the token will be strongly held by the notification center, until the notification is removed, therefore it is safe to only keep a weak reference to the token (even if the implementation should change).
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.
To get scroll content behind title/toolbar we need to set NSWindowStyleMaskFullSizeContentView which appears to have been inferred with the old (deprecated) WebView.
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.
The property is renamed from ‘currentResponderIsOakTextView’ to the more appropriate ‘keyWindowHasBackAndForwardActions’.
Furthermore, the menu items are found via indexOfItemWithTarget:andAction: instead of by title, although the title of the submenus for these menu items is still hardcoded.
The problem is that if shiftLeft:/shiftRight: exist after goBack:/goForward: in the responder chain, we would prefer the former. This can happen because main window is after the key window in the responder chain, so if the former contains an OakTextView, a potential responder in the key window would never be found.
This is motivated by having received several crash reports from CFSocketManager over the years, example crash log from TextMate 2.0.8:
Thread 5 Crashed:: com.apple.CFSocket.private
0 libsystem_kernel.dylib os_fault_with_payload + 10
1 libsystem_kernel.dylib __darwin_check_fd_set_overflow.cold.1 + 31
2 libsystem_kernel.dylib __darwin_check_fd_set_overflow + 79
3 com.apple.CoreFoundation __CFSocketManager + 939
4 libsystem_pthread.dylib _pthread_start + 148
5 libsystem_pthread.dylib thread_start + 15
Although one of the new API methods is deprecated starting with macOS 10.15, but that change is minor, and the replacement wasn’t introduced before macOS 10.15.
