This watches the Desktop for newly created screen snapshots and when it sees one, it prompts you to provide a name for it. This includes a construct for applying a DPI change to the image so that it ends up with the dimensions I expect when I open it in Preview. I implemented that because I use a custom screen resolution that can adversely affect the default display size of screen snapshots. If you want to try the macro without that change, disable the last three actions.
It does commandeer your clipboard, so I may need to find a workaround for that.
(This issue has been fixed in the recent version.)
I've tested with .png and .jpg, please let me know if you find other image formats or any other things that make it fail. I use it with macOS 15.3.1 on an M1 MacBook Pro.
I also found another caveat. The AppleScript requires a new name if another file on the desktop already has the file name entered. However, the macro doesn't wait for the new name, and creates an unreadable file called "OK". That's going to take me some time to investigate. It's related to my knowledge of KM rather than that of AppleScript. Anyway, another reason to use Griffman's, which I can also accommodate to work for my non-standard screen resolution, I think. Thanks.
(note: this problem is fixed in the version I'm uploading today.)
Always be careful deleting the clipboard as there are reasons that Keyboard Maestro does not generally restore the clipboard.
However in this case the better solution is to use a Named Clipboard (eg one named "Temporary").
Read the image in to the Named Clipboard, operate on the Named Clipboard, and then write the Named Clipboard out - no need to use the System Clipboard at all.
I'm on the way to a solution that will still incorporate the AppleScript. I've discovered some useless junk in the script that was left from long ago. Making those changes will also provide most of the fixing needed, I believe, but I'll also try using the Named Clipboard instead of the System Clipboard. That will work if and only if the Named Clipboard will hold the snapshot image.
OK, I've fixed the AppleScript and changed the macro so that the System Clipboard is never used (whether or not you include the three image editing actions near the end of the macro). Thanks.
From my understanding it is not possible to bypass the system clipboard so even if you copy straight to a clipboard it will still go to the system clipboard and will require the delete last clipboard with a value of 0 because it is the current clipboard and 1 would be one past clipboard.
Thanks. Yes, I'm reading the renamed screen snapshot file into the clipboard to apply the DPI change (4th action from the end). I did test, and the System Clipboard prior to using the macro does remain intact. I forgot to show the entire actions for the image manipulation at the end before I uploaded it, so here it is:
That is true if you use Cut/Copy to acquire the information. In that case, the data goes through the system clipboard and that cannot be avoided.
In this case, the OP was reading a file into a clipboard, processing that clipboard and writing the file out, all using Keyboard Maestro actions that can work with Named Clipboards, so it never touches the System Clipboard.
Okay good to know I didn't realize that was possible from what I read in a post years ago (not sure I could even find it).
So if I use Copy to Named Clipboard to go straight there it still goes to the system clipboard but if you read a file then you can go straight to a Keyboard Maestro clipboard without going through the system clipboard. Are there other exceptions to that?
If you are accessing data in any application, then the only universal reliable way to get it is by Edit➤Copy ⌘C (or Cut, obviously). If you do that, then the system clipboard is used.
If you are inserting data into any application, then the only universal reliable way to put it is by Edit➤Paste ⌘V and the data must be in the system clipboard to do that.
Using Named Clipboards is not necessarily that. For example, you can use the Copy Clipboard to Clipboard action to copy between named clipboards (or to copy from the existing system clipboard) without affecting the system clipboard.
Basically, the system clipboard is the interface between an application and the rest of the world as far as copy and pasting goes, and anything that does copy or paste uses that single system clipboard.
But nothing else does unless it explicitly says the system clipboard is the destination.
OK, that actually makes way more sense to me now I was always a bit confused why you couldn't just put things in clipboards. Thank you for the further clarification on this applications depend on the system clipboard because they are programmed into the application to do that and not necessarily from some other application. That's why you'd otherwise have to do "typed" instead of paste for some paste actions in macros. Thank you for taking the time to explain that, this is going into my book of notes and reference on copy and paste.
