Get Info: #finder

Stapler: I remade a 32 year old classic Macintosh app

by Matt Sephton — Sat, 10 Aug 2024 21:00:00 +0000

The latest version of this app is now available as a free download on the Mac App Store.
More info on my apps website at: gingerbeardman.com/apps/stapler/

A couple of days ago I was reading on Hacker News about a feature in some Linux window managers where they allow collections of tabs from different apps.

This reminded me of BeOS, but at the same time it reminded me of an app from 1992 for classic Macintosh called Stapler, and how I’d talked about that and it’s one-time spiritual successor, LaunchList, in the past. These were both similar apps that allowed you to collect and launch all the apps, files, folders, documents, related to a specific task, thus saving time. Or as Ali Rantakari so succinctly put it in 2009: “Opening a Bunch of Stuff at Once on Your Mac”.

So over the past day or so I built my own take on this concept for modern macOS!

Whilst my app is inspired by both Stapler (right down to the name) and LaunchList, my app adds improvements and features of its own and is more of a hybrid of both. For example, Stapler didn’t have drag and drop and LaunchList didn’t have zero-click auto-launch. My goal was to keep it as simple as possible, but no simpler. To that end, there are no preferences or settings in the app.

Tell me more

The idea is you set up a Stapler Document per project containing related apps, files, folders, etc. Then you can open them all at once by launching the single document. Each document contains a list of aliases that can be managed, inspected, launched using the app. The key time-saver is that if you launch a Stapler Document directly, all the items in its list will automatically be launched. Cool!

Work: text editor, run current game, pixel art editor, bitmap font app, todo list
Play: Music app, Hacker News app, Twitter app, script to position windows
Movie: run Caffeine to keep your computer on, shortcut to put displays to sleep

It’s an odd way of thinking about working on a computer—it’s task-based rather than app-based or document-based. Indeed, some might say it’s an outdated way of approaching things. But I’m always banging the drum about there being so much good stuff that was prematurely left behind along with the memories of System 7 (though I still use that), BeOS, OS/2, Amiga Workbench, GEM and the many alternative desktops of Atari ST, etc. So I thought I’d see if I could walk the walk as well as talk the talk.

Details

It’s written in Swift and SwiftUI and weighs in at 640KB, about one third of which is a multitude of icon files at many different sizes and resolutions. By creating a Document-Based App you get a ton of functionality for free, such as document/tab/window management, undo/redo (though I still needed to watch for it and refresh the app window), and much more.

The editor is a native macOS window that’s kind of like list view in a file manager, or a spreadsheet, or a little folder…depending on your point of view. Plus some menu commands and keyboard equivalents. You can have multiple windows open at once, for example one window each for all your common tasks, giving you the ability to launch full tasks or parts of them with minimal effort.

The items in each list are macOS bookmarks (sometimes: security scoped bookmarks) which are a type of authorised/verified/secure alias (in fact, they’re still called aliases in the code) that have been around for about 10–15 years. They contain the path plus a bunch more info. As macOS becomes more locked-down the recommended way of accessing files is to retrieve these bookmarks through the normal layers of system permissions and security. Without the bookmarks, for example just using plain text paths, I would not be able to show the full images in Quick Look or easily launch the list items. A key benefit is that the bookmark will still resolve if the file is moved somewhere else on the same disk, or even to a different volume!

I store the items as JSON in the saved file, simply because I prefer it to XML (which is the main/default option). I wanted the files to still be human readable and editable to a degree.

The files are launched using the default app specified by that file, so it can be changed on a per-file basis. Individual images might open in an image editor, image viewer, app to run OCR, script to run OCR on it, etc.

Dealing with files was both cool and annoying, cool that you can get the bookmarks to files so easily, but annoying that you have to jump through so many hoops to work around the security and sandbox protections and end up having to do file requests in a long-winded way, and then there’s having to tweak plist entries to give the app just the right permissions. I’m using some features of SwiftUI that mean the app can’t run on anything before macOS 14 Sonoma. All-in-all I’d say modern macOS development is a bit of a mixed bag. Take it or leave it.

Bonus tip

Make sure to uncheck: System Settings > Desktop & Dock > Windows > Close windows when quitting an application

Then leave the windows of an app open as you quit it. When you next launch the app its windows will restore to their previous size and position. If you close the windows first, then the app will restore to having no windows open.

Thanks

My good friend Dave Roberts (Serendipity App Company) for brainstorming why it was so damned difficult to get the app to react differently when a document was opened from Finder. Rip it up and start again! To Dustin Mierau for kickstarting this trend of remaking forgotten old apps for modern macOS. And eternal thanks to Chris Patterson and Ali Rantakari for their apps.

Since launch

support added for macOS 12 and newer (was originally macOS 14 and newer)
new features added
omissions addressed
bug fixes
new icon on the way

Elsewhere

Taking command of the Context Menu in macOS

by Matt Sephton — Tue, 30 Jul 2024 16:14:00 +0000

Yesterday on Twitter the inimitable Morten Just posted a preview of a tool he’s created that wrap ffmpeg to allow movies, such screen recordings but pretty much anything, to be re-encoded to a smaller filesize.

I responded with a trick I use to do the same on “right-click” context menu using a macOS app called ContextMenu, and others said it was possible to do it using Automator (with some caveats). In this blog post I’ll compare the two.

But first… let’s talk about how we will make this work.

Processing files through shell scripts

We’ll be making use of command line tools to do the heavy lifting, but don’t worry I’ll show that this can be as simple as a single-line command to process a single file, or a shell scripts of a few lines to process multiple files.

Single files

The one-line command to convert a video or audio file can be as simple as the following:

/opt/homebrew/bin/ffmpeg -i "$@" "${@%.*}.mp4"

There are some assumptions here:

ffmpeg has been installed using brew
my Mac is Apple silicon, so brew installs commands to /opt/homebrew/bin/
(older Intel Macs will have them installed to /usr/local/bin/)
the script is called with parameters passed by argv so the file is $@
the new file will have the same name as the original, but with a new .mp4 file extension
it only works on single files (read on)

We could add an extra parameter to the command line to use hardware encoding (hevc_videotoolbox) -c:v hevc_videotoolbox, which would be something like twice as fast, but this will not reduce the file size. So we stick with ffmpeg default settings.

You can take the exact same approach with any destination format as it is decided by the file extension. Cool. You could convert any of ffmpeg’s supported file types to any other, such as WAV, OGG, MKV, etc.

And as we’ll see later we can take this simple command and change it to use other command line tools to compress GIFs, with or without upscaling, and many other timesaving tasks. Powerful stuff!

Multiple files

To extend this approach for multiple files you can use the following for loop:

for f in "$@"
do
    /opt/homebrew/bin/ffmpeg -i "$f" "${f%.*}.mp4"
done

Multiple files in parallel

And to process those multiple files in parallel (be careful not to overwhelm your computer!) we can background each execution using the & symbol.

for f in "$@"
do
    /opt/homebrew/bin/ffmpeg -i "$f" "${f%.*}.mp4" &
done

Automator

This has been a built-in macOS app since 2005. Setup is relatively straightforward:

Create a new Quick Action workflow
Workflow receives current: movie files
in: Finder
Add a new action of type action Run Shell Script (search for it in the sidebar)
Pass input: as arguments (this will give us a template command)
Replace the echo line with your command
Save, name it “Duplicate as MP4”

The menu item is now available on the context menu, inside the Quick Actions submenu. After repeated use I find this submenu too annoying, but you may fare better.

So, pretty easy! But, there are some caveats or limitations that may, or may not, annoy you. Perhaps we don’t want the menu item to appear for such a broad range of files (all “movie files”), or maybe we want it to appear for multiple types of files (both “audio files” and “movie files”). Sadly this is not so easy with Automator.

Automator stores these files at ~/Library/Services/ and they will migrate to a new Mac.

ContextMenu

Many years ago I found ContextMenu ($4.99) which solves all of the issues I have with the Automator approach. There’s also a free version, ContextMenu Lite, that supports up to 3 actions to give you a taste of the good stuff.

Submenu is optional
Apply to multiple types (files or directories; can be as granular as file extension)
Show output (sometimes you want to see the results of the command)
Confirmation before running (if it’s a potentially dangerous operation)

The menu item displays in Finder as follows:

ContextMenu stores these files in its own group folder, right click an action and choose Show in Finder, but you can specify your own folder in a location of your choice. Both will migrate to a new Mac, but the later might give you more control.

Edit: we can limit actions to running on files with specific extensions or, since update 1.4.4 specific UTI types.

Compressing a GIF

We can use the gifsicle command line tool to optimise (compress) an Animated GIF. The a parameters I use here are explained in the gifsicle man page, and I arrived at them with years of experimentation.

/opt/homebrew/bin/gifsicle -O1 -Okeep-empty --careful "$@" > "${@%.gif}.o.gif"

We can also do the same thing whilst scaling it up by a factor of 2:

/opt/homebrew/bin/gifsicle -O1 -Okeep-empty --careful --scale 2 "$@" > "${@%.gif}.o.gif"

Repository of ContextMenu Actions

Here’s my repo of shared actions. Inside each .cmaction file is a main.sh file which contains the command that you can use in Automator if you’d like.

github.com/gingerbeardman/contextmenu-actions

These include many useful commands such as:

Convert BIN+CUE to ISO
Change sample rate of audio
Convert image to 1-bit
Convert image format
Create Clean ZIP
Duplicate audio as alternative format
Duplicate image as alternative format
Duplicate movie as alternative format
File information
Generate images for web
Make script executable
Move file (includes helper app)
New file with clipboard
Open file with specific apps
Optimize GIF
Set GIF to loop infinitely
Show GIF info
Playdate Colorize IMG
Replace Existing App (warning)
Scale image to certain percentage
Set as MacJapanese encoding
Show hashes (includes helper app)
Stub out file (warning)
Touch file