Although one of the new API methods is deprecated starting with macOS 10.15, but that change is minor, and the replacement wasn’t introduced before macOS 10.15.
If full keyboard navigation is disabled (default) and “Accept rmate connections” is also disabled, no control in the on the preference pane would have keyboard focus, meaning that the view controller (implementing action methods for the pop-up and install/uninstall button) would not be in the responder chain (since first responder would be the window, which is after the view controller in the responder chain).
It now matches the width of the other preference panes, so the preferences window will only change height when changing preferences panes (unless the user has manually resized any of the resizable preference panes).
The goal is to have the window resize as little as possible when switching to another preference pane, therefore we aim for at least making the width the same for all panes.
The MGScopeBar class uses deprecated API, doesn’t support dark mode, and doesn’t seem to be maintained, therefore it’s better to switch to OakScopeBarViewController, although it doesn’t support “collapsing” into a pop-up menu.
This commit does change the category filter to work as a radio button, so if one category is selected, others will be deselected, which I do think makes more sense than the previous behavior of allowing multiple categories to be selected, and using the union of these when filtering.
This commit also retires the xib file. The long-term goal is to eliminate all xib files, as being explicit (in code) is preferred. The xib files only exist because in the past we did not have auto-layout.
Ideally this would be a view property, but the view controller only expose the content view, which is an NSView instance that does not support the property by default, so we would have to introduce a subclass for this.
This fixes problems with symbolic links, for example file browser may show contents of /private/tmp when we ask to select /tmp/foo.txt. Comparing file path URLs will fail even though /tmp is a symbolic link for /private/tmp.
Note that this fix only works for when the current document is already part of the items in the file browser, as we still store pending URLs to select as file path URLs.
This is for multi-selecting items in the pasteboard chooser and they are stored as auto-generated items and with their history identifiers, so that we can treat them as multiple items.
Previously we stored discontinuous selections as a newline-delimited string, and therefore the individual fragments could not contain any newlines.
Now that we use NSPasteboard’s multi-string support, we no longer have this limitation.
I was using the clipboard history as a testbed for CoreData but my conclusion is that it was not a good fit, and with the API we used now being deprecated, and the clipboard history needing various improvements, it’s easier just to replace the CoreData backend with sqlite3 and offers us more flexibility going forward.
With this re-implementation there is now support for storing multiple strings on the clipboard and the check to see if other applications changed the clipboard should work better (it appears that if an application is changing the clipboard while TextMate is active, sometimes the NSPasteboard’s changeCount is not updated).
It now also stores the history item’s row ID on the pasteboard, so if we select the non-latest history item and relaunch TextMate, it will no longer treat the current item on the pasteboard as a new item.
Incase of a file reference URL, moving an item will have the URL resolve to the new file path, therefore such URL cannot be used for storing the old location/path of the item.
This is currently not a problem with TextMate, as all URLs are file path URLs, but as we are moving to using readObjectsForClasses: with NSURL, we will be receiving file reference URLs from Finder.
Terminal.app is peculiar about what it expects to be on the clipboard. If we only write URLs like this:
[pboard clearContents];
[pboard writeObjects:urls];
Then it will not paste anything. There *must* be string fallbacks for it to support paste. But if we also write an array of strings like this:
[pboard clearContents];
[pboard writeObjects:urls];
[pboard writeObjects:[urls valueForKeyPath:@"path.lastPathComponent"]];
Then it will paste both the URLs and the strings, but where the URLs will be space-separated, the strings will not. If instead we write a single string fallback only for the first item, like this:
[pboard clearContents];
[pboard writeObjects:urls];
[pboard setString:@"whatever" forType:NSPasteboardTypeString];
Then it will paste the URLs and ignore the string fallback for the first URL.
