When building on macOS 10.15, the split view will show the NSBrowser split as collapsed and not allow the user to resize it, though only when running the build on macOS 10.14 or earlier.
The problem has disappeared. I have no idea what changed, though I did not notice the issue until 2-3 weeks ago, and the problem disappeared around the time of last macOS security update, though comparing my machine’s uptime with the time of the commit being reverted, there has been no reboot since that commit.
This reverts commit f74aa3fde8.
We add a border to the NSTextField in Dark Mode to match the system tool tips, but it appears that the frame returned by “fittingSize” does not take that into account, so it returns a frame 1-2 points too small to fit the text, resulting in the last line missing.
This appears to be a fairly new problem, so might depend on the SDK that we link with.
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.
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.
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.
