Open Source

In System Preferences > Sound > Sound Effects, users have the choice to turn off user interface sound effects (as an example, that might be a “tick” sound when adjusting a slider, or a “lock/unlock” sound when clicking a Lock button).

But how do you respect that setting? NSSound surely doesn’t.
Well, I found two ways to do it:

The “Easy” Way

macOS has a key in the standard UserDefaults object

com.apple.sound.uiaudio.enabled

If it is present and set to true, it’s safe to play the ui sound.

The “Safe” Way

What if the UserDefaults key isn’t present? Or you just want to be absolutely certain that your sound respects the user’s setting?

Use the AudioToolbox APIs. It offers

AudioServicesSetProperty(kAudioServicesPropertyIsUISound,...)

which marks sounds as UI sounds, thus not playing if the user wishes them not to.

It’s a bit more work, but might be the safer way to do it.

Read more

For my freeware app SiriMote (which lets you control your Mac and its apps with your Apple TV Remote), I created a code-drawn representation of Apple TV’s Siri Remote (versions 2015-2021).

I figured, sharing is caring, so here you go, you can get at it over on GitHub.

It’s written in Objective-C, was built with Xcode 12.5.1 and runs on macOS 10.12.2 and newer.

Enjoy 😊

Read more

For Transloader’s upcoming version 3.0, I needed an NSMenuItem that not only showed a title, but also a subtitle, along with an optional image.

Because it took a bit of work and “reverse-engineering” (the click-on-an-item-selection-animation’s timing, in particular), I figured someone else might benefit from this.

Where to get it / Sample Project

It’s all pretty straight forward, and best shown / explained as an Xcode project, which you can download on Github.
This is basically all you need to do:

Screenshot the sample project's source code

That’s it!

Caveats

There are some things this implementation can not do, which the default NSMenuItem can:

  • There is no type select
  • The arrow keys can’t be used to go through the items
  • You can’t activate items with the space or enter keys

Basically, keyboard interaction is unavailable.

I do hope it’s useful to you anyways.
If you’re using this, I’d love to hear from you! 😊

Read more

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.

Greyed out files 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

Setting the creation and modification dates of the file to be greyed out

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:

mdls in Terminal on a copying 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…

Setting creator and type codes in Objective-C

…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.

Read more