More tolerant weight recording

You may remember the Weight Today shortcut I wrote about last month. I run it from my iPhone every morning to record my weight in both the Health app and a CSV file I use for graphing my progress (or lack thereof). It’s a simple shortcut, and yesterday it proved to be too simple.

I made a typo when entering my weight and tapped the Done button before I could stop myself. I opened up a text editor to fix the entry in the CSV file, but got distracted and forgot to fix the entry in Health. Not a big deal, but later that day I saw that a 3-mile walk had, according to my watch, burned only 1 calorie. I complained on Mastodon about the watch screwing up, and this morning Juande Santander-Vela (without knowing of my weight recording error) correctly deduced the cause:

maybe you’ve recorded a new weight and it is too small? I remember having had the opposite problem, where merely moving incurred a lot of calories, and it was because 80,2 kg had been recorded as 802 kg…

Upon reading this, I immediately opened the Health app and saw that it had my weight as 1.4 lbs. That explained the minuscule calorie count.

Shortly thereafter, April had a suggestion:

Can you incorporate some logic in your Shortcut to check for a minimum weight to avoid this?

Great idea. I’ll collect the most recent weight, compare it to the value just entered, and if the difference between the two is too much, I’ll ask for the weight again. I’ll put a while loop—or whatever Shortcuts calls a while loop—into the shortcut and that’ll take care of the problem.

Except I couldn’t find anything like a while loop in Shortcuts. I asked on Mastodon if I’d missed something, and the answer was no. Shortcuts can loop a specific number of times and it can loop through the elements of a list, but it can’t loop until a condition is met. Two workarounds were suggested:

  1. Use a Repeat loop with an unreasonably high count and stop the shortcut when the condition is met. This was suggested both by Tom and by Ian Bjorhovde,1 but I couldn’t bring myself to do it this way. Too ugly.
  2. Use recursion. This came from Leon Cowle, and that’s what I went with. Recursion seems kind of highfalutin for Shortcuts, and rewriting Weight Today that way made me think I was doing an exercise in SICP.

Here’s the new, more tolerant version of Weight Today:

StepActionComment
1 Weight Today Step 01 Get today’s date.
2 Weight Today Step 02 Format it as yyyy-mm-dd.
3 Weight Today Step 03 Get all the weights recorded in Health over the past 7 days, put them in reverse chronological order, and limit the list to the most recent.
4 Weight Today Step 04 Get the numerical value of the most recent weight.
5 Weight Today Step 05 Ask the user for today’s weight.
6 Weight Today Step 06 Calculate the difference (absolute value) between today’s weight and the most recent.
7 Weight Today Step 07 If the difference is more than 3…
8 Weight Today Step 08 Rerun the shortcut
9 Weight Today Step 09 If the difference is 3 or less…
10 Weight Today Step 10 Log today’s weight into the Health app.
11 Weight Today Step 11 Make a new CSV line.
12 Weight Today Step 12 Add the line to the CSV file.
13 Weight Today Step 13 Done.

As you can see, I chose 3 lbs as the cutoff for a realistic weight change. Anything more than that and I’m asked to try again. In the 6 months or so that I’ve been tracking my weight, I’ve never had a change of more than 2 lbs, so 3 lbs seemed like a decent choice. Of course, this doesn’t prevent all typos, just excessive ones.

I think the comments explain the shortcut pretty well. If you want to use something like it, but without the CSV stuff, just delete Steps 11 and 12. One last thing: I learned that the fabs function used in Step 6 was available in Shortcuts through a Reddit post by gluebyte.


  1. Whose uncle (I think it was uncle) Reidar Bjorhovde was a structural engineering researcher of some renown. 


Moon speed

We had very clear skies in the Chicago area last night, and I was able to see Mars just before the Moon passed in front of it. This happened somewhere between 8:00 and 8:30. A couple of hours before that, I tweeted

Mars is about two Moon diameters away from the Moon right now. Will go behind the Moon in a couple of hours. It’s a very clear night in the Chicago area; seeing this makes the cold that comes with cloudless skies worth it.

The prediction of when the occultation would occur was made with the help of GoSkyWatch, an app I’ve had since shortly after it was released in 2008. But with a little thought, I realized that I could have made the same rough prediction with no help at all.

As we learned in the Antikythera post, the Moon travels

360 +29.1067 =389.1067

in 29.5306 days or 708.734 hours. Therefore, the Moon moves at an average speed of

389.1067708.734=0.549deghr

against the background stars.

Because of the media’s recent obsession with supermoons, we know that the Moon’s apparent diameter varies, but on the average it’s about 31 arcminutes or

3160=0.516

Therfore, it moves roughly one diameter per hour. If it’s two diameters away from Mars at 6:15, it’ll start to occlude Mars at 8:15. More or less.

Do we need to account for the motion of Mars? Not at the level of precision we’re using. A Martian year is about 687 Earth days long, so its movement against the background stars is about 1/25 th that of the Moon. When considering its motion relative to the Moon over the course of a few hours, Mars is essentially as fixed as the background stars.


Retrobatch droplet improvement

Shortly after I published my CleanShot X/Retrobatch post, Allison Sheridan posted this on Mastodon:

That’s a great use of those tools. I am a big fan of Clean Shot X and Retrobatch but never thought of combining them. My main use of Retrobatch is to make featured images for blog posts that match what most if not all of the social media services will recognize. That droplet thing is money. I keep mine in the toolbar of Finder though since I always have a Finder window open when I’ve made a screenshot.

What’s actually money is Allison’s last sentence. Having the screenshot-trimming droplet sitting on my Desktop was the one thing about it I didn’t like. Putting it in the Finder toolbar is perfect because, like Allison, I always have at least one Finder window open when I’m writing blog posts and making screenshots for them.

So I moved the Trim Screenshot app into the Applications folder and set about adding it to my Finder toolbar. I control-clicked on the Finder window’s toolbar, selected Customize Toolbar…, and dragged the Trim Screenshot icon into the toolbar, putting it to the right of the folder name. Since I keep a post’s screenshots in the same folder as the Markdown source, I always have that folder open when writing. It’s now a simple matter to drag the screenshot from the Finder window up into the toolbar and drop it on the Trim Screenshot icon.

There was one more problem. The icon in the toolbar was the generic Retrobatch droplet icon. A fine icon, to be sure, but what if I come up with another Retrobatch workflow that I want in my Finder toolbar? How would I tell them apart? I refuse to change my toolbar display to Icon and Text.

The solution is to change the icon of the Trim Screenshot app. I opened Acorn and built this image:

Trim Screenshot icon

It’s started as 1024×1024 image saved as a PNG file and is meant to convey the idea that the droplet reduces the Desktop padding in a window screenshot. I later expanded the size to 1400×1400 by adding transparent padding around the outside. I’ll explain why in a minute.

Then I opened Trim Screenshot’s Get Info window and dragged the PNG file onto the icon spot at the upper left corner.

Trim Screenshot Get Info window

That changed the icon of the droplet in both the Applications window and, most important, in the Finder toolbar.

Finder window with Trim Screenshot icon in toolbar

You may have noticed that the blue in the icon is much brighter than the blue of my Desktop. That’s because when I used my Desktop blue in the icon it just looked gray when the icon was shrunk down. I had to brighten it up to make it look blue to me in the Finder toolbar.

Also, the icon was distinctly bigger than the others in the toolbar when it was 1024×1024. The transparent padding brought it down to a more reasonable size. It could probably be made even smaller, but I don’t want the arrowheads to get too small to see.

Now I have workflow for trimming screenshots that’s easy to use and keeps my Desktop clean. Thanks, Allison!


CleanShot X and Retrobatch

As last year wound down and software went on sale, I bought some new apps and updated some others. Included in these gifts to myself were CleanShot X, which is as good as everyone has said it is, and the Acorn/Retrobatch upgrade bundle. Over the past few days, I’ve been using CleanShot X and a Retrobatch workflow to handle the screenshots I post here.

As you may know, I’ve long had a couple of Keyboard Maestro macros for dealing with screenshots: SnapClip and SnapSCP. Because of the limitations of the screencapture command,1 neither of these macros can put both a drop shadow and a Desktop wallpaper around window screenshots. But CleanShot X can, which is why I’ve started using it. But it needs some help from Retrobatch.

Here are the CleanShot X wallpaper settings with the padding at the lowest value possible:

Screenshot of CleanShot X settings with wallpaper

As you can see, the padding around the window is still pretty big, about 110 pixels. I want to trim it down to a more reasonable size, like this:

Screenshot of CleanShot X settings with trimmed wallpaper

I don’t mind that part of the shadow gets cut off.

There are lots of ways to do this trimming, but I decided to make a Retrobatch workflow and turn it into a droplet, an app that sits on my Desktop that I can drag screenshots into to get their padding trimmed. Here’s the three-step workflow, which I call Trim Screenshot, showing the details of the Adjust Margin step:

Trim Screenshot workflow

The -70 adjustment on each edge trims the padding around the window down to about 40 pixels, which is larger than what I use in SnapClip and SnapSCP, but looks fine, maybe even a little better. I’ve been fiddling with this value for a couple of days and may change it again as I make more screenshots.

The Write Images step writes the changes back to the original file (I don’t need both versions hanging around), and the Quit Retrobatch step does what it says—without it, Retrobatch would stay open after the resizing, which would be weird for a droplet.

The first time I dropped a file onto Trim Screenshot, I got this permissions warning:

Permissions warning for Trim Screensot

Because the droplet is an app in its own right, the permissions already given to Retrobatch don’t apply; it needs its own authorization. And as I was experimenting with different amounts of trimming, the newly saved droplet kept needing reauthorization. O timid new world that has such warnings in’t!

Unlike SnapSCP, this workflow doesn’t upload the screenshot to my server, but I haven’t been using SnapSCP much recently. Since I often need to annotate screenshots, and I almost always have Transmit running when writing a blog post with images, automatic uploading isn’t as useful to me as it once was. This CleanShot X/Retrobatch/Transmit system is working pretty efficiently.

Update 3 Jan 2025 3:31 PM
Thanks to Allison Sheridan, I’ve moved the droplet to the Applications folder while still keeping it easy to drop files onto it. The explanation (which is a little too long for an update) is in the next post.


  1. Yes, that’s a link to an HTML-formatted man page. There will be a post about that soon.