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.
HistoryHound 2.2 is now available, giving you the option to add its icon to your menu bar so you can search your browsing history even faster.
HistoryHound still finds text in all the pages you’ve visited in any of the major Mac web browsers, but now handles Chrome and Firefox power users better. If you use multiple user profiles or run both Firefox and Firefox Developer Edition, HistoryHound will now track and search your history more efficiently and accurately.
This release also eliminates delays that could occur when you have HistoryHound set to “search as you type,” and adds a contextual menu to its error window so you can quickly add filters to keep certain pages from being added to your search index.
Version 5.4.3 of Default Folder X, our app for managing files and folders in Open and Save dialogs and the Finder, is now available. This release speeds things up when opening items in the Finder, ForkLift and Path Finder, as well as when saving files to slow servers over a network. It also brings little improvements in several areas:
The on-the-fly previews (the ones you see when traversing Default Folder X’s menus, in its Finder drawer, and in Open dialogs) have been improved to look better and display more smoothly.
It’s now easy to make Default Folder X forget all of your recently used files, folders and Finder windows all at once. Just hold down the Option key when choosing “Forget Recent <whatever>” at the bottom of a menu, and the menu command will change to “Forget All Recent Data”.
For any AppleScripters out there, there are new commands for managing files and folders in DFX’s Finder drawer, and an option to pop up its menu at a specific screen location. Note that if you’re using a macro utility that can run AppleScripts (like Peter Lewis’ excellent Keyboard Maestro), this can make it really handy to get to Default Folder X’s menus without going up to the menu bar.
There are also more than a dozen bug fixes, covering everything from occasional reliability issues to more esoteric problems with Pro Tools, Rogue Amoeba’s Fission app, and the built in screen capture utility in Mojave and Catalina. Oh, and Default Folder X’s Finder-click feature will now recognize all the tabs in Finder windows that aren’t in the current Space (if you’re using Mission Control to manage multiple workspaces). That was a really weird one.
Itemized release notes with all the details are available on the Default Folder X Release page, as usual, along with download links.
Version 2.5 of App Tamer is available, addressing a number of issues with different web browsers.
It adds default settings for Microsoft Edge, throttling Edge to 2% CPU when it’s not in the foreground.
It also fixes issues with Chrome apps that run as separate processes (created by saving a Chrome Shortcut with the “Open as window” checkbox turned on), making sure that Chrome is left running at full-speed when a shortcut app needs to run unhindered.
Performance problems have been resolved when site-specific browsers created with Epichrome are running. Previously, their reliance on frequent, repeated calls to shell commands was causing App Tamer itself to use too much CPU.
And finally, site-specific browsers created with Coherence Pro can each have their own settings in App Tamer, rather than all being managed with the settings you’ve given to Chrome.
Full release notes and download links are available on the App Tamer release page, or by choosing “Check for Updates” in App Tamer if you’re already running it.
Version 2.4.8 of App Tamer is available. It now explicitly supports the new Music app in Catalina, meaning that if Music is playing something, App Tamer won’t slow or stop it even if it’s in the background.
Create a Chrome App using “More Tools > Create Shortcut…” in Chrome
This release also adds support for Google Chrome ‘Apps’, which you can create in Google Chrome by using the More Tools > Create Shortcut item in the “…” menu in a Chrome window. If you select “Open as window” when creating the shortcut, Chrome creates a separate application that relies on Chrome to render its window. That means that App Tamer needs to (and now will) keep Chrome running, rather than slowing or stopping it, when you’re using one of these separate Chrome apps.
And finally, version 2.4.8 of App Tamer also corrects several issues with its process control mechanism that could result in it not working correctly after your Mac wakes from sleep.
Version 1.7.3 of Jettison is now available. It fixes a problem when running on Apple’s latest Catalina beta where it would try to eject Catalina’s new system data volume if the system was running from an external drive.
In addition, Jettison 1.7.3 also improves its error reporting and handling, allowing you to quit applications that are preventing a disk from being ejected. This release also addresses an occasional problem with disk images not getting completely cleaned up after being ejected.
More details and download links are available on the Jettison Release page. If you’re already running Jettison, just choose “Check for Updates…” from its menu in your menu bar to update to the new version.
Version 2.4.6 of App Tamer is available, adding preliminary support for macOS 10.16 Catalina (up to the second developer release, anyway, because that’s what we’ve got at present).
It also fixes a little bug that I personally found really annoying: When Spotlight was indexing files, App Tamer showed all of the Spotlight processes separately, often filling up half of the visible process list with Spotlight stuff. It now does what it’s supposed to do, aggregating all the CPU usage in one “Spotlight Indexer” entry and controlling that as if it’s a single process. That gives you better control over Spotlight’s CPU usage and makes CPU-hogs easier to see (I’m looking at you, Spotlight!).
This release also introduces a new setting in App Tamer’s preferences. In the Control tab, there’s now a way to modify how long it waits before managing processes after it launches or wakes from sleep.
This lets you give all processes a little time to run at full speed to get everything synced up after your Mac wakes up, usually making that happen a little faster.
Version 2.4.5 of App Tamer is a fairly tame release – it corrects a few nagging bugs, and is now checked for malware by Apple and notarized to indicate so. The menu bar icon shows its disabled state more clearly when running in Dark Mode on Mojave, and some processes were mistakenly listed in the “Managed Processes” list even though App Tamer wasn’t managing them (ironically, because of bookkeeping error, they were included in the list because App Tamer never touched them at all).
Default Folder X 5.3.7 is now available, and it displays a couple of additional pieces of metadata in the Info panel below Open dialogs, most notably the “last opened” date. It also addresses a number of issues, including problems with LaunchBar, sub-par behavior when file dialogs are very large or lie partially off-screen, keyboard shortcuts not working after using a menu bar app, and drag-and-drop problems with the Finder drawer. A full list of changes is available on the Default Folder X Release page or in the Version History.
This version also works around bugs in Mojave that have been affecting Default Folder X’s ability to list open Finder windows when those windows contain multiple tabs. It will now list those windows reliably, but may still get confused and show some tabs as being in their own, separate windows – but hey, at least they’re all there, right? Unfortunately, a complete solution requires that Apple fix the bugs that I’ve submitted.
And one very important note about Finder windows: The behavior of Default Folder X’s Finder-click feature has changed a bit. Most people won’t be affected by this, but if you have been relying on the fact that Finder-click showed windows that weren’t actually visible (because they’re in another Space or because the Finder’s hidden), you’ll find that they’re no longer appearing. They’re still in the Finder Windows menu in Default Folder X’s toolbar, or you can revert to the old behavior by following these instructions.
Finally, on the truly geeky side, you can now create an AppleScript to supply Default Folder X with a default folder for an application on the fly. When a file dialog comes up, DFX will run your AppleScript, and if it returns a folder, that’ll be used as the default folder for that file dialog. It works seamlessly and can really simplify things if you work in a project-based manner with a consistent way of determining where your project folder is. Look for a blog post about this shortly.
Brent Simmons has a great post over at inessential.com on the genius of Apple events. As one of the people behind the ground-breaking Userland Frontier, Brent is uniquely qualified to espouse on the significance and power of Apple events. Frontier, and later AppleScript, leveraged Apple events to let Mac users tie together applications to make workflows that got real things done, even when no single application existed that would do what they needed. I used Frontier for years to automate the back-end of my software business – it was invaluable.
As Brent says:
Picture Jane in her office. She gets an email from Bob every month with the latest WidgetX numbers. With that email in front of her, she double-clicks a script (or chooses one from a scripts menu)… [which] updates and saves (on a shared folder) a Keynote presentation with the new numbers.
This used to take hours, and it was prone to errors. Now it takes a minute or less — and it’s error-free
With Marzipan reportedly coming in macOS 10.15 this year, Apple is further de-emphasizing the cooperative nature of macOS apps, and will most likely not support Apple events in the “iPad apps adapted to run on the Mac” context of Marzipan. Again, from Brent:
What happens to Jane if Mail is a Marzipan app that doesn’t respond to Apple events?
Indeed.
And as Brent says (and as I detailed in an earlier post), many Mac apps use Apple events to directly integrate with other applications. They tie everything together for you, taking your Mac experience from ‘good’ to ‘great’. Just in my own apps, Default Folder X communicates this way with the Finder, Path Finder, ForkLift, Terminal and iTerm2 to give you seamless access to folders no matter where you need them. App Tamer uses Apple events to make sure it doesn’t interrupt iTunes and Spotify when they’re streaming music for you. And there are numerous other examples throughout the Mac ecosystem (and probably on your Mac right now).
Losing Apple event support in Mac applications would be a bigger loss than a lot of people realize – and one I’m not sure Apple is completely cognizant of. My hope is that there’s someone back there minding the proverbial store, but my feeling is that Apple is rushing headlong to open up macOS to UIKit applications to get more apps on the Mac, without regard for some important underpinnings.
