Many of the features we take for granted in macOS today have long histories. For the last week I’ve been looking at drag and drop using the Finder’s clipping files. Thanks to comments by theam27 and joethewalrus, we know this goes back over thirty years to the heady days of System 7. Before that, transfer of information between apps relied on the even older mechanism of copy and paste, one of the original features of the Mac in 1984.
Since System 7 Pro (7.1.1) and more generally in System 7.5 in September 1994, we’ve been able to drag text and other contents from open documents and drop them into the Finder to save them in a clipping file. That in turn can be dropped into a document to insert its contents there. It became highly popular in subsequent years, and different types of clippings proliferated. theam27 has identified four general types, with a further ten for internet location clippings.
Clipping files have proved long-term survivors. In Classic Mac OS their data was stored as resources in the resource fork of a file with an empty data fork. That survived the transition to Mac OS X, where it eventually became the com.apple.ResourceFork extended attribute. Since around 2015 clippings have also been written to the file’s main data as a binary property list. Although those changes have orphaned some old clipping files, drag, drop and clippings are still flourishing in macOS Tahoe, where the Finder supports them as well as ever. There’s excellent support built into SwiftUI as well as traditional AppKit APIs. Those are of course also required for drag and drop more generally, in addition to the Finder’s clipping files.
Sequoia and Tahoe now offer at least two types of general clippings, in textClipping and pictClipping, and two internet location types webloc and mailloc. My first task was to discover their structure, which I reported here for both resource and data formats. Although Apple has long since retired its Carbon API support for accessing what were formerly resource forks, opening up property list data is relatively straightforward, and the goal of my new app Disclipper, coming tomorrow.
Although similar to copy and paste, and often implemented alongside them, drag and drop works separately. For content in a document to be draggable, the app has to declare it so, and provide its data in one or more transferable formats. Those are generally standard representations, such as UTF-8 text, although an app can also use its own formats. Each is labelled with its UTI, to enable the drop destination app to know how to handle them.
The user selects the content they wish to drag, then drags and drops it onto the Desktop or inside a location in a Finder window. The textClipping or pictClipping is then assembled from all the transferable formats, and built into a binary property list (as well as a com.apple.ResourceFork extended attribute). The key for each of those is the UTI of the transfer format, with the content as its value, normally as either a String for text, or Data.
For example, when you drag rich text from my editor DelightEd, the textClipping file generated by the Finder contains its data represented as:
public.utf8-plain-text, the content as a UTF-8 stringpublic.utf16-plain-textandpublic.utf16-external-plain-text, two variants of UTF-16 as Datacom.apple.traditional-mac-plain-text, an old predecessor to UTF-8, probably Mac OS Roman, based on extended ASCII, but often truncatedpublic.rtf, the content as rich text, thus containing font and other styling information.
The Finder then uses those to provide previews and, in the case of plain and rich text, its own reader window.
When you drag that textClipping into another document to paste its contents there, the receiver app is given the choice of transferable formats from the file, and should pick the richest of those to convert into its own content and insert into the document. You can check the fidelity of the process in an app with both drag and drop support by dragging a textClipping from it, then dropping that back into a new empty document, and comparing that with the original.
Other types of content use different clipping files, with further references to the history of macOS. Select an area from a PNG image in GraphicConverter and drag it out to turn it into a clipping with the extension .pictClipping and both its com.apple.ResourceFork xattr and data fork contain complete PICT and TIFF versions of the original image. In the data fork, the latter appear as the values for the UTI-Data key, under the UTI keys of com.apple.pict and public.tiff. PICT is a long-dead graphics file format for Classic Mac OS QuickDraw graphics, but lives on in clippings and apps like GraphicConverter.
The receiver app decides which format to accept from the clipping file. Create a textClipping from a webpage in Safari, and it should contain representations of that page as a WebArchive and rich text in an RTFD, but drop that into TextEdit and it will probably choose the latter. You don’t get the option to use the WebArchive format. Disclipper changes that by saving the WebArchive version for you to use when you wish.
One type of view that currently doesn’t appear to be supported by textClipping or pictClipping files is PDF, perhaps because its format isn’t really suitable for this approach to its content.
Apple’s SF Symbols app is another interesting example, as its textClippings use private Unicode code points that are rendered as custom icons only when using one of the SF fonts normally only installed by developers. Those can substitute for what might otherwise be displayed using vector graphics.
If you already use clipping files, you should find Disclipper handy; if you don’t use them yet, they could be a fine New Year’s resolution.
The Eclectic Light Company 