Version 2.7.3 of App Tamer is now available, fixing a couple of problems.
First, my apologies to folks using versions of macOS older than Big Sur: Changes in the last App Tamer update tightened up the spacing of its menu bar icon to comply with modifications Apple made to Monterey and Big Sur. Unfortunately, it also did that on pre-Big Sur systems, often making its icon too close to adjacent ones in the menu bar. I’ve fixed that in 2.7.3.
Second, internal changes that Apple made in macOS resulted in App Tamer reporting the CPU usage of one particular process – kernel_task – incorrectly. App Tamer would show either zero or astronomical values for kernel_task’s processor use, neither of which was correct. In App Tamer’s defense, the system’s approved public API was supplying those numbers and it dutifully reported them without prejudice. Some hunting around in the macOS source code (thank you Apple for making darwin Open Source!) revealed an alternate method that correctly reports the CPU usage of all processes, including kernel_task. So that fix is now available in App Tamer, making it a reliable source of CPU information for all processes again.
As usual, release notes and download links are on the App Tamer release page, or if you’re already using App Tamer, just choose “Check for Update” from its menu. This update is free if you’ve already purchased an App Tamer 2.x license.
Version 5.6.5 of Default Folder X is now available for download. It includes a number of improvements and bug fixes.
First, Default Folder X now recognizes files that you upload using a web browser or attach to an email as “recently used,” even if they haven’t actually been modified or opened. They’ll appear in DFX’s Recent Files menu so you can quickly get back to them.
Also, this release improves the way it handles Save As dialogs in Big Sur and Monterey. When a Save dialog is presented as a sheet, Default Folder X will emphasize the Finder windows behind it by drawing them darker as you mouse over them, but will leave the title-bar area of the sheet’s parent window unemphasized. This is done so you can still drag the window by its title bar to move it (and its attached Save dialog) around on the screen. It looks like this:
Clear as mud, right? I’ll be the first to admit that it looks damned weird, but given that the Big Sur / Monterey implementation of sheets is a giant step backward in usability, I didn’t have a lot to work with. This method gives you the best access to your Finder windows while still allowing you to move the window (even though the new sheet UI implies that you can’t move it by graying it out).
And while we’re discussing Finder-click, version 5.6.5 fixes a problem with the way Default Folder X tracked the windows of Path Finder and ForkLift. They sometimes wouldn’t be recognized by the Finder-click feature because, in my drive to get the best performance, there was a case where I just optimized them out of existence. That’s been corrected.
Various bugs have also been fixed in the way Default Folder X handles Finder comments, cloud-synced folders, the icon of the Finder itself, and Save dialogs in macOS Sierra.
Release notes and download links are on the Default Folder X release page. Or if you’re already running Default Folder X, just choose “Check for Update” from its menu in your menu bar.
Version 5.5.9 of Default Folder X is available. One very significant improvement is its “reaction time” to bring up its controls when an Open or Save dialog comes up on the screen.
Under the hood, Default Folder X relies on notifications from macOS to alert it to the presence of a file dialog, and then queries the system to determine the dialog’s characteristics (whether it’s an Open or Save dialog, whether it’s a sheet or window, which folder it’s displaying, etc). In Big Sur, the system’s responses have become slower under some circumstances, resulting in a longer delay before Default Folder X’s controls appear around Open and Save dialogs. Version 5.5.9 streamlines the queries that Default Folder X makes to the system, resulting in a much quicker response after it’s notified that an Open or Save dialog has popped up – it’s nearly twice as fast as previous versions.
And in the process of analyzing Default Folder X’s performance to make it more responsive, I found some inefficiencies in the way it collects and organizes its lists of the windows open in the Finder (and Path Finder and ForkLift, if you’re running those apps). Those inefficiencies have been eliminated as well, reducing Default Folder X’s CPU usage and further improving its response time.
There are also a few fixes in the Finder-click feature to work around a bug in the macOS Finder: Default Folder X will no longer display some tabs of a Finder window as separate windows when the Finder returns incorrect data. In addition, you should now be able to reliably traverse DFX’s menus with the keyboard, and selecting the default folder item in the Favorites menu will work consistently.
Version 2.6.2 of App Tamer is available, fixing a couple of user interface bugs that could trip up new users. When newly installed, the size of App Tamer’s window was much smaller than it was supposed to be, making it hard to see the list of tamed processes. Compounding this was a change in version 2.6.1 that resulted in the mouse cursor not turning into a little arrow when you hovered over the edges of the window, so you couldn’t tell it’s resizable.
Another glitch, a result of changes that Apple made in Big Sur, could result in the names of processes being truncated in the process list. That’s been fixed as well.
You can find the full release notes and download links to App Tamer 2.6.2 on the App Tamer Release Page.
An experimental feature for a very specific system problem:
And now for the geeky, experimental feature: It’s come to my attention that some people are living with bugs in macOS that can result in essential background processes (like lsd and pkd) suddenly consuming tons of CPU time and bringing their Mac to a standstill. Despite chasing around to try and find the culprit, they often can’t resolve the problem without completely reinstalling the system. And apparently, App Tamer’s process throttling can’t limit the CPU usage without effectively disabling whatever function those processes are supposed to be performing.
So I’ve added a “runaway process assassin” to App Tamer. You specify which processes to watch, and if the CPU usage of any of them stays above a specified limit for a certain amount of time, App Tamer just kills the process. This certainly isn’t ideal, but works fine for system daemons that macOS will automatically relaunch whenever they’re needed. This feature is probably only useful to a few people, but because it isn’t something that’s easy to code up with an AppleScript or shell script, I figured I’d just add it. App Tamer is already collecting the CPU statistics anyway.
To configure this, you have to use Terminal. Paste in these commands, hitting the Return key after each one:
The first command turns on the killRunawayProcesses feature.
The second sets runawayProcessCPULimit to 50. You can set that to whatever CPU percentage you want.
The third sets runawayProcessTimeLimit to 20. This is how long (in seconds) the process has to be above its limit before App Tamer kills it.
The fourth sets runawayProcessList to watch lsd and pkd. You can add as many processes as you want here, separated by spaces. For full-fledged applications, use the app’s bundle identifier.
When App Tamer kills a process, it will put up a notification to let you know. You’ll probably want to make sure you’ve allowed App Tamer to display notifications in System Preferences > Notifications.
WARNING: Don’t turn this on unless you have a real need for it! You could potentially kill a service that’s necessary for your Mac to operate correctly. However, if you do need and make use of this feature, I’d appreciate hearing from you in the comments or at support@stclairsoft.com.
For folks that use Path Finder (an excellent Power User’s alternative to the Finder), you’ll be happy to know that Path Finder is now a fully supported alternative when you’re using Default Folder X. Anywhere that DFX integrates with the Finder, it will now use Path Finder if it’s running.
New in this release is the ability to add Default Folder X’s shortcut buttons to Path Finder’s toolbars. This lets you quickly pop up Default Folder X’s menus or slide out its drag-and-drop drawer by clicking a button in the toolbar.
Default Folder X also now “sees” all of the tabs in Path Finder’s windows. Every folder that you have in a Path Finder window will be shown in Default Folder X’s “Finder Windows” menu and highlighted by it’s Finder-click feature in Open and Save dialogs.
For those of you that _don’t_ use Path Finder, this release delivers a bunch of important bug fixes, so please don’t pass it up. Chief among them are fixes for the occasional disappearing cursor in Open and Save dialogs (finally), better reliability when switching between folders, and the elimination of a hang that could occur as Default Folder X was launching.
Download links and a full list of changes are available on the Default Folder X Release Page, or if you’re already running Default Folder X, just choose “Check for Update” from its menu to get the update.
Version 1.8.2 of Jettison is now available. It brings a number of improvements, including several fixes for problems remounting disks after they’ve been ejected.
Jettison’s error reporting has also been improved so that it catches edge cases where a disk unmounts after Jettison has been told by the system that the unmount failed. This should prevent those error messages that said a problem had occurred, but then didn’t list any disks in the error details.
For several releases now, Jettison has been quietly quitting Photos, iTunes and Music before it ejects disks, then relaunching them when those disks are remounted. This prevents problems for the many people that keep their photos or music on external drives. In doing this, however, Jettison was a little too aggressive: It quit the apps when you chose “Eject External Disks Now” from its menu as well as when the machine went to sleep. That turned out to be a Bad Idea, so now it’s only done before ejecting disks when the machine is actually going to sleep.
In a similar vein, there are now some preference settings accessible via Terminal to tweak this behavior. You can turn off the auto-quit / relaunch behavior using this command in Terminal:
where a whitespace-separated list of process names goes in place of photoanalysisd.
And yes, if these options prove popular, they’ll get their own place in the preferences dialog so you no longer have to use Terminal to set them up.
So anyway, this is available in Jettison 1.8.2, with details and download links on the Jettison Release Page. Or if you’re already using Jettison, choose “Check for Updates” from its menu in your menu bar.
Version 2.6.1 of App Tamer is now available! This maintenance release of our app for taking control of your Mac’s CPU and battery delivers a number of bug-fixes. It works correctly with the Origin game launcher, as well as with processes that are launched using ‘sh’ and ‘tcsh’ shell scripts (which some ‘normal’ applications do under the hood).
App Tamer 2.6.1 also prevents you from completely stopping apps that are distributed via the Setapp subscription service because that can cause issues with Setapp. If you want to reduce the CPU usage of those apps, simply have App Tamer throttle them to 1% CPU rather than completely stopping them.
And finally, this release allows you to make App Tamer’s process window smaller than its default size and keep it that way. Previously, it’d insist on enlarging the window back to its default size when you closed it and opened it again. Oops 🙄
In Big Sur 11.1, Apple introduced an annoying system bug that made Open and Save dialogs revert to a very small size every time you used them. To see anything in the dialog, you pretty much had to resize them. Every. Single. Time. Default Folder X 5.5.4 brought a fix for this – forcing the dialogs back to your preferred, larger size whenever they came up.
Fast forward to Big Sur 11.2, and Apple has fixed the bug so dialogs now stay larger once you resize them – yay! Well, mostly yay anyway. The sidebar still bounces back to its narrow, “I can’t read the names of my folders” width of about 100 pixels every second time you use an Open or Save dialog. <sigh>
So here’s Default Folder X 5.5.6. If you resize the sidebar in an Open or Save dialog, Default Folder X will make sure it bounces back to that size the next time you use the same file dialog.
In addition, this release expands support for HoudahSpot so that you now get the “Search in HoudahSpot” menu item in Default Folder X’s utility menu if you’re using the version of HoudahSpot included in the Setapp subscription service. It previously only worked with copies of HoudahSpot bought directly from Houdah Software.
And because someone asked for it, holding down the Option key while selecting a Folder Set from Default Folder X’s menu in your menu bar will open all of your Favorite folders in the Finder. So if you’ve got multiple Folder Sets for different projects or workflows, you can now instantly open all of those folders in the Finder when you’re starting work. (A few of you old-timers might remember that this was actually a feature in version 4 that didn’t make the jump to v5 – now it’s back!)
There are also a few bug fixes in version 5.5.6, as I’m still chasing after the elusive problem of the cursor sporadically disappearing on some Macs (but not others). Full release notes and download links are on the Default Folder X Release Page. Or just choose “Check for Updates” from Default Folder X’s menu if you’re already running it.
Version 5.5.5 of Default Folder X is now available for download. This maintenance release corrects a number of problems that have been reported recently:
Items in the drag zone and Finder drawer now expand to show longer file and folder names. By default, they’ll get marginally larger when necessary. You can, however, use the defaults command in Terminal to make them really big if you want. Just set maxDrawerContentWidth and maxDragZoneContentWidth to 200 or so.
Problems with the cursor disappearing in file dialogs on Big Sur have been corrected – because this didn’t get completely fixed in the last release 🙄.
Resolved a problem that could crash JetBrains apps like IntelliJ and GoLand. This was actually not a bug in Default Folder X, but a result of most Java apps not handling the macOS Accessibility API correctly (and hanging or crashing). Default Folder X now correctly detects that JetBrains apps are indeed written in Java and doesn’t add its enhancements to them.
Eliminated errors that were occurring when the Finder relaunched.
There’s also a fix to an unofficial feature: If you’ve got “Finder-click changes view mode” turned on in the hidden prefs window (Option-click on Preferences in DFX’s menu to get to it), clicking on a Finder window would sometimes set the wrong view mode. This was because Default Folder X would occasionally miss the fact that you’d changed the view mode of a Finder window. This has been fixed.
Download links for the new version and a less complete list of changes are on the Default Folder X Release Page. Or if you’re already running Default Folder X (thank you!), just select “Check for Update” from its menu in your menu bar.
Version 1.3 of Go64 is now available, adding some convenient controls for sorting through Intel vs Universal apps in addition to displaying which of your apps are 64-bit compatible (and which aren’t).
There’s also a new German localization, courtesy of Eberhard Woentz. Thanks Eberhard! 👋🏼 And a couple of bug fixes which may impact you if you use the contextual menus within Go64 or have backups of old iPhone apps laying around (I’m looking at you, Thomas Tempelmann). Thanks, Thomas, for bringing the problems to my attention.
I also changed the text in the UI to read “Not 64-bit ready” and “64-bit ready” rather than “32-bit” and “64-bit”. It better reflects the purpose of Go64, and also takes care of that gray area where really old stuff like PowerPC apps were being listed as “32-bit” – which wasn’t really technically true, but served the purpose of letting you know they wouldn’t run on Catalina or Big Sur.