Developer Tip: Custom Icons for Quick Actions

Notice: I’ve moved the blog over to blog.eternalstorms.at – please update your bookmarks!

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

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

or Light Mode:

(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:

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

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:

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

Advertisements

Developer Tip: Today Widgets and macOS Mojave’s Dark Mode

When testing your Today Widget on macOS Mojave and you see something like this using Dark Mode:

don’t fret, there’s a rather easy fix.

In your Today Widget’s Info.plist, in NSExtension > NSExtensionAttributes, there’s NSExtensionPointVersion.
For the widget above – with the wrong appearance – the version was set to 2.0:

To see where the problem might be, I created a new widget under macOS Mojave, and it turns out, it uses version 3.0, which also fixes the appearance issue:

and voilà, it worked like a charm:

Compatibility

I’ve tested back to macOS El Capitan 10.11 and it worked, it will possibly work for earlier versions of macOS, too.

 

 

Hope it helps :)

How-To: ‘Gray out’ Files in Finder

When copying files in Finder, you might have noticed that the newly created, still-being-written-to files are ‘grayed out’, conveniently informing the user that the file is not ready yet.

I wanted to replicate that for an upcoming upgrade of Transloader (along with a progress indicator, as you can see in the screenshot above, but that’s another topic), and after trying a couple of things, I found out how to do it.

I tested this on macOS High Sierra only, since it’s the OS version I’m targeting right now, but I don’t see a reason why it wouldn’t work on earlier versions of macOS.

It’s All in the Date

After digging around on the internet, I found that all that needs to be done is to change the file’s creation- and modification dates to one specific date, namely:
January 24th, 1984, 09:00:00 AM

And it works great – the created file appears ‘grayed out’ in Finder.

There’s a downside, however:
When copying a file in Finder, and trying to move that still-being-written-to file, Finder will display a convenient message that tells the user the file is in use and moving it might cause problems.
This doesn’t happen when using this date-setting approach.

So I kept digging.

The Solution

What I did, then, was use Terminal and the ‘mdls’ command to list the meta data of the still-being-written-to file:

At first, coming from the date-approach, I noticed the kMDItemFSCreationDate item, stating
1904-01-01 00:00:00 +0000

However, setting that as the creation date does nothing at all.

Then, I noticed the kMDItemFSCreatorCode and kMDItemFSTypeCode fields (red arrows in the screenshot of Terminal above).

Setting those like this…

…does exactly what I wanted – it ‘grays out’ the file in Finder, and displays the convenient Finder error message when trying to move it:

Mission accomplished – we’re done!

Please keep in mind, though, that the user may still choose “Continue” to move the file, so you should definitely use an NSFileCoordinator to take care of that.