Previously we fetched items row-by-row from the database, which could be slow even with only 500 entries.
We now fetch everything using a single query. Long-term though we may fetch the strings on-demand but with some prefetch, mainly just to avoid an issue if the user store hundred of megabytes in the clipboard history.
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.
