The warning only appears when the anonymous enum is used in a conditional, hence why we do not need this change for all calls to NSFileTypeForHFSTypeCode.
Previously we would download and archive the default bundles as part of ./configure and place the result in our source directory, this however both pollutes the source directory with generated files, but also had the ./configure step actually do a partial build, since we need to build the ‘bl’ executable to download bundles.
For bundle items we have to decorate the menu items ourselves with shortcut keys and tab triggers, which were previously rendered with the system text color, but starting with Big Sur, it appears to use the tertiary label color, which we now match.
Setting this flag means the content view spans the full window size, thus is rendered “behind” the window chrome, which is how we have designed these windows, which hold a scroll view as the main content.
However, starting with macOS 10.16 (Big Sur) the scroll view doesn’t automatically set the top inset to adjust for the title bar (and auxiliary view), at least it has not yet been set, when we adjust the bottom inset, and disable further (automatic) changes of the scroll view insets.
By not setting the full size flag, the content view’s size is limited to the “visible are” of the window, but there seems to be some special detection of full size scroll views, so this one still gets the “full size” effect with content behind window chrome.
Since we bind the disabled state of the “Check Now” button (in preferences) to this property, we cannot update the property in a background thread, as the UI can only be updated from the main thread.
The extension is converted to from ‘vstrings’ to ‘strings’ and it is saved as UTF-16. Ideally this would not introduce a new extension (and rely on the existing ‘strings’ filter to convert to UTF-16), but see previous commit for the technical limitation preventing this.
TARGET_NAME and YEAR are predefined variables.
This relates to the build system: Transformations that does not change file name are called filters, this could e.g. be converting UTF-8 to UTF-16 or converting a property list to binary representation (without changing extension).
This currently works when the filter is applied to a file in the source directory, as we write the result to the build directory, but if the input is already in the build directory, we would create a new output with the same path, which would result in a malformed build file (multiple targets generate the same file and/or cycles in the dependency graph).
As a workaround, we only allow filters to be applied to files in the source directory. But it would be nice to lift this limitation.
These variables are passed as arguments to commands that go through a shell interpreter, therefore spaces would be a problem.
Previously we expected the variables themselves to include proper escaping (or quotes), but that is problematic if they are set in build.ninja, as we recreate this file via a rule that passes all variables as arguments, and this rule already uses single quotes for escaping, so it would cause a problem, if the variables contains single quotes.
Use int64_t instead of NSUInteger, check against NSURLSessionTransferSizeUnknown, and ensure that completedUnitCount is the last thing we set on the NSProgress object, so that there is no potential race condition with a progress object being completed, but still having a non-zero estimated time remaining value.
We already setup proper line break mode for the strings displayed (via paragraph attributes), but having good defaults makes sense, so subclasses can forego setting it.
We want to preserve the existing file’s metadata, although we manually take steps to do so, but no reason to disable the system’s functionality for this.
This is useful when working with one set of files in a project, then moving to another set without closing the original set first.
Alternate menu items are pretty subtle, but there are already a lot of ways to close tabs, and I didn't want to clutter the menu further.
Normally a selection done via search or double-click will be unanchored, so that the first use of shift-left/right will always extend the selection, as opposed to a selection done with keyboard, where shift-left/right moves the ending of the selection.
This produces a warning with latest Xcode, stating that it produces a copy, as the variable is already const. This does seem a little strange, so it could be a problem with the analyzer, but not marking these variables const shouldn’t affect anything.
We only set underline and strikethrough when those are enabled, and use applyFontTraits:range: instead of explicitly setting the font.
The latter should avoid breaking font substitution, although to be safe, we still call fixFontAttributeInRange:.
I have not found it advantageous to get multiple carets when pasting search results, on the contrary, if we have a significant number of results, the multiple carets may impact performance.
This reverts the change that was made in 82593c8824.
This problem started after f1a1e1920f (handling key equivalents in performKeyEquivalent: instead of keyDown:).
It does however not appear that it is necessary to manually handle the return key to activate editing, therefore we have removed handling of this key.
Most likely it was required before view-based table views.
Some of the items require the key equivalent to be set as “inactive” as menu item keys are “global” and thus need to be unique, and can be triggered even when the view containing the context menu is not active.
Previously “Paste Next” in the Edit → Paste submenu could have its title updated to “Move Item Here”, which would never be restored back to “Paste Next”, similarly for regular paste.
This commit also drops the wrappers for the cut:, copy:, paste:, and delete: methods, as these wrappers resulted in a bit of redundancy related to menu item validation.
This is called before the main menu acts on keys, and thus allows us to catch keys that are otherwise assigned to menu items.
We only do this when the file browser is first responder, so it should be acceptable to have a few menu keys change behavior in that case.
