This is simpler than having to proxy the action (and target) for the button.
Previously the button was created on demand, but now that we always create it (and hide it when not required), we might as well have users set action and target directly on the button instance.
Minor downside is that labels for open and closed files are no longer aligned.
It would be nice to find a solution for that, but without dropping the stack view, as it saves us > 100 lines of code.
This fixes problems with symbolic links, for example file browser may show contents of /private/tmp when we ask to select /tmp/foo.txt. Comparing file path URLs will fail even though /tmp is a symbolic link for /private/tmp.
Note that this fix only works for when the current document is already part of the items in the file browser, as we still store pending URLs to select as file path URLs.
Incase of a file reference URL, moving an item will have the URL resolve to the new file path, therefore such URL cannot be used for storing the old location/path of the item.
This is currently not a problem with TextMate, as all URLs are file path URLs, but as we are moving to using readObjectsForClasses: with NSURL, we will be receiving file reference URLs from Finder.
Terminal.app is peculiar about what it expects to be on the clipboard. If we only write URLs like this:
[pboard clearContents];
[pboard writeObjects:urls];
Then it will not paste anything. There *must* be string fallbacks for it to support paste. But if we also write an array of strings like this:
[pboard clearContents];
[pboard writeObjects:urls];
[pboard writeObjects:[urls valueForKeyPath:@"path.lastPathComponent"]];
Then it will paste both the URLs and the strings, but where the URLs will be space-separated, the strings will not. If instead we write a single string fallback only for the first item, like this:
[pboard clearContents];
[pboard writeObjects:urls];
[pboard setString:@"whatever" forType:NSPasteboardTypeString];
Then it will paste the URLs and ignore the string fallback for the first URL.
While in theory just a wrapper for VNODE events, there are some edge cases:
- Observe missing file: Report when created (observe all ancestors to know).
- Rename ancestor: Treat as rename (observe all ancestors to know).
- Move observed file to trash: Treat as delete (reported as rename).
- Rename file with symbolic link in path (e.g. /tmp): Preserve symbolic path.
- Delete observed file and write new one: Treat as a write (reported as delete).
- Rename observed file and write new one: Treat as a write (reported as rename).
- Change case of file: Tricky on case-insensitive but preserving file systems because newPath != oldPath but both exist, so it looks the same as “rename and write new file” (previous case) that should be reported as write.
There is also an issue observing a symbolic link, here we should really observe both the link itself (does it get renamed or deleted) but also the resolved path (does this file get updated).
Currently though this is NOT implemented.
Previously some status bars could be compressed vertically because the dividers did not have a fixed height, so they were sized based on their intrinsic height.
With a fixed height the intrinsic height is redundant and previously it was simply hiding an issue with an under-constrained layout, so better just remove them.
This makes the color of the separator bar better adapt to the color of the status bar and should make things more consistent, as we already have separators inside visual effect views in various places.
Also adjust height of the vertical separators in status bars to only be 15 pixels so that we have equal padding above and below.
Previously it was a subclass of OakBackgroundFillView which adds the NSVisualEffectView as a subview, but this messes up compositing in some cases where an ancestor view is also an NSVisualEffectView, for example when placing the file browser in a “source list” split view item (using NSSplitViewController).
Also change the material to NSVisualEffectMaterialTitlebar. I think this looks better, as the previously used NSVisualEffectMaterialHeaderView does not look identical to other table view headers and only have very faint bottom border but very noticeable “within window” compositing.
A further advantage of changing to title bar material is that NSVisualEffectMaterialHeaderView requires macOS 10.14, so by using title bar material, we avoid having a different code path for users using older versions of macOS.
Previously we would only do this on macOS 10.14 and later, but as we now also use “within window” compositing for the header view prior to macOS 10.14, we should always inset the scroll view.
Furthermore, even without “within window” compositing, insetting the scroll view should not cause any issues, so the code was actually not required previously.
This is to make it easier to support Cocoa’s native resume feature, as for this, we should keep all state in the controller, but also, the controller should be able to know if view state changes, for example expanded/selected items in the outline view, which require our controller to be the delegate.
For example if we have a directory with files named 001-foo.txt, 002-bar.txt, and 003-fud.txt, duplicating one of these will result in the duplicate starting with 004.
Also improve support for finding dates in file names being duplicated. Previously we only looked for YYYY-MM-DD but now we also support YYYY_MM_DD and YYYYMMDD. If a date is found in the file name being duplicated, it is replaced with the current date in the duplicate.
The workaround is untested, as I have not found a way to reproduce the issue, but there is some debug output that can be reviewed and hopefully give some idea as to what is causing the issue.
The debug information can be collected by running the following in a terminal:
log show --predicate 'process = "TextMate" AND eventMessage CONTAINS "loadChildrenForItem:expandChildren:"'
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.
