I've gone back, taken a good look in the mirror and thought long and hard about what it is that I am trying to accomplish and I have returned, I feel, better equipped to articulate it. I'll bullet this so it's perhaps easier to comprehend.
• I want to be able to paste Final Cut Pro effects into Final Cut Pro without having to rely on a a named clipboard that does not sync.
I am running into the following problem.
• Currently, I have no way of determining what the data that makes up a Final Cut Pro effect is.
• Should I get access to the data that's pasted into Final Cut Pro then I assume it would be trivial to include that data in a macro.
A clipboard is made up of a set of flavors, each flavor having an ID and data (technically, a clipboard can actually mbe made up of a set of items, but this rarely happens and isn't applicable in this case).
Some of the flavors have public IDs (like com.apple.traditional-mac-plain-text), others are proprietary (like com.stairways.keyboardmaestro.actionarray). Some may contain data that is useful long term, but some might contain transient data that is only valid now and might not be valid if you copy something else, or quit and relaunch the application.
So the first step is verifying the the clipboard can be saved - copy the effect into a Named Clipboard, quit Final Cut Pro, copy something else, relaunch Final Cut Pro and verify that you can now paste from the Named Clipboard. If you can, then the clipboard can probably be safely saved and reloaded, and perhaps sent to the other Mac.
But then we get to the hard part, there isn't any real way to “save” a clipboard and all its flavors to a file that could be transferred. There is probably some way, but I don't know how, maybe with AppleScript, take the flavors apart and save the relevant parts?
Not necessarily, the Write to a File action will only write files in a variety of formats (images or text). What is really needed is a way to write all the flavors of the clipboard to a file and then restore them (as Keyboard Maestro does internally when storing the clipboard history or the named clipboards).
Yes, I understand the point about multiple flavours, so I was probably unclear when I used the term "arbitrary data". I'll put my question another way, and then give a provisional answer myself, since I have run more tests now!
Saving and reading data of an unknown format
Q: If data from an application is copied to the clipboard, and there is only one flavour, and it is not a format that KM has been designed to handle, can KM save that raw data to a file and then read that data from the file?
A: No. The log indicates "Write File action failed to read source text in macro..."
Q: "it would have to deal with both multiple items and multiple flavors". I understand about the flavours, but what do you mean by multiple items?
Where I was coming from with this
For one of my macros, I relied upon all but one flavour being lost when copying the clipboard to a file. This was a macro that saved to a file any image copied from the Web and then read the image back into the clipboard from the file. That ensured that attempting to then paste the image into any app would actually paste the image, and not the URL of the image, which was the flavour that some applications decided to use.
(I replaced that macro when I worked out a simpler method that did not involve files).
I hoped that a similar scheme might work with FCP.
Why my proposed experimental solution would not work
It turns out that KM cannot dump the clipboard for just any kind of data.
That the required flavour would be the first in the list of flavours was only a hope.
That the other flavours would not be required by FCP was also only a hope.
I don't know, but I suspect that FCP would not copy the full data but would instead copy some sort of reference to that data – in which case, even if KM were able to save and read the format between clipboard and file, reading from the file on another computer would likely fail.
I suspect that, when pasting, FCP would read from an internal clipboard of its own, and ignore the System clipboard.
Keyboard Maestro can only write the files out in the specified formats, which are all images or various textish documents. You cannot write a file in an arbitrary format from one or more unknown flavors.
A single clipboard can include multiple items. This happens rarely (and generally badly). About the only relatively common case is selecting multiple files in the Finder and copying them.
Yes, I've used the same technique. And indeed, Keyboard Maestro’s clipboard history has an explicit action to Set Clipboard to Image in the gear menu for such purposes to disambiguate when a clipboard might have an image and other data such as text or URLs or file references.
Yes, all those conclusions sound either valid or plausible.
Number 1 is definitely true.
Number 2 doesn't really make sense as flavors aren't really ordered.
My current method in a macro is to use Composite Clipboard onto Image – back onto the clipboard!
I did wonder if I might be corrected. I was going by the following sentence from the Apple Pasteboard Programming Guide – without having too much confidence that flavors and representations were actually the same thing.
Rather than requiring an item to provide all of the representations it offers, a pasteboard only asks for the first representation in the list of representations an item offers.
I just found the Clipboard Viewer app while searching for a similar sort of problem. That might help you identify something in the clipboard that you can then query in an If Then Else action using The Clipboard: System Clipboard conforms to and entering the public or private UTI (see Apple Uniform Type Identifiers) type name for one of the ones listed in General Clipboard for the copied effects data to at least filter out anything except the type of clipboard data you want to process.
As to how to save and paste later, this post might have some helpful info on using the Clipboard History Switcher or named clipboards to save the data.
But as for saving to/restoring from a file, especially when dealing with data from a third party app, that would be a lot trickier and more error prone.