Since we have multiple application targets, it doesn’t make sense with a global APP_NAME variable.
Though if building the frameworks as standalone bundles and embedding them in different applications, we may need some sort of unique component in the bundle identifier, but we currently do not do this (they are all statically linked, so the Info.plist is currently unused).
It appears to be ignored on 10.14 but earlier versions of macOS rendered the elements with a shadow, which is probably not a good fit for our current design.
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.
