We pass --minimum-deployment-target to ibtool so having the deployment target in the xib is redundant.
Furthermore, it appears that when building on macOS 11, a directory will be created for xib files when they:
1. Are a custom view (as opposed to a window)
2. Contains a deployment target
3. Contains a table view
Therefore, to successfully build on macOS 11 we cannot set deployment target for xib files meeting the above 3 criteria, which is easier when we only set the target in one place, instead of every single xib.
Thanks to Kevin Sjöberg for helping track this down.
The motivation is to have a universal type for a file that knows whether or not the file is open/modified, if it has SCM status, what icon to use for the file, and supporting bindings for the latter (incase icon is updated).
This does sound like a “document” but there are many places where we just want to show a file icon (with SCM and “modified” status) without instantiating a full document, for example folder pop-up menus.
We would also like a way to “close” the file, incase it is open, for example from file browser or “open quickly”, which is not really a document action per se, furthermore, we may delete the file from the file browser, which again, is more of a file than document action, but if the file is “open” somewhere, it should be notified about the delete operation.
We set the default position to a fraction of the split view height (rather than absolute value), so this is only if scaling is not done proportionally, and only when there is no saved split view size.
When building on macOS 10.15, the split view will show the NSBrowser split as collapsed and not allow the user to resize it, though only when running the build on macOS 10.14 or earlier.
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.
This was done using search and replace. Presumably it should be done in Xcode so that it can adjust the xib for the new deployment target, otherwise what is the point of storing deployment version in the xib and provide it as a command line argument to the xib compiler as well (only to get a warning if the versions do not match)?
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).
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.
