The warning only appears when the anonymous enum is used in a conditional, hence why we do not need this change for all calls to NSFileTypeForHFSTypeCode.
This problem started after f1a1e1920f (handling key equivalents in performKeyEquivalent: instead of keyDown:).
It does however not appear that it is necessary to manually handle the return key to activate editing, therefore we have removed handling of this key.
Most likely it was required before view-based table views.
Some of the items require the key equivalent to be set as “inactive” as menu item keys are “global” and thus need to be unique, and can be triggered even when the view containing the context menu is not active.
Previously “Paste Next” in the Edit → Paste submenu could have its title updated to “Move Item Here”, which would never be restored back to “Paste Next”, similarly for regular paste.
This commit also drops the wrappers for the cut:, copy:, paste:, and delete: methods, as these wrappers resulted in a bit of redundancy related to menu item validation.
This is called before the main menu acts on keys, and thus allows us to catch keys that are otherwise assigned to menu items.
We only do this when the file browser is first responder, so it should be acceptable to have a few menu keys change behavior in that case.
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.
It appears that NSURL’s algorithm for “delete last path component” is to first append ‘../’ and then “normalize” the result, but the latter step can fail for some file URLs, for example with “file://localhost/path/to/https://macromates.com/” it will be stuck at the two slashes (continuing to append ‘../’).
Such malformed (file) URL can be created by running ‘mate https://macromates.com/’.
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.
