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.
One spin report shows that an attributed string is being used with the text field. Calling ‘description’ on an attributed string can produce a lot of output (dumping all the attributes) and the spin report in question shows a lot of symbols related to auto-layout and text sizing, so perhaps this is related.
http://lists.macromates.com/textmate/2016-August/039891.html
This commit turned out rather complex because the only proper way to do this seems to do with a data formatter, but the data formatting protocol assumes that we can construct an object from the editing string, which is not possible when the string only represents a subset of the object being edited.
Unlike the existing setNewDisplayName: this function does not try to figure out if the argument was the file’s display name (with potentially hidden extension).
This was previously placed in the file browser’s action menu and thus probably overlooked by many, even though ⇧⌘A is a very useful key equivalent, since many commands work on the entire project when there is no selection in the file browser.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
Previously we would only accept first responder if clicking an already selected item, this was so that the user could select items in the file browser without losing focus from the text editor.
Unfortunately after switching to a view-based file browser, clicking an already selected item (even when the file browser does not have focus) brings up an edit-in-place text field which is undesired.
Worse is that it is brought up after a delay, so a user may for example click the file browser (to give it focus) and instantly initiates an action like duplicate, which brings up the edit-in-place text field for the new copy, but then after a short delay, will move the edit-in-place text field to the originally clicked item.
The problem is that the URL property for all descendents of this item are pointing to the old path.
Ideally we should recursively update the descendents, because the current workaround loses the expanded state of the folder.
To reveal an item we need to expand all parents, but after switching to a view-based outline view, expanding items will be done animated, and updating the outline view’s bounds won’t happen until after all animation has completed.
I tried adding a completion handler to the current animation context, but this ran before the bounds had been updated.
I also tried to disable expansion animation (when we have an item to reveal), but I was unable to make that work. What I did was group the expandItem:expandChildren: call in a new animation context for which the duration had been set to zero.
