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).
This is instead of placing it relative to the entire window. The main motivation is that with the file browser on the right, I want the file chooser closer to the left edge of the window.
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.
These would previously be prefixed with the project folder path. Now they get no prefix (and disappear when the path-part of the filter string is non-empty).
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.
For aesthetic reasons the focus ring is disabled as there is no other control that can be active, however this is not the case with full keyboard access enabled as you can tab through the scope bar as well.
The UUID is a unique reference to a document that trumps the path. However, as we don’t actually keep the documents in the file chooser, we end up with UUIDs from documents that does not exist, and should a new document be created for the same path, it will get another UUID.
This was broken by 645f8d91e1.
The issue is that if the user press a key not in our managed menu, then the menu delegate will no longer be asked to update the menu for keys not in this (cached) menu.
Example: If there are items for ⌘1-3 in the menu and the user press ⌥⌘N a few times (to create more tabs), then the delegate is asked to update the menu on the first press, but as ⌥⌘N is not in the menu, successive events will not cause the menu to be updated. If the user then press ⌘5 (to go to the 5’th tab), nothing will happen, because our menu only holds 3 items, and the delegate is not asked to update the menu.
- Remove focus ring from search field as there is no second target.
- Set top and bottom border widths for the textured window.
- Remove miniaturize and zoom buttons for lack of utility.
- Match name of window to menu command.
- Various color and spacing tweaks.
Since styles_for_scope effectively ignore the font parameters (and instead return styles based on the font parameters used when the cache entry was created) it is a better design to have theme_t own the font. This way, changing it can do the proper cache invalidation.
A minor downside is that we can now change the font of the theme without also changing the layout’s font, which wouldn’t cause proper layout invalidation — since layout_t owns theme_t though, users of a layout should always change font via layout_t (which will then change it in the theme).
Also, themes cannot be shared between views that wish to use different font settings.
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.
Font name and font size was being used in the cache key as a way to avoid having to do cache invalidation. This comes at a price of a 3X slow down. Instead clear the cache when font size/name changes. Excessive font name/size switching should be deterred IMO, why not with slowdowns? so no real downside. This does not affect themes setting font name/size, as they are handled by another mechanism.
This is to be used with file actions done from the UI: Actions are undoable, proper dialogs will be shown for errors or to confirm permanent deletes on volumes without a trashcan (closes#589). Interface sounds will also be played (when moving, trashing, and duplicating items).
I decided not to use the asynchronous file system methods that NSWorkspace offer. Mainly because they can only be used for the initial operation, not during replay, as performing asynchronous operations during replay may cause issues if user moves quickly between items (something that seems to be an actual problem for Finder). The problem though only exist as long as we rely on NSUndoManager to manage the process.
Presently there is no API for batch operations, which leads to suboptimal action titles when performing multiple file system operations in the same undo group.
