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.
This is the “modern” API that supports multiple items on the clipboard and gives us a badge to show how many items are being dragged.
Though the default drag image does not resemble Finder nor does it seem to support flocking out of the box (where multiple items are collapsed into a single proxy image).
Avoid setting explicit size of the image buttons and do not stretch the buttons to full height, except for reload, as that image seems to use a different size as our other buttons, and therefor doesn’t align properly.
Previously we stretched the views to full height (minus bottom divider) and relied on the views to then center their content, but the back/forward images were not properly aligned (at least on 10.14).
At least on 10.14 the window color is neither black (in dark mode) nor white (in light mode) and thus works well to give some contrast to the main text view.
Without this, it would sometimes fail when the outline view had to reload and expand items, presumably because updating the frame of the outline view (after reloading/expanding items) is not “instant”.
This is not relevant for TextMate, but when the file browser is used in other contexts, it would previously show hidden files, as there was no default include pattern to limit files to only those matching `*`.
