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.
This introduces the `OakBackgroundFillViewStyle` enum with styles that are dark mode aware and should lead to more consistent use between UI elements in the future. Also, convert OTVStatusBar and OFBHeaderView to use the new style enum.
This is done by setting the ‘disableJavaScriptAPI’ key to ‘true’ in the tmCommand file.
The rationale behind this is that a command like “HTML → Show Preview” is using the HTML output view with user data which should not have access to the special TextMate JavaScript object, for example a user may have a `<script>` tag that loads JavaScript from a CDN, and such script would effectively have shell access to the user’s machine.
Most of these layout changes are related to the common pattern we used to set constraints for "dividers", where one of the dividers is specified to be connected to both edges of its superview then setting the other dividers' constraints to have equal widths (e.g., @"H:|[divider(==divider2,==divider3)]"). On 10.12, this now appears to result in ambiguous layout. We can resolve it by connecting at least one of the edges for each divider to its superview.
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
The previous name was inspired by WebView’s default API but it sounds like it is just the default implementation with a default baseURL: parameter, hence why I prefer to name it something different.
The problem is that HTML output is loaded from the x-txmt-command protocol, possibly with the “base URL” set to file://$TM_FILEPATH, so protocol-relative URLs like //example.org/main.css would be resolved as file://example.org/main.css.
We now try to detect these URLs (heuristically, since we only see the resolved URL) and (by default) redirect to https.
This commit checks for the presence of NSURLComponents which was introduced in Mac OS X 10.9. On 10.8 this commit has no effect.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
With the 10.11 SDK we get a warning about this initializer not calling super, however, we do not intend for instances of this class to be created, which is why we had the dummy initializer.
We should remove this class entirely, as it’s a workaround for a problem that was fixed a long time ago, but I haven’t yet tested if there are still bundles using the (legacy) tm-file: URL scheme.
We call `fileURL` here but the method doesn't actually exists (it's actually a property with the getter `isFileURL`). The URLs we obtain from NSOpenPanel are paths so it's probably safe to get the path without checking if it's a proper file URL.
