This allows us to use the same key for more than just directories. The notification name itself should indicate if the ‘path’ refers only to directories or files.
This mainly relates to the folder pop-up. By delaying creation of this menu till the user actually opens it, we avoid/delay having to create potentially expensive icons (icons are “expensive” since creating one may cause TextMate to hit the disk).
We use ⌘[ and ⌘] which is also used for Text → Shift Left/Right so we only set these keys for when the main text view is not active.
The main advantage is that you can now use these keys to move back and forth in history of HTML views (it also works in file browser, but due to a custom keyDown: overload, it also worked prior to this commit).
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).
