Since OFBFinderTagsChooser always show only the favorite tags, any non-favorite tag set as selected or removable will simply be ignored, so there is no reason to filter these out at the call-site.
In fact, whether or not to show non-favorite tags should probably be an OFBFinderTagsChooser decision.
Furthermore, the tag’s favorite status is set during initialization, so it could actually be outdated when showing the OFBFinderTagsChooser.
This does mean that we are taxing our main thread with disk access. This is mainly a problem for users who are using network mounted file systems, but it does provide better abstraction in the code, and should this turn out to be a performance issue, I think a better approach is to fetch the tags in a dispatch queue (initiated by FSItem), and then use KVC to update the property once the tags have been loaded, although ideally such system would use some sort of batching, so that we do not dispatch in each property accessor.
Could also have the background directory scanner set a boolean property to indicate if the item has tags, as most items do not, and in that case, we can bypass the disk access. But this then only does half the job of encapsulating how tags are stored.
When the menu is brought up as a context-sensitive menu (right-clicking a file) the system will add a “Services” submenu as the last item, which looks nicer when there is a separator before it.
This submenu is not added when the menu is brought up via the gear button in the status bar, but the system will automatically strip trailing separator items from menus, so in this case, the separator will not be shown at all.
When using the gear menu in the status bar, the “Tags…” menu item was enabled. It appears that NSPopupButton validates its menu differently than NSView when bringing up the context-sensitive pop-up menu.
The file browser is observing the `finderTags` property so we need to do KVC updating of this property when we change the tags on disk.
It worked before because changing tags on disk triggers a reload, but that may not always be the case, e.g. the SCM data source showing uncommitted changes did not update in response to changing tags.
The rationale behind the latter is for consistency with pointer declarations, e.g. we need to do `NSString* const kConstant = …` to indicate that the variable is a constant NSString pointer, so for this reason I prefer to also do `CGFloat const kConstant = …`
This commit can be merged into its parent.
The reason is that menuForEvent: will draw an outline around the items under the mouse, which can be incorrect when we use the keyboard.
While we can address it by creating a fake mouse event that points to the selection, this will fail when there is no selection, so I felt it was better to always forego it.
Most of these layout changes are related to the common pattern we used to set constraints for "dividers", where one of the dividers is specified to be connected to both edges of its superview then setting the other dividers' constraints to have equal widths (e.g., @"H:|[divider(==divider2,==divider3)]"). On 10.12, this now appears to result in ambiguous layout. We can resolve it by connecting at least one of the edges for each divider to its superview.
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
It can be enabled by setting the ‘enableXcodeDataSource’ defaults key to YES.
The reason it has been disabled is that there is a file browser (crash) issue, and the 3 users who have provided steps to reproduce all mention clicking an Xcode project (though myself and Michael Sheets have been unable to reproduce, following those steps, and I do not think the bug is with the Xcode data source, but it does seem to be a catalyst).
It appears that the OS does not reliable initiate edit on 10.12.1.
When expanding and then collapsing an item, the OS will often then no longer edit the item on return.
This reverts commit cce3417962.
Back when this code was written there was a lot of problems related to application expectations (especially for the copy clipboard), and that might have been why we did not put NSFilenamesPboardType on the (services) clipboard, but it seems strange as it’s the only type we actually declare support for.
This shouldn’t be necessary but many of the new crashes on macOS 10.12 are from this method, though I suspect that ‘self’ is the already released object rather than ‘otherObject’ being nil.
Previously we would descend into the first selected folder, ignoring all other items selected. Now we ignore the folders, unless all items selected are folders, in that case, we descend into the first one.
Since we were testing for a class rather than instance method, this check would never be true.
Since I am not aware of any problems with the current code where we do not call super, I decided to remove rather than change the code (to call super when it responds to the selector).
The display name of an item may change, e.g. when user toggles “hidden extension” in Finder. The data source for the FSItem will catch this and update the displayName property, but since we did not observe it, the file browser would not update with the new name.
The reason we disabled use of bindings was because the binding is bidirectional and we had no setter for the new object value.
We solve this by adding a new property to FSItem that is for use with bindings and data formatters.
