Since we create an attributed title when the menu item has a tab trigger or “inactive” key equivalent, we can’t later update the title via the title property.
The rendering doesn’t mimic the system 100%, for example the key equivalents are not centered on the split between modifiers and the key, nor are F-keys rendered using a smaller font / menu glyph.
On the plus side though, now all keys are rendered. Previously keys shared with other (non bundle) menu items would only be shown for one of the items sharing the key, and some keys would simply not be shown (e.g. ⌃#).
Also, bundle menu items no longer “eclipse” regular menu items, which could previously happen even when the bundle menu item wouldn’t fire (as it was scoped for something else than the current context).
Fixes#894.
This is important when we wish to select or edit the URL (in the file browser) as URLs with different values for this flag will not compare as equal, and URL objects created before there is a file on disk will always have this flag set to NO.
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 is to match the minimum allowed size for the sidebar header when the tabs above document is enabled, also matches the height of the forthcoming tab redesign.
- 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
NSFileManager only provide a move function which fails with “file exists” if we make case changes on a case-insensitive file system, therefor we now explicitly test for that error and use <x-man-page://2/rename> if the source and destination refer to the same file, but the path differ.
Fixes#769.
This is both to speedup file browser updates (as there is a bit of lag waiting for fs-events) and to work with file systems that doesn’t support fs-events (issue #745).
Since the created image is a “dumb” object that can’t provoke redrawing itself, we require that SCM info is already cached for the repository containing the file for which we are creating an image. If not, there will be no SCM badge, so most users of this API should setup their own SCM info and recreate the image when SCM status changes.
Previously we used our own icon image class which support SCM status, custom images for known file types, and more. This is however is unnecessary, as we know the Open With menu contains only applications, and each should use their standard icon.
This should also fix issue #510, although the issue was never diagnosed beyond git stalling while trying to get SCM status for the application icons in this menu.
Added .less files to the OakAppKit .plist bindings file as another grid icon, to go along with the existing .css, .sass and .scss definitions.
Signed-off-by: Bob Rockefeller <bob@bobrockefeller.com>
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.
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.
