Version 2.7 of App Tamer is out of beta testing and available for download. Details and download links are on the App Tamer release page.
In case you missed the beta versions and accompanying blog posts, the marquee feature of this release is the ability to run an app on the M1’s efficiency cores instead of on the more power-hungry performance cores when you’re not actively using it. As with the rest of App Tamer’s capabilities, it’s a simple matter of selecting the running app and clicking on a checkbox:
App Tamer 2.7 also augments its interface with additional performance information to let you manage CPU and power consumption intelligently. In addition to showing overall CPU usage, it breaks it down by processor core type, giving separate stats for the M1 performance and efficiency cores. They’re included textually and graphically in App Tamer’s window, and also (optionally) as tiny ‘P’ and ‘E’ values in its menu bar display:
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.
Version 5.6.4 of Default Folder X is available. It updates its tracking of cloud-sync services (OneDrive, Dropbox, Box Sync and Google Drive) to handle changes that Apple is requiring for macOS 12.3 compatibility. OneDrive and Box Sync were recently updated, and this resulted in Default Folder X’s Recent Files and Recent Folders menus no longer showing items that were synced to your Mac by those services. This update fixes that.
Default Folder X 5.6.4 also works around a bug in Chromium-based web browsers that rendered default folders inoperable if they depended on the type of file being saved. This impacted Google Chrome, Brave, Vivaldi, Opera and Microsoft Edge.
And finally, I fixed a bug in Default Folder X’s logic for expanding and minimizing Save dialogs depending on previous usage and whether the OK and Save buttons lie on-screen or not. It now works as it should in all scenarios and all applications.
Release notes and download links for Default Folder X 5.6.4 are available on the Default Folder X release page, or if you’re already running Default Folder X, by choosing “Check for Update” from its menu in your menu bar.
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.
Version 2.6.5 of App Tamer is available, sporting fixes for a few things that have come to my attention since the last release. Specifically, App Tamer’s Force Quit command, which you can get to by Control-clicking on any app in the process list, now ensures that the app is terminated even if it’s being very uncooperative.
Some UI inconsistencies have also been fixed, including small changes to the text color and font size used in App Tamer’s icon in your menu bar. And there’s a fix to App Tamer’s high-cpu-usage-detection warnings so that if some helper process (like one of Safari’s web content renderers) uses lots of CPU, App Tamer tells you to limit Safari’s CPU usage to fix the problem, rather than complaining about the helper process itself.
This release also includes the “inverting” of an existing feature to fill the niche left by the demise of the app Hocus Focus. App Tamer already offered an option to hide particular apps after they’d been idle for a certain amount of time, but if you wanted that to apply to all applications, you had to turn the feature on for every app individually. Now you can set up all apps to be hidden after 5 minutes (or whatever) in one fell swoop by using these commands in Terminal:
The first command turns on the “hideWhenIdle” feature, while the second sets the “minutesUntilHide” time to 5. You can obviously use any delay you want for minutesUntilHide. To turn the feature off again, just set hideWhenIdle to zero:
Also, if you want a few apps to wait longer to hide, you can override the time using App Tamer’s normal hide-when-idle feature, accessible in the settings popover that you get by clicking on an app in the process list. Or to prevent the app from being hidden regardless of how long it’s been idle, enter zero into the edit box next to the slider.
As usual, concise release notes and download links are available on the App Tamer Release page, or if you’re already running App Tamer, by choosing “Check for Update” from utility menu at the bottom of App Tamer’s window.
There’s a free update to Default Folder X available, bringing it to version 5.6.3. This release adds a few notable exceptions to DFX’s general rule of “if something is hidden, I won’t show it in your recent files or folders”.
Background
Default Folder X has always followed the principle that it should respect your privacy choices. To that end, if you open a file or folder that’s stored within a folder that’s been hidden, it assumes that there’s a reason that folder is hidden and it shouldn’t show the world the thing that you just opened. Generally, that’s what you want. If you hid that huge folder full of photos you took on an ill-considered party weekend in Vegas, your Recent Files menu won’t suddenly be filled with them after you’ve opened a bunch while trying to figure out what the heck your buddy Jason was wearing on his head that Saturday night.
The Problem
The hiccup in this system arises because Apple has chosen to hide some folders on your system by default. Most notably, the Library folder within your home folder is hidden. That’s generally a good idea, since you don’t want to know about its zillions of mystery files storing cached information, preferences, miscellaneous application data and the like. Unfortunately, there are a few things stored in the Library folder that you do care about – namely the attachments included in Mail messages and Messages conversations.
The Solution
In version 5.6.3, Default Folder X now makes special exceptions for attachments that you open from Mail and Messages. Even though they’re in a hidden location, they’ll show up in your Recent Files menu because there’s a reasonable chance that you’ll want to get back to them later.
Similarly, the cloud sync service Box Drive recently changed the default location of its synced Box Drive folder so that it’s stored within your Library folder. That, too, will now be treated as an exception by Default Folder X when it’s tracking cloud-synced files and folders. Anything that arrives in your Box Drive folder will be shown in your Recent Files and Recent Folders menus as it should be.
Other Changes in 5.6.3
In addition to the changes to recent-item-tracking, this release includes a number of bug fixes. One particularly vexing one for some folks was this situation:
where the Save, Cancel and Delete buttons are below the bottom of the screen. While you can move the dialog by dragging the parent window’s titlebar – or use the Return, Esc or Command-Delete keys to activate the button you want – this situation is confusing. It’s caused by Default Folder X trying to “help” by maximizing the dialog that first appears, which originally looks like this:
To fix the problem, Default Folder X now detects this situation and leaves the “do you want to keep this” dialog at its smaller size if there’s not room for it to fit on-screen.
Finally, version 5.6.3 corrects several other less egregious user interface issues. Full details are in the release notes on the Default Folder X Release Page. You’ll also find download links there, or if you’re already running Default Folder X, just choose “Check for Update” from its menu in your menu bar.
Well, the launch of Default Folder X 5.6 for Monterey has been a little rocky if you’ve been using some particular features.
Oops…
The biggest compatibility problem has been with Monterey’s new “Automatically hide and show the menu bar on desktop” setting, which caused Default Folder X to put its controls for Open and Save dialogs in the wrong place on the screen – sometimes covering up the actual file dialog 🙄. There were also issues for some people using Default Folder X’s buttons in their Finder toolbars – if you Command-dragged them to different locations in the toolbar, the buttons would keep moving back to their default positions every time you restarted your Mac.
These problems have been fixed in version 5.6.2, along with a rare situation where the Finder would continually relaunch after you logged in. And on the more benign side of things, Default Folder X’s controls will no longer get in the way of Quick Look previews in Open dialogs.
My apologies for these bugs, and for the rapid succession of the 5.6.1 and 5.6.2 updates. I’m trying to balance the need for getting these fixes out quickly with some patience to make sure there are no other lurking problems, or worse yet, bugs introduced in the process of fixing others.
At any rate, full details are available on the Default Folder X Release page. If you’re already running Default Folder X, this free update is available by simply choosing “Check for Update” from its menu in your menu bar.
Yes, yes, I know Apple hasn’t released the final version of Monterey yet, but I’m fairly confident that there won’t be changes in the full release that will cause compatibility problems. Of course, there’s always the slim chance – if so, you’ll find me out back, kicking myself for jumping the gun. But I hate getting email from customers saying “Help! Default Folder X stopped working!” if they happen to upgrade before updating to a compatible version of DFX. It’s an unpleasant experience for all you bleeding-edge upgraders out there 😉
Anyway, in addition to support for Monterey, Default Folder X 5.6 delivers compatibility improvements with Photoshop, Affinity Designer and its sibling apps, MoneyDance, Flying Logic and PDF Studio Pro. There are also fixes for handling situations where Google Drive or Dropbox folders are hidden, and small refinements in many other areas.
I also rewrote the code for the popup path menu that appears above the list of files in Open and Save dialogs. It had some annoying little graphical glitches depending upon the version of macOS you were running and whether you were in Light Mode or Dark Mode – those should be sorted out now.
A full list of changes is available on the Default Folder X Release Page, along with download links for your chosen language (as long as it’s English, Japanese, French, German or Danish 😁).
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.
