Using a Folder Trigger to Prompt Renaming and Moving New Screenshots

Questions & Suggestions
1

Hi!

I'm trying to create a macro that is triggered by a screenshot being added to the Desktop. When this happens, the macro is supposed to ask me for the new name of the file, rename it, move it to a new destination (always the same) and copy the new path of the file to the clipboard.

I did what you can see below and it doesn't fully work: the user prompt shows up twice when a new screenshot is added to the Desktop. The KM log shows that actually the whole macro is triggered twice at almost the same time. I therefore changed the option "ignore partial files" to "ignore partial or changing files". This solves the problem in that the macro is just triggered once, but it creates a new problem: it takes ages (about 8 seconds) until the macro is activated after the file is actually visible on the desktop. This is too long for me to wait in the situations in which I want to use the macro. Any idea how this problem can be solved?

image
image1066×6958 882 KB

2

Hi Vinho,

Perhaps a semaphore lock might help?

1 Like
3

Thanks for the suggestion, didn't know about semaphore locks before! I tried leaving "Ignore partial files" (because of the problem with the long timespan) and added a semaphore lock with a very short timeout. The result: The first macro activated remains the only one, so that's good. But: The screenshot file that activated this first macro is a changing file, so it has a "." at the beginning of its filename which is part of the variable TriggerValue that the macro uses. The macro can then later not find the screenshot file that is supposed to be renamed and moved, because in the meantime the changing file has disappeared from the Desktop and the file that is present doesn't have a "." at the beginning of its filename anymore.
What I had to do is change the macro to use a substring of TriggerValue that gets rid of the "." – it works now but doesn't feel very elegant.
A more elegant way would be to cancel the first macro that is activated by the screenshot being added to the Desktop (still changing file) instead of the second one. But I don't know if there's a way to do that...

4

what about:

3 Likes
5

I wasn't aware of the "Cancel This Macro" actions – that's a great idea! Needed to choose "contains /." as the If-condition, though, because TriggerValue is the whole file path which doesn't start with a dot.

Thanks a lot!

1 Like
6

Years it took me to read this correctly. Thanks.

2 Likes
7

Was anyone else using this until recently, when stopped working? For the trigger text that includes "Screen Snapshot" instead of ".Screen Snapshot" as the beginning of the screen snapshot's default name (the trigger that doesn't result in canceling the macro), I'm now getting warned that the file can't be found (error 43). Here's what that file name that is returned by KM's system attribute "KMINSTANCE" looks like when I paste it into a BBEdit window:

image

Until I can find out why the new snapshot's actual file name doesn't match what is being passed by the "KMINSTANCE" attribute in KM, I'm probably going to have to revert to the common way of renaming a screen snapshot on the desktop that I haven't used for about a quarter century in the classic mac OS. Before KM, I used folder actions. I don't know if I can get folder actions working under macOS 15.3.1 or not. Thanks.

8

The problem appears to be that I'm no longer getting expected results from this AppleScript construct. The displayed dialog is now empty, and I was depending on the text that previously would have been saved there.

set kmInst to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine"
	set myfile to getvariable "local_DesktopScreenSnap" instance kmInst
end tell

tell me to display dialog (myfile as text)

Does it work for you? Has something changed that you can let me know about?

My macro runs it immediately upon snapping a screen snapshot, but I can run it manually within 3 seconds of snapping the screen snapshot. It's also no longer possible to press return to complete the fresh screen snapshot's disposition (making it appear on the desktop) after pressing (⌘⇧3). Rather, I have to click the preview and click "Done" in the ensuing dialog.
Thanks.

9

Please upload your actual Macro. Otherwise we will have to guess at recreating it.

10

I'm having trouble understanding why an AppleScript is required at all, and how it would overcome the delay.

As a test, I wrote a very simple macro that just triggers on change in the Desktop (where I set screenshots to save), then displays that %TriggerValue%. This macro is still triggering twice, so there are two files created, as before:

image
image1046×366 55.3 KB

However, this macro takes about six seconds to run, so I don't see any way (AppleScript or not) you're going to get around this delay. To make sure the delay isn't something introduced by Keyboard Maestro, I ran this in Terminal before I started the macro:

while true; do
while> ls *Screenshot*
while> sleep 0.5
while> done

The output while running the macro:

zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
zsh: no matches found: *Screenshot*
Screenshot 2025-02-13 at 5.02.49 AM.png
Screenshot 2025-02-13 at 5.02.49 AM.png

I ran the macro very soon after starting the little shell script, but even if you call it a second delay, you can see there was quite a bit of time before the file showed up.

Then I disabled the macro, so that only the OS was involved, and the results were identical: There's a long delay before the file shows up. So—AppleScript or no AppleScript—I don't see how this is ever going to run instantly, in terms of letting you very quickly rename a saved screenshot. The delay is at the OS level, not at the Keyboard Maestro level.

Some more testing indicates that the macro isn't even triggered until the small thumbnail of the screenshot vanishes. Only then does the macro kick off, so you can't even put up a "Processing screenshot" message as soon as you trigger the screenshot.

Writing a macro that renames the final file on the Desktop isn't difficult, but I don't see any way to overcome the delay, given it's happening at the OS level. At least not using the folder watching method. I think I can do it another way, though, so I'll post that soon, but do so in a new thread (as it's a different approach completely).

-rob.

11

And here's my take on a super-fast capture-and-rename tool:

-rob.

12

I assumed the "local_DesktopScreenSnap" variable was some sort of constant for KM. What actually happened was that, apparently through an unobserved, unintentional cursor drag, I moved the macro that set the variable to a position that caused it to occur after the script that used it. How fast can an unintentional drag occur in Keyboard Maestro? Apparently fast enough that I didn't see it, and to cause failure for a frequently used macro. I'll definitely be looking for the embarassment emoji to use as a label for my responses in this topic. Apologies, and thanks! I'll still be trying your solution, griffman!

1 Like