Developer Tip

In an effort to support macOS Monterey’s new Shortcuts in Transloader‘s Link– and File Actions, I decided to run all the necessary CLI commands and AppleScripts in an external XPC service, mostly to separate privileges (running Apple Scripts (which aren’t precompiled and reside in the Application Scripts folder) in a sandboxed Mac app requires specific sandbox entitlements, which Transloader itself just doesn’t need).

I didn’t start with an XPC service, though. For testing and debugging purposes, I began with a new app in Xcode and ran all the Apple Scripts from there, which, after a bit of tweaking because I’m not “fluent” in Apple Script, worked just fine.

After subsequently moving them into an XPC service and thinking it would “just work”, I found that it didn’t. At least not reliably. Maybe every 8th or 9th time, yes, it did all it was asked to do, but every other time, it outright refused to execute Apple Scripts.

After two days of desperate attempts to get it working correctly, and almost giving up on the XPC privilege separation entirely for this, I figured I’d check to see if the Apple Scripts were being executed on the main thread.
I did recall reading quite some time ago (I don’t know where, sorry) that Apple Scripts on background threads are iffy in their execution. Lo and behold, the methods weren’t run on the main thread. One quick dispatch_async to the main queue later, and everything worked as I expected it to.

So, the takeaway of all this, and the TLDR, is this post’s title: An XPC service’s methods aren’t necessarily run on the main thread. Go figure.

Addendum

If you’re wondering what my configuration for the XPC service is:

RunLoop = NSRunLoop
ServiceType = Application

I did try dispatch_main as RunLoop as well, which worked too, but I just figured, for Apple Scripts, NSRunLoop would be required, but I don’t know for sure.

Read more

Since I’ve had to go re-watch WWDC20’s “Adopt the New Look of macOS” session (at around the 07:03 mark), I thought I’d note it down here – for anyone else late to the update-for-macOS-Big-Sur-game 😉

What we want to achieve is go from this UI (basically standard on any macOS before Big Sur):

Screenshot of Yoink's preferences on macOS Catalina and earlier

to this UI (new UI for Preferences windows on macOS Big Sur):

Screenshot of Yoink's Preferences on macOS Big Sur

And it’s fairly easy to do so. All you need to call is (pardon the Objective-C, Yoink for Mac (and iPad and iPhone, for that matter), is still 100% Swift-free..)

self.window.toolbarStyle = NSWindowToolbarStylePreference;

and update your toolbar items’ icons, and you’re all set.

Screenshot of Xcode  24 09 2020 08 48 22

 

 

– Matthias
mail | website | twitter | instagram | facebook

Read more

When creating a custom Quick Action for macOS Mojave’s Finder, you have the option to supply a custom icon:

Creating a custom Quick Action in Automator for macOS Mojave

Selecting an icon in Automator

But this is what happens when you supply an ordinary image in Dark Mode:

A Quick Action's icon without adjustments

or Light Mode:

Unmodified Quick Action icon

(in Light Mode, it’s obviously better, but still not as subdued as it should be, which is more grey than pitch-black, or whatever color your original icon file might have).

Tip #1 – Getting the icon’s color right

The trick is to have the file end in ‘Template’, like ‘MyWorkflowIconTemplate.tiff’. But that’s not all there is to it. When you add a custom icon through Automator, it automatically gets renamed into ‘workflowCustomImage.png’. So no matter what you name your file, it won’t matter.

To fix this, add a custom icon to your Quick Action in Automator, save, switch to Finder and navigate to /Users/yourname/Library/Services/, where your newly saved Quick Action will end up.
There, right-click your Quick Action, select ‘Show Package Contents’, and navigate into Resources, where your icon file will be. Rename it to ‘workflowCustomImageTemplate.png’.
Now, navigate into Contents and open Info.plist. Look for <key>NSIconName</key> and change ‘workflowCustomImage’ to ‘workflowCustomImageTemplate’. Save.

Now the icon will look like this:

Modified Quick Action icon in Dark Mode

Modified Quick Action icon in Light Mode

That’s much better. But there’s another issue we need to take care of:

Touch Bar with oversized Quick Action icon

The icon’s a bit too large, even though in Finder and the “More…” menu, it looks well-sized.

Tip #2 – Getting the Touch Bar icon to play nice

I thought I’d be smart about it, since the “append ‘Template’ “ trick worked, I’d have three differently sized images and append @2x and @3x. But it didn’t work.
The trick is to have a TIFF file with 2 (or 3, to be on the safe side) representations – one at 1x, one at 2x and one at 3x.
And voila, it worked:

Quick Action icon in Touch Bar with properly sized icon

To create the TIFF, I wrote a small app that takes my icon file, creates three NSBitmapImageRep objects from it and adds them to an NSImage instance. Then it writes the NSImage object’s TIFFRepresentation to disk.
Open that file in Preview.app and you’ll notice all three icons inside that one TIFF (you might have to select View – Thumbnails in the menu to show them)
Select the first and select Tools -> Adjust Size… in the menu bar.
Resize the image to 16×16 (which I found to be working nicely) and set its resolution to 72, if it isn’t already.
Select the next thumbnail and resize it to 32×32 at 144 DPI, and the third thumbnail to 48×48 at 216 DPI. Save.
Now repeat Tip #1 with this new file and you’re all set.

I hope this will save you some time, as it cost me plenty 😉

_____
Matthias Gansrigler
 | Founder & Developer – Eternal Storms Software
e: blog@eternalstorms.at
twitter | facebook | instagram

Read more