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 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.
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.
The reason we were doing a fetch was because it may provide better performance, furthermore, the count returned by the array controller is count of filtered objects, so this change is a slight regression, should be addressed later.
By implementing this, we avoid potentially updating the menu when pressing “menu keys”, which can be slow due to collecting information about system applications, such as supported file types, icon, and display name.
This would happen when opening the menu via the file browser’s action menu, and then using arrow keys in the text view. On my setup, moving the insertion point was slowed down noticeably.
We now do all the work in NSMenuItem’s setActivationString: and no longer require subclassing the mutable versions of NSAttributedString.
It should now be more transparent what the code does and why it does it.
Starting with macOS 10.15 the system will use new NSAttributedString API to obtain bounding rect, so we need to (also) overload this to return our fixed bounding rectangle.
The issue appears to be that accessing the clipboard, as part of setting up a normal document window, will stall when trying to connect to the system’s clipboard server.
Here’s the relevant stack trace:
-[OakPasteboard checkForExternalPasteboardChanges]
-[NSPasteboard stringForType:]
-[NSPasteboard _dataForType:securityScoped:]
-[NSPasteboard _dataForType:index:usesPboardTypes:combinesItems:securityScoped:]
-[NSPasteboard _dataWithoutConversionForTypeIdentifier:securityScoped:]
CFPasteboardCopyData (in CoreFoundation)
___onqueue_CFPasteboardRequestDataFromDaemon_block_invoke.341
usleep (in libsystem_c.dylib)
nanosleep (in libsystem_c.dylib)
__semwait_signal (in libsystem_kernel.dylib)
This was done using search and replace. Presumably it should be done in Xcode so that it can adjust the xib for the new deployment target, otherwise what is the point of storing deployment version in the xib and provide it as a command line argument to the xib compiler as well (only to get a warning if the versions do not match)?
This was because our windowWillClose: delegate method was never called, as our object was no longer a window delegate, an issue introduced in 709570049f when the superclass was changed to NSWindowController and I erroneously assumed that the superclass would set itself as delegate.
Since we have multiple application targets, it doesn’t make sense with a global APP_NAME variable.
Though if building the frameworks as standalone bundles and embedding them in different applications, we may need some sort of unique component in the bundle identifier, but we currently do not do this (they are all statically linked, so the Info.plist is currently unused).
The button created on 10.12 or 10.13 has a “Button” label next to it when used in table views (as used in the Find in Project results and Commit sheet).
See https://lists.macromates.com/textmate/2019-January/040883.html.
The issue is caused by commit f850dbdbc7, which added support for font style changes. It did so by applying a single font across the entire string. But, in some cases not all characters (e.g., Chinese or Japanese characters) may be available for that font so these characters would not be rendered correctly while editing.
It appears to be ignored on 10.14 but earlier versions of macOS rendered the elements with a shadow, which is probably not a good fit for our current design.
Semantically this seems slightly more appropriate, and giving a range allows us to pass the strings length as the length of the range, instead of assuming that the string has a first character for which we can get attributes, although for an empty string, passing in a zero-length range *does* throw an exception, so we must only call this when we know the string is non-empty.
