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:

Widget with wrong appearance in macOS Mojave's 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:

NSExtensionPointVersion in Info.plist

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:

New NSExtensionPointVersion in Info.plist

and voilà, it worked like a charm:

Widget with correct appearance in Dark Mode on macOS Mojave

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

Advertisements

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.

'Grayed out' file in Finder

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

Source code for setting the creation- and modification dates of a file

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:

Using the mdls command in Terminal

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…

Setting the creator- and type codes in code

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

Finder error message when trying to move a still-being-written-to file

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.

Mac Developer Tip: Programmatically Starting a Search on the Mac App Store

Working on Transloader 3, I wanted to re-implement the Finder’s Open With… contextual menu:

The Finder's Open With contextual menu

Getting the apps in there turned out to be the easy part. What took some effort was the “App Store…” menu item, as I wanted to precisely replicate its functionality.

Transloader 3's Open With contextual menu

Right-click a file in Finder, select Open With -> App Store…, and it will launch the Mac App Store with a UTI search, for example: uti:public.zip-archive.
This will give you a list of all apps available in the Mac App Store that can handle that file type. Neat!

The ‘macappstores’ URL scheme

The Mac App Store app luckily offers a URL scheme:

  • macappstores://
    Launches the Mac App Store
  • macappstores://showUpdatesPage
    Launches the Mac App Store and takes you directly to your Updates page
  • macappstores://showPurchasesPage
    Launches the Mac App Store and takes you directly to your Purchased page
  • macappstores://itunes.apple.com/app/idYOURAPPID
    Launches the Mac App Store and takes you directly to the product page, identified by the product ID

That’s very practical, but not what I was looking for. I was in need of a way to start a search the way Finder does.

In order to find out the URL Finder uses, I wrote a quick throwaway-app that would overtake the Mac App Store’s URL schemes (using LSSetDefaultHandlerForURLScheme) and print out the URL that was opened.
Alas – no dice. Apparently, Finder uses Apple Events or some other magic that “can not be used in a third-party sandboxed app anyway”™ to do its bidding.

After googling the issue, I found a URL that supposedly worked: macappstores://ax.search.itunes.apple.com/WebObjects/MZSearch.woa/wa/search?q=searchterm, but just to pour more salt into an already wide-open wound, it only worked on pre-10.9 systems:

The search URL in 10.9-and-beyond systems

Another dead end. Or was it?
I guess I should have experimented with that URL a little, because Jan Vitturi (@jan4843 on twitter) had the answer: just remove “ax.” from the URL, and it works (on both pre-10.9 and post-10.9 systems)!

Using this URL:
macappstores://search.itunes.apple.com/WebObjects/MZSearch.woa/wa/search?q=searchterm
I was able to get a search going on the Mac App Store, right from within my app.

Sadly, there’s a caveat.
I can’t do a UTI search this way. When I pass (even a percent-escaped) search term along the lines of ‘uti:public.zip-archive’, the Mac App Store tells me there are no results. Reloading that very same page then does show the results – weird and annoying, but nothing I was able to work around.
Using extension:zip seemed to work a little better, but still didn’t return all results a reload would.

Jan Vitturi to the rescue again – the URL’s a little different for UTI or extension searches:
macappstores://search.itunes.apple.com/WebObjects/MZSearch.woa/wa/docTypeLookup?uti=youruti

Alternatively, instead of uti=…, you can use extension=… to search by file path extensions.

My sincere thanks go to Jan Vitturi!

 

Eternal Storms Software Logo

– – – Do you enjoy my blog and/or my software? – – –
Stay up-to-date on all things Eternal Storms Software and join my low-frequency newsletter (one mail a month at most).
Thank you :)