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.
The data sources should already re-use items, as they are passed the old items, but since data sources are multi threaded, there might perhaps be a situation where the items passed gets updated out-of-order and re-use isn’t perfect (I haven’t been able to confirm this).
Re-using the items, when we use the animation methods of the outline view, does however seem to be very important, because the outline view will neither copy nor retain the items returned from our data source, so we must ensure they stay retained until we have told the outline view that the item no longer exist, so replacing an item with one that is equal but not pointer identical, without notifying the outline view, will cause random crashes.
At least that is my theory.
When running a debug build we get an exception due to lacking this method and the documentation does seem to indicate this is required for scalar keys.
The method wasn’t public before 10.10 but since we need to check for 10.10 we can simply conclude that lack of this method means that we are not running on 10.10.
The algorithm will avoid changing root when possible. If root has to be changed, we favor the current project folder, if that is not possible, we use the parent for the item being selected, unless the item is in a file package below the project folder, in that case, we use the root of the file package.
The problem is if we right-click an item that causes content to be changed (e.g. Show Enclosing Folder) then later in the same run loop cycle ask for selected items, we prefer the clicked row, but this one might now no longer exist.
The view passed to the file manager is used to request the undo manager. The problem with using an NSTableCellView instance is that this view may be taken out of the view hierarchy (and thus responder chain) which makes it lose its undo manager.
This isn’t an immediate problem but if we later use undo/redo, it might be.
This way we only have to abort editing if the item being edited is going away.
View-based table views do not supported editedRow so this commit also change the way to figure out if a row is being edited.
Previously if we deleted an expanded folder it would select the first child of this item which would then be removed and leave nothing selected.
There are still a few edge-cases left though where what’s selected after deleting items is not ideal.
We previously did this when the background style was set to dark, but the code for this only works when the view is a direct descendent of the NSTableCellView and also, when a row is selected in an inactive table view, the background style is not set to dark.
The comparison is somewhat shallow, but ideally all changes to the actual items (rather than adding or removing items) is done by updating the properties of the existing instance. The exception here is the SCM Status data source, but FSItem’s isEqual: method does compare scmStatus.
One issue with the view-based version is that there seems to be no hook where we can update the text prior to edit, so in the SCM Status view where item names are disambiguated, editing the item will cause the disambiguated name to be used as basename.
The view-based version is also more eager to start editing rows, for example the “click a selected item to move focus to file browser” now also trigger renaming of that item, which is rather undesirable.
A few other pending issues also remain, like better rendering of labels, not adding a (hidden) close button to each row, and ensuring FSItem instances are re-used when possible (e.g. SCM data source).
The way we mark items as modified or open is also suboptimal, as it’s partly done via bindings and partly manual.
I’m not sure if it is necessary to manually refocus the outline view after aborting the field editor, does seem like a bug and will most likely not be present for view-based outline views.
