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 terminal has a default limit of 256, which can be too low for users with a lot of open files, as TextMate also keeps a file descriptor open for parent folders, in order to observe file system changes.
On my system though, launching TextMate via Finder has the maximum number of open files set to 8-12,000, also when launching via ‘mate’ (as that uses the Launch Services), but a user had problems with around 160 open files.
APFS does not support exchangedata(2) meaning that atomic save has to be done using a rename.
This means that the inode is not preserved and the date of the file’s directory is updated.
There are some disadvantages to this, and I have been running with atomic saving disabled shortly after switching to APFS, so I believe it is best to make this the default behavior.
Previously we would automatically pick up an Info.plist file copied using any of the CP_* keys, and both move it to the correct location (when belonging to target built) or ignore it, if we were copying it from an imported target.
To simplify the logic in the build system, it is however better to be explicit about this, also because we could actually want an Info.plist file among our copied files.
We previously did this for InfoPlist.vstrings files, but the changed extension was only a temporary workaround for not allowing multiple filters to run on a build input.
Previously we would download and archive the default bundles as part of ./configure and place the result in our source directory, this however both pollutes the source directory with generated files, but also had the ./configure step actually do a partial build, since we need to build the ‘bl’ executable to download bundles.
This is useful when working with one set of files in a project, then moving to another set without closing the original set first.
Alternate menu items are pretty subtle, but there are already a lot of ways to close tabs, and I didn't want to clutter the menu further.
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).
