Main reason I picked the named styles was that a time interval of zero would show as “in 0 seconds”, but we now check if check was less than 5 seconds ago and use “Just now” for that case.
We now always return an NSToolbarItem instance, even when we don’t actually have a view controller for the identifier.
This should not arise in practice, but it makes it easier to test new items in the toolbar (by only adding the identifier).
This is instead of using the initialKeyView property. The latter is more declarative, and thus more abstracted / flexible, but we only need it for a single preferences pane, and the downside is that the generic code to “swap views” has to implement support for it, which I would like to avoid.
Relying on “modern” APIs we can eliminate most of the MASPreferencesViewController protocol:
- viewIdentifier → identifier
- toolbarItemLabel → title
- initialKeyView → call makeFirstResponder: in viewDidAppear
- hasResizableWidth / hasResizableHeight → use auto layout constraints
Furthermore, handling the preferences panes can be done by using child view controllers, and it might even be possible to use transitionFromViewController:toViewController:options:completionHandler: to switch between the views.
The last point is actually the motivation for this change, as I need a playground for animated view transitions.
We might as well use the standard properties to store label/title and identifier.
It indirectly fixes a bug, as the code that generates the ⌘1-n menu would look at identifier instead of viewIdentifier to find selected item (so no item was shown as selected).
While we can copy the interface of this class to our sdk-compat.h header, we also need to setup weak linking for the class itself, so better just skip it for now, as it provides no benefits over the fallback code.
Rows are baseline aligned, and when that is the case, the grid view will use the y-placement of the first cell (which is not ‘none’) to place the row.
However, since the non-label column is likely to contain taller views, we should use that for placing the row.
That said, this change has no effect on the resulting layout, possibly because there are constraints with higher priorities that prevent the labels from bleeding into neighboring rows.
If full keyboard navigation is disabled (default) and “Accept rmate connections” is also disabled, no control in the on the preference pane would have keyboard focus, meaning that the view controller (implementing action methods for the pop-up and install/uninstall button) would not be in the responder chain (since first responder would be the window, which is after the view controller in the responder chain).
It now matches the width of the other preference panes, so the preferences window will only change height when changing preferences panes (unless the user has manually resized any of the resizable preference panes).
The goal is to have the window resize as little as possible when switching to another preference pane, therefore we aim for at least making the width the same for all panes.
The MGScopeBar class uses deprecated API, doesn’t support dark mode, and doesn’t seem to be maintained, therefore it’s better to switch to OakScopeBarViewController, although it doesn’t support “collapsing” into a pop-up menu.
This commit does change the category filter to work as a radio button, so if one category is selected, others will be deselected, which I do think makes more sense than the previous behavior of allowing multiple categories to be selected, and using the union of these when filtering.
This commit also retires the xib file. The long-term goal is to eliminate all xib files, as being explicit (in code) is preferred. The xib files only exist because in the past we did not have auto-layout.
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).
This changes a bunch of things:
1. Each framework now creates its own include directory for exported headers, and any target linking with this framework, gets that directory added to its include search path. This ensures deterministic behavior, unlike previously where a single shared directory was used, so even if target A did not explicitly link with target B, there was a reasonable chance that target B’s headers would be available when target A was built.
2. There is a new IMPORT keyword to indicate that a target depends on the headers of another framework but does not want to link with it. For example the `commit` shell command imports headers from the CommitWindow framework (related to their communications protocol) but linking with the CommitWindow framework would not be practical (as that would bring in all the resources of the CommitWindow).
3. All embedded targets are signed before being copied to their destination.
4. A new CS_ENTITLEMENTS keyword allows specifying `codesign` entitlements. Currently the hardened runtime is enabled, although this does make development problematic, as modifying files of a running instance (as done during rebuild) can cause TextMate to crash with EXC_BAD_ACCESS (Code Signature Invalid). Worse though, it seems the system has a cache of blacklisted executables indexed by inode. So if e.g. the embedded `mate` executable gets blacklisted, one has to manually remove and rebuild it, before it gets possible to use it again (by default, rebuilding causes the inode to be re-used, but I may change the build system to unlink before copy).
5. The build file no longer contains rules related to deployment. Instead variables are declared that a user build file can reference to extend the build with notarization/deployment rules (without having to hardcode build directory paths).
6. The code has been made modular with a Compiler super class that is subclassed to add support for file transformations (xib, ragel, asset catalogs, etc.) and a transformed file can have its own settings.
7. If target A links with target B, the linker flags of target B will now be included when linking target A.
8. Currently no indexing of help books. Unsure if this is actually useful.
9. Previously it was possible to have umbrella targets that would not generate any output, but just change settings for their sub-targets. This is no longer supported, as the implementation was arcane. I would like to introduce a different system for managing sectioned settings. Related to this; settings in target files are now always merged, regardless of whether using ‘=’ or ‘+=’.
