It’s June, and you know what that means! Well, maybe you don’t… Apple’s World Wide Developer Conference (WWDC) is held at the beginning of June every year, and Apple traditionally uses the conference to introduce the next version of all of its operating systems. This year is no different, so developers world-wide (see what I did there?) are downloading and running the first early test version of macOS 13 “Ventura”.
And because Default Folder X works so closely with the operating system, it needs to be updated to support each new version. So there’s now a public pre-release build of Default Folder X 5.7 that’s available for folks who are running Ventura. For those of you who are accustomed to Default Folder X’s quick navigation and file management, this will keep you from getting frustrated while testing or developing on Ventura 😁
A download link, release notes and a list of known problems are on the Default Folder X Testing page. I’ve also rolled in a few fixes for other issues that affect both Ventura and past versions of macOS, so check the release notes for details about those, too.
Version 2.7b2, the second public beta release of App Tamer 2.7, is available on the App Tamer Beta Testing page. If you’ve recently downloaded beta 1, just choose “Check for Update” from its utility menu or in the Options tab of App Tamer’s Preferences window to get the new version.
The changes in beta 2 are relatively small, correcting interactions between the new capability of running apps on the M1 processor’s efficiency cores and several existing App Tamer options. In addition, App Tamer’s online help has been brought up to date, and a bug affecting the CPU usage graphs in beta 1 has been fixed. Details and download links are available on the beta testing page.
If you have any feedback or bugs to report on the 2.7 beta releases, please share them in the comments here or by emailing AppTamer@stclairsoft.com. Version 2.7 is on track for release soon, barring any further bug reports or changes.
There’s now a public beta version of App Tamer 2.7 available for download. The big deal in this iteration is support for the Performance and Efficiency cores (or “P and E cores” for short) in Apple’s M-series processors.
P and E core usage statistics
As you can see in the image on the left, App Tamer now displays graphs of P and E core usage as well as overall CPU usage. You’ll get these automatically if you’re running App Tamer on an M1-powered Mac.
Note that P and E stats are shown as a proportion of total CPU power available, so on an M1 Pro processor (8 P cores and 2 E cores), the E core number will max out at 20% (2 cores out of the 10 available), while the P core number will max out at 80%. This may be a little counter-intuitive at first, but it was even more confusing to represent them as a percentage of each core type. In that scenario, “CPU Used by All Apps” could show 50%, with E core usage at 100% and P core usage at 38% – which doesn’t make sense to most normal humans.
Running background apps on E cores
This is the really cool part. When you click on an app in the process list to change its settings, there’s an additional “Run this app on the CPU’s efficiency cores” checkbox, as you can see in the screenshot below.
I explained the basics of this feature in a previous post. It works like App Tamer’s other CPU-saving capabilities in that it’s applied to an app anytime that app is not frontmost. If you turn on the checkbox for Safari, any time that you leave Safari running in the background while you’re using another app, Safari will be switched to the processor’s E cores. This saves power and leaves the P cores free to handle higher priority tasks.
Note that the effects of this feature are similar to App Tamer’s existing “CPU throttling” capability, which is what you get when you turn on the “Slow down this app if it uses more than X%” checkbox. However, there are a couple of advantages:
The E cores actually consume less power by design
There’s no overhead when running an app on E cores, whereas throttling an app’s CPU usage requires App Tamer to actively manage the app’s execution
So, basically, running an app on the processor’s E cores saves more power than throttling it.
Of course, the two aren’t mutually exclusive – you can run an app on the CPU’s E cores and throttle it while it’s there if it’s still using too much processing power. App Tamer will let you turn on both checkboxes to do this.
What about Intel-powered Macs?
If you’re not using a fancy new M1 or M2 (soon?) powered Mac, you won’t get this new feature. However, that checkbox does still do something. It’s named “Run this app as a low-priority process” on Intel Macs, and it will use the macOS system scheduler to reduce the priority of the app, both in terms of CPU usage and disk and network I/O. This will reduce its impact on other apps and cut its energy usage somewhat, but not nearly as much as it does on M-series Macs.
So I was reading Howard Oakley’s Eclectic Light Company blog, as I often do (and you should too), and he mentioned the taskpolicy command line app, which I wasn’t aware of before. taskpolicy allows you to demote a process to “background priority,” making it run more slowly by giving it a lower priority for its disk and network access and – key point here – on M1-powered Macs, also runs the process on the M1’s efficiency cores instead of on the performance cores.
That got me thinking… if there’s a command line tool to do this, there must be a system API to make this happen, too. And lo and behold, the setpriority( ) system call will actually perform this neat trick, even though the man page lies and says it won’t.
I made some changes to App Tamer yesterday to add this, and App Tamer now has a new checkbox:
Turn the checkbox on, and whenever an app isn’t frontmost, App Tamer will give that app background priority, reducing its disk and network priority and switching it over to run on an M1 efficiency core. Running a few apps that consume quite a bit of CPU looks like this in Activity Monitor:
In my initial testing, the feature seems to work quite nicely. App Tamer automatically moves apps between the performance and efficiency cores as you switch between apps. So far, I haven’t found any downsides to this – but then again, I just added the feature yesterday and have only done limited testing. It’d be great to actually quantify whether this delivers additional battery life.
If you’d like to give it a try, you can download App Tamer 2.7d1 here. Just unzip it and run it, then click on a cpu-hungry app in App Tamer’s process list and turn on “Run this app on an M1 efficiency core” – that’s it. App Tamer will automatically lower the app’s priority when it isn’t frontmost.
Note for users of Intel-based Macs: On your machine, the checkbox is named “Run this app as a low-priority process” because your Mac doesn’t have separate efficiency and performance cores 😢. The app will be demoted to background priority so it uses fewer CPU and I/O resources, but I’m afraid there’s no fancy cpu-juggling involved.
While it’s been slow going, I’ve gotten a few new features put together in the ongoing development of version 6 of Default Folder X. I’m sharing two here because I’m very happy to have gotten them up and running, as I personally find them really useful.
Expanded Filename Editing Field
It seems like such a minor thing, but when you’re saving something like a web page that has a long name, it’s maddening that Save As dialogs have such a tiny edit box for the filename. The long name runs past the end of the edit field and you have to click and drag or use the arrow keys to get to the rest of it if you want to make any changes.
While it required way more juggling than I expected, Default Folder X 6 expands the filename field to a usable size.
Keyboard-based Access to Recent and Favorite Items
I’m personally a very keyboard-biased user. I’d rather use shortcuts and type than take my hand off the keyboard to click around with the mouse. As a result, Default Folder X has always had the ability to assign keyboard shortcuts to Favorites and to access recently used items. Up until now, however, that didn’t include just typing to select exactly what you wanted. In version 6, that’ll be an option:
I’ve used a “Sublime Text-style” selection method, where fuzzy matching gives you results that include file, folder and application names that contain the letters you’ve typed, even if there are some missing in between. It also favors capital letters and the first letters of words.
You’ll see that the top match in the image above when typing “roc” is “ReactiveObjC” because of the capitalized R, O and C in the correct order, with “ProcessController.m” further down the list even though it contains “roc” in lowercase. I’m still tweaking this, but I find the results pretty quick and intuitive when looking for something (though granted, the results lower down in the list tend to appear almost random until you look hard at them).
As a developer, the danger I see with this feature is that people will want me to reproduce all kinds of options from similar keyboard-based utilities like LaunchBar and Alfred and I’m not sure how far to go with that. This isn’t meant to replace those (I’m a long-time LaunchBar user myself), but some additional tweaks could be nice…
If you want to help test…
While these (and other) features are still in development and thus a bit rough around the edges, I’d welcome input if you’ve got some time to try them out and provide thoughtful feedback. Email DefaultFolderX@stclairsoft.com if you’re interested.
Version 5.5.2 of Default Folder X is available. It works on Apple’s recent macOS 11.1 Big Sur beta release.
Amusingly, the biggest problem on macOS 11.1 was the new version numbering scheme that Apple is using for Big Sur. Default Folder X checks the OS version and had always assumed that if the minor revision number (the ’15’ in 10.15.7, for example) changed, it was a major new OS release, because that’s the way it’s always been in the past. Big releases like going from Mojave (10.14) to Catalina (10.15) generally require significant testing and development to ensure compatibility, so it just disables itself and waits for me to finish a compatibility update.
So when Apple went from Big Sur 11.0.1 to Big Sur 11.1 beta (with a version number change that surprised a lot of us developers), Default Folder X said “Oh no, it’s a major OS release! I don’t know what to do, so I’ll just be safe and do nothing” and refused to even look at the Open and Save dialogs. So yeah, redoing the OS-version-checking logic and making a minor functional tweak was all that was actually necessary to get things working on 11.1.
In the process of testing Default Folder X on the Big Sur 11.1 beta, I did find a bug that could potentially cause file dialogs to lock up for what seems like an eternity (potentially as much as 2 minutes), so that’s also fixed in 5.5.2. Because of that, you should update if you’re running Big Sur, even if you’re not using 11.1.
Default Folder X 5.4.1 is now available. It fixes several issues that have been reported with macOS Catalina. A couple were simple bugs in Default Folder X itself:
Empty folders were not added to the Recent Folders menu
Items in the Utility menu were sometimes not enabled correctly
File dialog menu shortcuts were not working as advertised
Those issues have all been fixed. One other fix, however, is a bit bizarre. I figured I’d briefly talk about it in case other Mac users or developers encounter this:
In Catalina, the Finder must be running before you can approve apps to record the screen
In macOS 10.15, Default Folder X requests permission for Screen Recording (here’s why). If it doesn’t have permission, it tries to capture a portion of the screen, which causes Catalina to pop up an alert asking for your approval. Default Folder X then leads you through System Preferences to ok everything. It’s an annoying process, but works as well as can be expected given Catalina’s limitations. UNLESS you happen to also be a user of CocoaTech’s Path Finder app.
If you’re running Path Finder and have chosen to have Path Finder launch when you log in and have its preference set to quit the Finder after it launches, you’re in for a treat. If an app needs permission to record your screen, you will never see the prompt, and the app will not be added to System Preferences > Security & Privacy > Privacy > Screen Recording, so there’s no way for you to manually approve it there if you happen to realize it needs permission.
Based on testing that I and Ben Surtees at Surtees Studios (developer of the excellent Bartender app) have done, if the Finder isn’t running, the permissions system for Screen Recording just silently fails. Default Folder X, Bartender or whatever app needs permission doesn’t know this, and will continue prompting you to authorize them in System Preferences. Unfortunately, you have no way of approving them because there’s no way to manually add apps to the Screen Recording privacy panel, and if the Finder’s not running, the system doesn’t automatically add apps as it should.
As a developer, this seems pretty arbitrary – why would we need to have the Finder running in order to get permission for Screen Recording? But there you go – if you’re running into this, now you know why. As of version 5.4.1, Default Folder X will launch the Finder when necessary (and quit it afterwards) if it runs into this scenario. It’s a bit of a comical workaround, but hey, it gets you up and running without further pain.
The latest public beta of Default Folder X 5.4 is available, and offers improvements on both Catalina and older versions of macOS. Specifically, it adds support for the version of Path Finder distributed via SetApp, gives AppleScript developers access to applets and droplets in DFX’s Recent Files menu, and fixes a bug in Default Folder X’s handling of tabbed Finder windows.
To prepare, I wrote Go64, a free application that scans your system for 32-bit apps and shows them all in one place, with version and website information to make it easier to assess whether you need to update or look for an alternative.
After Mojave started warning about 32-bit apps needing to be updated, Ronald Leroux, who does all the French localizations of my software, pointed out that there wasn’t really a good way to check for and update 32-bit apps on your system. The built-in System Information app does work, but it’s certainly not the most user-friendly, nor is it necessarily complete.
Over a weekend last fall, I put together a straightforward little app to scan for 32-bit applications and show them in a list. It took a fairly simplistic approach, and worked fine but was no more thorough than what System Information provides. Still, it was much easier to use, so I figured I’d release it in the Mac App Store. Then came the task of trying to get it approved: App Store Review rejected it because it asked for permission for the entire disk so it could scan for apps. That wasn’t something I could fix or work around. So I shelved it – there were higher priorities at St. Clair Software, plus dealing with the App Store always seems to ruin my day.
Fast forward to WWDC 2019, when Apple confirmed that Catalina definitely won’t run 32-bit apps. Howard Oakley at the Eclectic Light Company had been doing some deep-digging and highlighted a number of issues with 32-bit app checking. He wrote his own exhaustive scanner that searches for them, but it’s slow and still not very user-friendly. I dusted off Go64 and figured I’d turn it into a more complete solution.
“It’ll only take a couple of days…” – famous last words uttered by nearly every software developer at some point in their careers.
As they say, the devil’s in the details, and dealing with the vagaries of what goes on inside applications got interesting. Go64 leverages Spotlight to compile a list of executables, but then does a deep dive into each 64-bit application to check for any helper apps, frameworks, services or plugins that might not be 64-bit. While I knew this could be an issue, Howard’s work highlighted just how common it is to have a mix of executables bundled within apps. Most of the time, it’s just for expediency, and developers do the proper juggling to run the correct one, but how’s a user to know? So Go64 does a bunch of checks to look for common methods, and if it still can’t make sense of things, errs on the safe side and flags the app with a little caution icon.
Clicking on “More Info” gives you the whole scoop:
This, of course, led to more complexity. As a developer, I don’t want to be bugged by hoards of people asking whether my app is Catalina-compatible just because some stupid “Go64” app noticed I include a 32-bit helper to deal with ancient Quicktime videos. So Go64 updates its internal “Ignore this warning” list periodically from the St. Clair Software website – that way it can inform users that even though the app contains 32-bit code, it’s compatible.
So developers, if your app contains 32-bit code but is Catalina-compatible, contact me with the bundle ID and version number of the app and I’ll add it to the list so Go64 gives users this message instead:
And to everyone else, I hope Go64 turns out to be useful for you. I certainly had a lot more 32-bit apps sitting on my Mac than I thought!
Version 5.3.7 of Default Folder X introduced a new capability: it can now ask what the default folder for an application should be on the fly using AppleScript. That may sound like a mouthful of jargon, so let me explain, because it can be applied in a lot of situations.
Jason Snell (of Six Colors and The Incomparable fame) has been writing about Macs forever, and is now a prolific podcaster. He emailed to ask if it would be possible to make Default Folder X more flexible. At that time, you could set a default folder for an application so that when you chose Save As, it always offered to save a file in that particular folder. His problem was that you have to set a single folder as the app’s default folder – just one.
Jason creates podcasts – lots of them. His reasoning was that if he could magically tell Default Folder X what podcast he was working on, it would always offer to save the component audio files into the folder for that podcast. Essentially: Wouldn’t it be great if you could edit an audio clip, hit Save, and have it automatically go into the folder for the current podcast folder? No re-configuring a default folder for each new project – it’d just work.
So he hit on this idea (which I think is just brilliant). He uses Apple’s Logic X application to create his podcasts. So for each podcast episode, there’s one master Logic X project file. To find the correct default folder for audio clips, all he has to do is look at all the project files and see which one has been saved most recently. The “Audio Files” folder sitting next to that project is where everything should go for the current project. He wrote an AppleScript to do this, which he shared on the Six Colors blog.
This can obviously translate to all sorts of different workflows. If you have one primary file for each project, it’s easy to tell which one you’re currently working on – it’s the one that’s been saved most recently.
How to set up an AppleScript to specify a default folder
So how do you wire up Default Folder X to do this? It’s pretty simple. Put an AppleScript script in:
or, if you want it to handle only a single application, put it in a sub-folder of the Scripts folder named for the application you want it to serve. To have it queried only for Preview, for example, put an AppleScript in:
The trick is that you need to implement this handler:
on getDefaultFolder(appName, dialogType, firstTime)
which returns the location of the default folder. Open up the sample script file in Script Editor (or your AppleScript editor of choice) and have a look. I’ve tried to explain things clearly in the comment at the top, and the script shows a number of different ways of returning folders to Default Folder X. And of course, you can also use Jason’s complete script as a starting point.
I think Jason’s idea is great – it streamlines work on multiple projects, but most importantly, it reduces the chance for error as you’re trying to meet that pressing deadline. I’d love to hear how others use this feature, so please drop me a line if it works for you too!
