We now log an error if we are unable to obtain the NSURLLocalizedNameKey property, but still cache the (fallback) name (so that we do not repeatedly try to obtain the missing property).
When the NSTextField is not editable then it will (by default) hug its content, which is undesired, since the potential views following the text field (tags and close button) should appear right-aligned.
In general though, we do not have controls after the text field when it is read-only, as it represents a missing file, so this is just for layout consistency.
The motivation is to have a universal type for a file that knows whether or not the file is open/modified, if it has SCM status, what icon to use for the file, and supporting bindings for the latter (incase icon is updated).
This does sound like a “document” but there are many places where we just want to show a file icon (with SCM and “modified” status) without instantiating a full document, for example folder pop-up menus.
We would also like a way to “close” the file, incase it is open, for example from file browser or “open quickly”, which is not really a document action per se, furthermore, we may delete the file from the file browser, which again, is more of a file than document action, but if the file is “open” somewhere, it should be notified about the delete operation.
There appears to be a problem with floating views (in tables) on Big Sur, so this is an attempt of a temporary workaround. The visual look of group rows is currently not very good (on macOS 11).
I am a little torn about this, as this is basically “revert Big Sur’s UI changes”, but I don’t think the new default look is appropriate for these lists.
The spacing was so that the icon (in the folder pop-up) was aligned with the file item icons in the list below, but this no longer holds on Big Sur, and the spacing is too tight on Big Sur.
Like with the status bar pop-ups, I am using the increased spacing for all builds, to keep things simple.
By default, scrollbars are hidden on macOS when using a trackpad, but for mouse users, or people with scrollbars set to always visible, this is probably preferable (all other scrollviews in TextMate use autohiding scrollbars).
This is only when the default application is not TextMate.
Ideally the regular “Open” item would change to “Open With «application»” when the selected items are not text documents, and there is an application to handle them, but the code changes required for this are non-trivial because what the item does, is not decided until the user triggers it, and it may not treat all selected items the same.
The API expose a few more implementation details and require the user retains the delegate for the duration of the menu’s lifecycle.
The upside is that we avoid the global singleton and it is now possible to examine and use the information gathered by the Open With menu delegate.
Due to the high priority menus have in the responder chain, we effectively cannot have context menus with key equivalents, if these menu items have explicit targets.
We need the explicit targets so that the context menu works when the application is not the active application.
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.
