Previously some status bars could be compressed vertically because the dividers did not have a fixed height, so they were sized based on their intrinsic height.
With a fixed height the intrinsic height is redundant and previously it was simply hiding an issue with an under-constrained layout, so better just remove them.
This makes the color of the separator bar better adapt to the color of the status bar and should make things more consistent, as we already have separators inside visual effect views in various places.
Also adjust height of the vertical separators in status bars to only be 15 pixels so that we have equal padding above and below.
This is instead of the more opaque OakCreateHorizontalLine(OakBackgroundFillViewStyleDivider).
Also use NSLayoutFormatAlignAllLeading with the visual format language instead of manually creating constraints for the dividers.
Previously it was a subclass of OakBackgroundFillView which adds the NSVisualEffectView as a subview, but this messes up compositing in some cases where an ancestor view is also an NSVisualEffectView, for example when placing the file browser in a “source list” split view item (using NSSplitViewController).
Also change the material to NSVisualEffectMaterialTitlebar. I think this looks better, as the previously used NSVisualEffectMaterialHeaderView does not look identical to other table view headers and only have very faint bottom border but very noticeable “within window” compositing.
A further advantage of changing to title bar material is that NSVisualEffectMaterialHeaderView requires macOS 10.14, so by using title bar material, we avoid having a different code path for users using older versions of macOS.
Previously we would only do this on macOS 10.14 and later, but as we now also use “within window” compositing for the header view prior to macOS 10.14, we should always inset the scroll view.
Furthermore, even without “within window” compositing, insetting the scroll view should not cause any issues, so the code was actually not required previously.
This is to make it easier to support Cocoa’s native resume feature, as for this, we should keep all state in the controller, but also, the controller should be able to know if view state changes, for example expanded/selected items in the outline view, which require our controller to be the delegate.
This is because third party framework headers are likely to be installed in directories with many other headers that can clash with some of our custom frameworks.
Closes#1441.
We now do all the work in NSMenuItem’s setActivationString: and no longer require subclassing the mutable versions of NSAttributedString.
It should now be more transparent what the code does and why it does it.
Starting with macOS 10.15 the system will use new NSAttributedString API to obtain bounding rect, so we need to (also) overload this to return our fixed bounding rectangle.
We don’t care about the trim mode as nobody is reading the generated HTML, but we have to supply something, previously we enabled everything, which is now giving an error despite the documentation saying that trim mode can be “one or more of the following modifiers”:
% enables Ruby code processing for lines beginning with %
<> omit newline for lines starting with <% and ending in %>
> omit newline for lines ending in %>
- omit blank lines ending in -%>
It would seem that ‘<>’ is mutually exclusive with ‘-’ so now we pass ‘%-’ for trim mode.
Since this is internal API it should not be necessary to sanitize the range, but based on textmate/bugs#34 it is causing a lot of crashes on macOS 10.15.
This is because we ensure that each target copied to another target, gets signed before we copy it.
We initially used ‘-deep’ but that actually never worked fully, as it didn’t find all executables in our bundle, presumably only embedded bundles like frameworks and plug-ins were found and signed.
Previously we used the system’s temporary directory and removed the script after use.
This is because macOS 10.15 will “call home” (notarization?) when executing a new script (that it has not seen before), so with an unstable network connection, running commands could take several seconds.
Apparently the window’s delegate is not used for context menu actions in full screen mode, although NSApp’s targetForAction: does find the receiver, so this appears to be a framework bug.
The specific issue being addressed is macOS 10.15 where the mount point for ~/Library/Application Support is under /System/Volumes/Data so our assertion that the relative path received in our callback can be appended to the mount point, to match the path being observed, is false.
As a workaround we call realpath() on the path we wish to observe, observe that path, and in our callback we calculate the relative path from the real observed path, and append that to the requested path.
In theory the caller could be made responsible for expanding paths to their real path, but the current abstraction allows observing non-existing paths, which is why it needs to handle this path rewriting.
If one event cycle triggered multiple re-layouts, we could end up reusing a tab bar view that had been removed from its superview because the weak pointer had not yet been cleared (as the view hadn’t yet been fully released).
This could happen during window construction in a scenario like this:
1. Window gets created at some size, tab bar views are created
2. Window size gets restored causing some tab bar views to be removed
3. Active tab gets restored bringing an overflow tab into the visible area, re-using a removed view
We don’t yet rely on any 10.12 specific API other than os_log which can be skipped without user impact.
Unfortunately when trying to build for 10.10 using latest Xcode/SDK the linker gives an error for missing symbol: _objc_loadClassref.
Going forward we will require 10.12 but as there is no non-beta build for 10.11 users yet, I wanted to make one.
