We now write what the actions will apply to. This isn’t done for all actions, which is somewhat consistent with Finder, though I don’t know why Finder doesn’t include such description for all items, perhaps it’s seen as redundant to state for every action (and just adds noise), so only items where user could be “confused” should explicitly state what they work on.
All of these will always have the same badge, so there’s no reason to show it (and it covers the alias badge, so there is some usability benefits beyond just the visuals).
- Accept two NSGradient objects instead of four colors.
- Call designated initializer on super instead of self since subclass is likely calling us from its designated initializer
- Make class public
Previously we kept the children which had been expanded, as these had an associated record for tracking file system changes and SCM info.
However, when expanding we weren’t actually re-using the item from the cached record, so not only was this wasteful, but it caused a problem because we effectively created a new item but used the old record with the old item, and while the two items would compare is equal when using isEqualTo:, they didn’t have the same memory address, so the outline view would not consider them equal, and would thus not react on reload requests when using the older item.
This is only to ensure everyone goes through the class method, which is easier to search for (constructing an FSItem from a URL is a little expensive so we wish to get rid of it where possible).
Also change SCM implementation so that it doesn’t use objects with automatic storage, as the objects may be accessed from threads, which may run after objects with automatic storage has been destroyed.
With focus in the file browser this menu item can now be used to toggle wether or not the include/exclude patterns should be ignored (causing everything to be shown, when ignored).
The ideal behavior would account for “nesting”, i.e. we should prefer to select an item from the same folder which we deleted from. Though Finder uses a similarly “naive” selection preservation algorithm.
Closes#717.
The URL constant for the favorites location was setup using oak::application_support() but done before the app support folder was initialized (due to the setup function being marked as a constructor).
Previously these would not initially be expanded but the expansion state remembered. Now that we regularly clear cache of expanded URLs, it’s more tedious regularly having to expand these two groups.
It also introduce new API for having data sources return what items should be initially expanded, which probably makes sense for some data sources.
We probably should only drop expanded folders which descend from the current root, but that’s more code and the implemented behavior could be seen as “garbage collection” (keeping the memory of expanded folders low).
Any file should be able to be opened within TextMate, so
Option-DblClick will always do that. I first noticed this with .xib
files.
Because of the order of the if statements, opening an alias to a
package or binary file (or .xib) would not have the previous if
statements applied to it.
Given constraint-based layouts, we’re more likely to create views in code, and as helper functions are often involved, it makes sense to name them so that we can quickly get a list of all helpers (via search), either for copy/paste or for evaluating wether or not it makes sense to move all helpers to a single library.
Since helpers are declared with static storage, they do not pollute the global namespace.
