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.
Default Folder X 5.6b4 is now available. It’s a public beta release that adds compatibility with Apple’s latest macOS 12 Monterey betas, but also fixes issues on earlier versions of macOS as well.
The most important change is for users of 5.6b3, the previous beta release. That version would hang for 10 seconds or more (sometimes a lot more) after you resized a file dialog. That’s fixed in b4.
Other changes include a fix for instances where a top-level folder in Google Drive would get its “hidden” flag set by a bug (or feature?) in Google Drive, resulting in Default Folder X hiding folders or files within that folder in the Recent Folders and Recent Files history. Now Default Folder X just ignores that hidden flag. And I’ve added support for the Mac App Store version of PDF Studio Pro, an app DFX was refusing to enhance because it’s written in Java, and Java apps can sometimes crash because they don’t properly support the macOS Accessibility API.
As always, details and download links are on the Default Folder X Testing page. Note that the change history there includes a list of all the changes made since the last full release (version 5.5.9), if you haven’t been keeping up with previous beta releases.
A second public beta release of Default Folder X, Default Folder X 5.6b2, keeps it up to date with the latest macOS 12 Monterey builds from Apple.
It also fixes an issue that prevented Default Folder X from showing recent files and folders in your Dropbox folder if you turned on Dropbox’s syncing of your Documents and Desktop folders. In that configuration, Dropbox syncs your Documents and Desktop folders to a hidden folder within your Dropbox folder. Default Folder X, being the good citizen that it is, saw that hidden folder and said to itself “oh, if you’re putting files and folders into a hidden folder, you probably don’t want them shown in your Recent Files and Recent Folders menus,” and acted accordingly. Now Default Folder X will ignore the fact that that folder is hidden, showing those recent files and folders in its menus.
This beta build also enables DFX in the Flying Logic app and fixes a glitch in the way VoiceOver reads the path menu in Open and Save dialogs.
It’s June, which means Apple has begun rolling out test builds of the next version of macOS, dubbed macOS 12 Monterey. And that means we’ve got a public beta version of Default Folder X available, bringing Default Folder X’s file and folder organization chops to the new OS.
And if you’re not running Monterey yet, version 5.6b1 still addresses some issues with Affinity Designer and other Affinity apps, Photoshop’s “Export As” dialog, and Google Drive.
Don’t let your Open and Save dialogs go naked in Monterey – head on over to the Default Folder X beta testing page for details and a download link!
Version 2.6.3 of App Tamer improves its own efficiency, as well as addressing a few issues that have been brought up by users. When collecting and managing CPU statistics of the processes running on your Mac, App Tamer now uses two additional strategies to reduce its own processor usage. And on Apple Silicon-powered M1 Macs, its helper application (which is in charge of managing the CPU usage of other apps) schedules its work on the M1’s “efficiency cores”, which use less power than the CPU’s “performance cores”.
On top of that, several bugs and user interface issues were corrected to prevent settings for critical processes from being changed to values you really don’t want (trust me 😁), and fixing a rare issue with Amazon Photos.
With the recent focus on Default Folder X’s integration with Path Finder, I’ve been fielding a number of questions about how to make Default Folder X open folders in Path Finder instead of the Finder.
Using Path Finder instead of the Finder for all apps
The first, simplest answer is that Default Folder X uses your “default file browser” when opening folders. If you set your default file browser to be Path Finder, selecting a folder from Default Folder X’s menus will open it in Path Finder. This will also make all other apps on your Mac use Path Finder for their “Reveal in Finder” commands.
“But how the heck do I set Path Finder as my default file browser?” you say. Well, I’m glad you asked! It’s easy – there’s a setting in your Path Finder preferences:
Turn on this checkbox and you’re done.
Using Path Finder instead of the Finder – but just for Default Folder X
If you’d rather make this apply only to Default Folder X, you can set Default Folder X’s “fileViewer” preference in Terminal with this command:
Note that if you’re using the Setapp version of Path Finder, you should replace ‘com.cocoatech.PathFinder’ with ‘com.cocoatech.PathFinder-setapp’. To tell Default Folder X to go back to using the Finder instead of Path Finder, just replace ‘com.cocoatech.PathFinder’ with ‘com.apple.finder’.
Toggling between Path Finder and Finder on the fly
And finally, if you want to get really fancy and sometimes have Default Folder X open folders in the Finder and sometimes in Path Finder, you can set up an AppleScript to toggle back and forth. Attaching a script like this to a keyboard shortcut using Peter Lewis’ amazing Keyboard Maestro app makes it super-easy:
-- set the 'currentViewer' variable to the current fileViewer setting set currentViewer to do shell script "defaults read com.stclairsoft.DefaultFolderX5 fileViewer" -- now switch to whichever fileViewer is currently not in use if currentViewer is "com.apple.finder" then do shell script "defaults write com.stclairsoft.DefaultFolderX5 fileViewer com.cocoatech.PathFinder" else do shell script "defaults write com.stclairsoft.DefaultFolderX5 fileViewer com.apple.finder" end if
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.
