[FILES] Move & Rename Screenshots to Screen Shots Folder

###MACRO: [FILES] Move Screenshots to Screen Shots Folder

~~~ VER: 2.2 2016-03-12 ~~~
####Download:
[FILES] Move Screenshots to Screen Shots Folder.kmmacros (35 KB)
####Added this AppleScript File you will need:
[KM] Check IF File or Folder Exists [AS].scpt.zip (4.9 KB)

You will need to modify the Action that uses this script to point to the location where you have stored it.
Execute ‘[KM] Check IF File or Folder Exists [AS].scpt’ AppleScript

My many thanks to @Tom for creating and sharing the original macro.
I started with @Tom's macro, and added to it:

~~~ VER: 2.2     2016-03-12 ~~~

Author:        Original Macro:  @Tom
                    Ver 2:                @JMichaelTX

PURPOSE:  Move & Rename Screen Shots Created by standard Mac OSX
                    screen shot tool (⌘⇧4)

VER 2.2 CHANGES:
  • Adds the Semaphore Action at the top of the script

VER 2.1 CHANGES:
  • Adds check for existing file
  • Adds choices for handling existing file
     • Rename
     • Replace
     • Append Date/Time
     • Append Time (Seconds())

VER 2.0 CHANGES:
  • Adds optional rename prompt
  • Adds delete option
  • Adds Variable for "Screen Shots" folder 
      (default:  ~/Screen Shots)
  • Adds option to open file in Preview

HOW TO USE:
  0. BEFORE first use:  Confirm/Change Folder for Screen Shots
      (see Set Variable "SS Folder")
  1. Just press the standard Mac OS X screenshot shortcut
  2. Macro is triggered by new files added to the ~/Desktop folder
  3. Will only process files that start with "Screen Shot"
  4. Accept default file name, or enter new name
  5. OR, DELETE the screen shot file.

REF:
  • KM Forum Topic "I use a little gem called “Folder Actions” "
  • Macro posted by @Tom:  "Move Screenshots.kmmacros"
  • https://forum.keyboardmaestro.com/t/i-use-a-little-gem-called-folder-actions/1966/6

USER SETTINGS:
  • Any Action in magenta color is designed to be changed by end-user
  • This macro uses Google Search and Google Chrome, but can be easily changed

ACTION COLOR CODES
  • To facilitate the reading, customizing, and maintenance of this macro,
      key Actions are colored as follows:
  • GREEN      -- Key Comments designed to highlight main sections of macro
  • MAGENTA -- Actions designed to be customized by user
  • YELLOW   -- Primary Actions (usually the main purpose of the macro)
  • ORANGE  -- Actions that permanently destroy Varibles or Clipboards

REQUIRES:  
(1)  Keyboard Maestro Ver 7.0.3+
(2)  Yosemite (10.10.5)+

2 Likes

Nice idea with the renaming and opening :slight_smile:

And … this macro has a very interesting problem :upside_down_face::

Does it work for you with small ⌘⇧4 (rectangle tool) screenshots?

For me it works only with relatively large screenshots or fullscreen screenshots. Somehow the inverse case of the original problem

What I get —with smaller screenshots— is this:

And file names like these:

(File Ext is empty.)

That means the value of %TriggerValue% doesn’t get copied to the SS Trigger Value variable at the beginning of the ‘If All…’ block.

A debug message, placed immediately after the declaration of SS Trigger Value, confirms this. And —at a first look— is seems to suggest that the %TriggerValue% token itself is fine:

However, the solution to the problem is to set this pause before the variable declaration:

This suggests that there is indeed a small time window where the %TriggerValue% token is empty(!)


Why?

I don’t get it why this happens only with small screenshots. Of course, it has do with the fact that the OS first writes a temporary dot file and then processes it to the final screenshot file.

That is, the macro gets rapidly triggered twice with every screenshot:

(The first one will be stopped in its tracks, because %TriggerValue% won’t pass the ^Screen Shot regex condition.)

The difference between a small and a large screenshot is that the latter needs more processing and writing time, that is, the time gap between the temporary file and the final file is shorter with small screenshots.

The only explication that comes to mind is that the first triggered macro hasn’t finished when the second one starts and therefore somehow interferes with the second one if this time gap is too short :face_with_head_bandage:

Tom

This is the sort of problem that is usually easily resolved with a Semaphore Lock action. Throw one of these at the front of the macro, and the macro will then execute to completion before the next instance is allowed to run. The first one will ignore the dot file because it does not have the right name.

Whether that is enough to resolve the problem, I don't know, I haven't looked at the macro in enough detail.

Yep, it works. And is more elegant than the ‘Pause Until…’ thingy.

Thanks for the hint, I was always wondering what this exactly is for :smile:

1 Like

@Tom, thanks for the testing and feedback.

Yes, ⌘⇧4 is working for me, but I'm already on an updated version.
All screenshot shortcuts are working for me. Tested on two Macs, but both Yosemite (10.10.5)

I think you are seeing an error I had originally in the RegEx for parsing the file name and ext. It should be:
(.+)\.(.+)$

I'll upload my revised macro shortly.

No, the regex is fine. (Otherwise it wouldn’t work with large screenshots.) It indeed needs the ‘Pause Until…’ or, better, the Semaphore Lock.

Possible that it’s different on Yosemite.

Just updated my original post above with Ver 2.1

@Tom, please test this version when you have a chance. I think it will fix all of the issues you reported.

Note that I did not have to add any of these:

  • Pause before the variable declaration
  • a Semaphore Lock action

However, I have not tested for doing another screen shot before you have finished the macro of the current screen shot. I don't know why that would every happen. As soon as you complete a screen shot, the macro immediately pops up.

But maybe I'm missing something.

However, I have not tested for doing another screen shot before you have finished the macro of the current screen shot. I don't know why that would every happen. As soon as you complete a screen shot, the macro immediately pops up.

But maybe I'm missing something.

Yes, you are :wink: It’s not the user who is making two subsequent screenshots, it’s the OS that is placing two files in the Desktop folder. The first one you don’t see. It’s the temporary dot file (see my post above and/or the screenshot here). This triggers the first run of the macro. You won’t see the user prompt, because the macro gets stopped at the ^Screenshot condition.

A little bit later (how much later depends on the size of the screenshot) the final file —without dot— appears on the Desktop. This triggers the macro again.

Run the macro in debugging mode (Keyboard Maestro Menu > Start Debugging) and you’ll see the two instances of the macro. Or remove the file name condition, and you’ll see two user prompts. If you don’t see it, than the whole thing is something new of El Capitan.

Note that I did not have to add any of these:

Pause before the variable declaration
a Semaphore Lock action

It seems your new version runs fine so far, even with small screenshots. But, as said, the whole thing seems to be a timing issue between the first and the second instance of the macro. Since you inverted the file name condition (!^Screenshot) in the new version you may have “accidentally” resolved the issue. But when the macro is run on a different machine (faster or slower CPU/disk) I wouldn’t bet that the issue won’t appear.

With the Semaphore Lock you are on the sure side, since it doesn’t let run the second instance unless the first one (the one from the dot file) has terminated.

Just updated original post with Ver 2.2.

This ADDs the semaphore that @peternlewis suggested to ensure that " the macro will then execute to completion before the next instance is allowed to run. The first one will ignore the dot file because it does not have the right name."

@Tom, thanks for making it clear that the macro needs the semaphore to always ensure proper execution. I had not seen any issues, but others could.

Please give the update a test when you have time and let me know how it goes.

Please give the update a test when you have time and let me know how it goes.

Technically it works flawlessly so far! Just an UI observation:

You can get rid of two superfluous dialog boxes:

  • Use Trash instead of Delete. This is (IMO) preferable anyway and for Trashing you don't need a confirmation dialog.
  • Put the Open button into the main prompt, no need for an extra dialog box.

Thanks. Please post if you find any issues.

I suppose the button label is a matter of preference. "Delete" is the action, and "Trash" is where it goes. IME, most apps use the word "Delete".

I could eliminate the Delete confirmation, but I have observed users sometimes accidently delete something, not even knowing they clicked on the Delete button. Then they are lost because they can't find their file. IMO, the confirmation is a minor nuisance that can help eliminate this confusion.

Maybe instead of another button for "Save & Open", another checkbox can be added for "Open in Preview".

Of course, the great thing about KM is that each user can take the macro and further modify it to their liking.

Thanks for the suggestions.

I suppose the button label is a matter of preference. "Delete" is the action, and "Trash" is where it goes. IME, most apps use the word "Delete".

No, I didn’t mean only the wording. Of course, you also have to change the action to ‘Trash’:

The Delete action deletes a file, the Trash action puts it into the Trash.

I could eliminate the Delete confirmation, but I have observed users sometimes accidently delete something, not even knowing they clicked on the Delete button.

That’s why I think Trash is better than Delete.

Maybe instead of another button for "Save & Open", another checkbox can be added for "Open in Preview".

These are two clicks. A Save & Open button is one click. And to the buttons you can assign hotkeys(!)

You can do it the same way as with a checkbox. You just have to save the Result Button variable to another variable (e.g. Result Button 1) for later reference, because you have the Rename prompt in between.

But either way is better than a second dialog.

the great thing about KM is that each user can take the macro and further modify it to their liking.

Of course. Already done :smile: I just proposed these changes because they have advantages for every use case (not just mine). I think nobody likes to click through confirmation dialogs, if not necessary :wink:

[I edited the ‘Open Button’ section in my post above.]

Thanks for that. I have changed (but NOT updated my post above yet) both "Delete" actions to "Trash" actions.
However, I think the button should stay as is: "Delete".

I don't see that used anywhere else.

Thanks for your suggestions. However, I disagree with your "for every use case" assertion, and with your "nobody likes to click through confirmation dialogs" assertion.

I have designed the UI the way I think it should be based on my experience with a lot of users. Maybe some will like it, some will not. IAC all can modify it to suit their own liking. It see my post as just a starting point for people to use, not as a final production product.

Feel free to post your own macro with the UI as you like it.

That’s why I think Trash is better than Delete.

I don't see that used anywhere else.

Sorry, not the wording. I did mean: trashing a file is preferable to deleting a file, because for “recovering” a trashed file you only have to move it back from the Trash can. If you delete a file it’s not that easy.

Feel free to post your own macro with the UI as you like it.

Of course.

I didn’t want to offend you. You asked for feedback. These were mere suggestions of improvements that seemed plausible to me. No problem at all if you don’t agree.

A post was split to a new topic: Uploading Files

A post was split to a new topic: Forum Color Scheme

A post was split to a new topic: How do you attach a Folder Action to a folder?

I added this macro but for some reason I end up with the full path in my TriggerValue, instead of just the file name. Why? What am I missing?

See Compatibility Notes for KM 7.1:

Folder Trigger now sets TriggerValue to the full path. Adjust macros to account for this.

1 Like