Version 2.5.1 of App Tamer is available now. Among other things, it includes fixes for a couple of complaints with the “using too much CPU” notifications that App Tamer puts up when a process is – you guessed it – using too much CPU. It will no longer notify you if you’ve already throttled an app, even if the app is still over the warning threshold. It also provides a method of making the “Let it continue” button suppress the high-CPU notifications for longer. The default is now 10 minutes (instead of 5) before you see another warning, and you can change that by using this command in Terminal:
where XXX is is the number of seconds to silence notifications.
And for those folks that want to automate control of their apps, a new “manage” verb in App Tamer’s AppleScript dictionary lets you create scripts so you can change settings on a schedule, change an app’s settings with a keyboard shortcut, or something AppleScript-y like that. Here’s an example:
That will slow Safari to 2% CPU usage when it’s in the background and will hide it after it’s been idle for 10 minutes. To see all of the options, open App Tamer’s dictionary in Script Editor.
This scripting ability is being used by some users to change settings for backups so they run with different CPU limits at night vs. during the day, and throttling background apps more aggressively during video calls. As they say, the possibilities are endless!
App Tamer 2.5.1 also includes a number of fixes for infrequently encountered bugs, such as incorrect behavior when the stats update frequency is set to “never”, and processes not appearing when they’re run from the Terminal using ‘sudo’ or ‘su’.
Version 5.4.5 of Default Folder X is now available to enhance your Open and Save dialogs even more. Default Folder X has always provided hierarchical menus that let you very quickly navigate to a folder or file you want, but sometimes those menus aren’t sorted the way you want them. To switch between sort-by-name and sort-by-date, just hold down the Option key before mousing over a menu or submenu – that can make it much faster to find what you’re looking for.
This release also addresses some performance issues if you’re using ARCHICAD or if you’re using screen-sharing while working from home. And there are bug-fixes, including a fairly common one for folks who access files on a NAS or server.
If you’re interested in App Tamer, Podfeet Podcasts just posted a great write-up about it. The article goes into more depth than our own App Tamer pages, and is a great introduction to its features and why you’d want them. It’s a few minutes’ read, and I highly recommend it if you’re interested in getting the CPU usage of your Mac under control!
Get 25% off all of our products during the Black Friday / Cyber Monday weekend! That includes Default Folder X, App Tamer, HistoryHound and Jettison. If you already own what you want, get gift licenses for friends and family to make their Mac-lives easier!
Just go to our web store and use the coupon code BLACKFRIDAY2019 when you check out.
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.
Go64 1.0.3 is available now – you can download it from the Go64 page. If you’re not already aware of it, Go64 is a free application that scans your Mac for 32-bit applications that will no longer work when you upgrade to macOS 10.15 Catalina.
The new version of Go64 will now show you Preference Panes that contain 32-bit code. It also properly skips apps that are built for non-macOS platforms even if they contain code to run on an Intel processor (this is for you, iOS developers).
Most importantly, however, version 1.0.3 provides a preference window where you can tell Go64 not to show apps that are located within specific folders.
In the image above, I’ve got an old copy of Microsoft Database Daemon selected – it’s part of Microsoft Office 2011, which I still have so I can test it with Default Folder X. I know it’s 32-bit but want to keep it around, yet I don’t want it shown in Go64’s search results.
To remove it from the results, I just drag the ‘Microsoft Office 2011’ folder shown in the path control (in the green square) to the ‘ignore list’ in the prefs window. That’ll remove it from the results quickly and easily, even though Office 2011 is still on my Mac.
This should make it easier to clean out your list of 32-bit only apps so you can focus on the ones you need to upgrade. Note that you can also drag a single app into the ‘ignore list’ if you just want to remove one app rather than all apps within a folder.
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!
Houdah Software released a major upgrade of their excellent Spotlight search utility, HoudahSpot 5, last week. Among a ton of useful new features, HoudahSpot now also integrates with Default Folder X, giving you a much more powerful way to search for files and folders in Open and Save dialogs.
Just select “Search with HoudahSpot” from Default Folder X’s Utility menu
When you’re in a file dialog, Default Folder X provides a menu command to quickly search the currently displayed folder in HoudahSpot. This gives you the flexibility to search by file type, tags, content, modification date, or any other parameter you can think of.
And use HoudahSpot’s “Default Folder X” menu to send a search result to a waiting file dialog
Once you’ve located the file you want in HoudahSpot, Control-click on that file and use the “Default Folder X” menu to finish the round trip and send it back to the waiting file dialog (in Preview, in this case).
I’m happy to have had the chance to collaborate with Pierre Bernard, HoudahSpot’s developer, on this workflow. It delivers more convenience and time-savings to all the folks that use both HoudahSpot and Default Folder X.
If you have ideas for similar connections between your favorite indie applications, let the developers know – many of us are very receptive to your suggestions. Default Folder X also integrates with ForkLift and Path Finder, for example, because lots of people asked for it!
Jettison 1.7.1 is available, bringing fixes for a couple of simple problems and one complicated one.
Simple stuff:
The previous release of Jettison didn’t correctly show that it was licensed when you looked in the About box after importing a Mac App Store license. This was understandably very confusing to those of you that followed the instructions for upgrading in the FAQ. It now correctly shows “Licensed to: Mac App Store User” (since Apple doesn’t provide a way for us to get your name or Apple ID from your license) and removes the “License” item from its menu.
Also, there were occasions when all of the items in Jettison’s menu would become grayed out. This turned out to be caused by its error window getting stuck behind an application that was in Full Screen mode. It was patiently waiting for you to respond to an error message you couldn’t see – definitely not very helpful. That’s been fixed now.
Messy issues with Power Nap and Wake for Network Access:
When Power Nap or Wake for Network Access are turned on in your Energy Saver prefs, macOS may wake from sleep in ‘dark mode’ – which means it wakes from sleep, but never turns on the display. When this happens, it doesn’t let most applications – including Jettison – know when it wakes up or goes back to sleep. That means that Jettison can’t mount or eject your disks as it’s supposed to.
This would all be well and good if this temporary wakeful state mounted your disks, did its thing (like a Time Machine backup), ejected the disks and then went back to sleep. Unfortunately, while it seems to (mostly) work with Time Machine disks, if other drives get mounted during dark wake, you’ll often see a “Disk not ejected properly” error for them when you return. macOS can’t always manage the mounting and ejecting of disks correctly, even when it’s all by itself in a dark room.
Jettison 1.7.1 solves this problem by refusing to let macOS mount any non-Time Machine drives during a dark wake. This should take care of the disk errors (and associated possibility of data corruption) while still allowing you to use Power Nap and Wake for Network.
On the outside chance that you’re actually getting error messages for your Time Machine drive too, you can launch Terminal and run this command:
That will tell Jettison to prevent your Time Machine drive from being mounted during dark wakes – with the obvious consequence that Time Machine can’t run Power Nap backups while your machine is sleeping. It’s a compromise, but at least it’ll ensure that your backups don’t get corrupted.
