May 11th, 2017 by Jon
TLDR; Get Default Folder X 5.1.5 here. Default Folder X now shows its bezel around minimized Save dialogs and fixes crashes and compatibility problems, especially with old Carbon apps like Office 2011 and Adobe Creative Suite 6. It also addresses issues with particular shortcut key combinations and works better with Spaces.
For Those That Want Details: ‘Minimized’ Save As dialogs have been a problem for Default Folder X for some time. Because of the way macOS El Capitan and Sierra work, DFX can’t provide all of its features in a Save dialog if there’s no list of files and folders. Up until now, Default Folder X would simply not appear next to minimized Save dialogs. This caused confusion, with some people thinking that DFX wasn’t working at all, when in fact it just couldn’t do anything in that particular situation.
I kept revisiting this issue over and over again to see if I could find some sort of technical solution that’d let me get Default Folder X working in this configuration. Alas, it’s not to be – there are some fundamental limitations that prevent Default Folder X from working. So in version 5.1.5 I’ve put together a simple bezel that comes up around minimized Save dialogs and offers a single option: expanding the dialog so that Default Folder X can provide all of its features. It isn’t ideal, but it’s less confusing than just having Default Folder X missing in action when you click the minimize button in a Save dialog.
In addition to this change, Default Folder X 5.1.5 addresses a number of compatibility and stability issues (ie. bugs). I’m actually very happy to have found the source of a recurring crash that I’ve never been able to reproduce. Crash logs have been trickling in, but none of them actually pointed to the underlying problem. I’ve now found a bug that appears to be the cause of those crashes, and have also addressed bunch of other issues that have come up since the last release.
A change list and download links are available at http://www.stclairsoft.com/DefaultFolderX/release.html
April 5th, 2017 by Jon
With today’s release of App Tamer 2.3.2, you can now resize App Tamer’s window to display more processes on larger monitors. This version also fixes a couple of nagging bugs that could cause App Tamer to think it was slowing down a background process when it actually wasn’t. If you’ve ever looked at the process list and seen a background daemon pegged at 100% even though App Tamer shows its yellow “slowed down” icon next to it, this release will fix that 🙂
The 2.3.2 update is free for licensed users of App Tamer 2.x. You can see the detailed release notes and download it on the App Tamer release page.
March 24th, 2017 by Jon
Version 5.1.4 of Default Folder X is out, and although this update doesn’t bring any big feature additions, it offers a bunch of internal improvements that make things more reliable. If you’re already using Default Folder X, just select “Check for Updates” from the Default Folder X menu in your menubar to get the new version.
And if you’ve experienced a crash in Default Folder X and submitted a crash log after it happened, thank you for taking the time to do so. That data really does help track down problems and get them fixed! If you’re having a problem that doesn’t result in a crash, contact us using the Tech Support page and we’ll do our best to get the issue resolved, whatever it happens to be.
March 17th, 2017 by Jon
Default Folder X was mentioned on Dave Hamilton’s excellent Mac Geek Gab podcast. It made me laugh so I have to share it. At the end of the segment Dave says “Using a Mac without Default Folder feels like using a Mac with mittens.” I think that’s one of the best endorsements I’ve heard in a while 🙂
Anyway – check it out – along with lots of other great information and commentary – at the 1:20 mark of Mac Geek Gab 647. I think I learn something new in every episode.
March 2nd, 2017 by Jon
While Jettison and HistoryHound are still supported and sold on the St. Clair Software website, I’ve pulled them from the Mac App Store. The versions that were in the Mac App Store were older revisions, and it just didn’t make business sense to rearchitect the apps to meet Apple’s current requirements for approval so they could be kept up-to-date.
For both applications, complying with Apple’s sandboxing and feature constraints to get them approved for sale would have required significant rewrites. And in Jettison’s case, it would also require that buyers download a separate helper app to enable its full functionality. I realize that some people will be put off or inconvenienced by the fact that these apps are no longer in the Mac App Store – my apologies if you’re one of those folks, but it just doesn’t make sense for Jettison and HistoryHound.
Without going into a full-on rant about the Mac App Store (I could ramble on for days), let’s just say that while the Mac App Store is convenient for consumers, it doesn’t really serve the needs of some developers. Much has been written about it already (here, here, here, here and here, for example) so I won’t rehash it all – and despite years of “constructive criticism” from developers, Apple hasn’t fixed some major problems.
I hope you’ll continue to purchase our applications, as well as those from other independent developers selling outside the Mac App Store. While it’s a little less convenient than the Mac App Store, it allows us to bring you the best software we can, and also gives us the opportunity to foster a two-way relationship with you – both of which really matter to us.
March 1st, 2017 by Jon
Version 2.3.1 of App Tamer fixes several bugs in our CPU- and battery-saving application, as well as more smoothly supporting Spotify. If you’ve got App Tamer set up to manage Spotify’s CPU usage, it will not slow it down or stop it while Spotify is playing music. This prevents your music from stuttering or going completely silent – generally a good thing 🙂
You can find more details and download links on the App Tamer Release page. We recommend that all App Tamer users update even if you don’t use Spotify because the bug fixes are important.
And on the topic of App Tamer, I was remiss in my duties – I didn’t blog about the release of version 2.3, even though it delivered a couple of very significant changes. The most obvious one is a user interface overhaul that brings App Tamer up to snuff with the flat, white look that’s all the rage (check it out over on the right there). The preferences have also been split among multiple tabs to better organize them, and hopefully make all the settings a little less intimidating.
A more interesting, though much less visible addition is App Tamer’s new “CPU hog detection” feature. In the “Detection” tab of the preferences, you can set a limit to how much CPU any application should use. If any app uses that much CPU for longer than a time you specify, App Tamer will pop up a warning to let you know that something’s amiss, and will give you several options. If you’re on a laptop, this is great because it lets you know before the CPU hogging app drains your battery down to nothing and you realize that you left your power adapter under the couch at home.
And of course there are a whole bunch of little fixes and improvements rolled into versions 2.3 and 2.3.1 as well. It’s worth the trouble to download, especially if you’ve already bought a license for App Tamer 2 because these updates are free.
February 28th, 2017 by Jon
This is information I originally posted back in 2009, but here we are 6 macOS versions later and it’s still relevant – and people are still asking for it.
Below are details on how to create a “Move Items” contextual menu item in the Services menu in the Finder (see the picture below). It uses Default Folder X to specify the destination folder, giving you access to all of your Favorite and Recent folders.
TL;DR: If you just want to get things to work, there’s a link at the bottom to download an already-built Automator workflow.
Contextual menu items are added by making a Workflow in Automator and saving it as a Service. You start by running the Automator application (it’s in your /Applications folder), creating a new Workflow, and setting it up as shown in the (old) screenshots below:
If you’re experienced with Automator, you’re probably asking: Why go to the trouble of creating variables instead of just using the “Move Finder Items” action by itself? I’m glad you asked! The reason is that I want to bring up a file dialog to specify the folder where I want the items to go. There’s not a clean way to have the “Move Finder Items” do that every time. You can change its options to “Show this action when the workflow runs” but you still have to click on it every time you use it to ask it to show a file dialog. If you use Default Folder X to enhance your Open dialogs, it’s faster to just have the dialog pop up and then go where you want to with DFX.
So in the image above, the workflow puts the current Finder selection into the “selection” variable. Then it uses AppleScript to bring up a file dialog to ask for a folder, which it stores in the “path” variable. And finally, it uses the Move Finder Items action to do the work. Not too much more complicated, and it speeds up your workflow considerably if you’ve already got DFX installed so the Open dialogs are smart.
For you Automator programmers, note that some of the actions shown in the workflow do not take inputs. I did this by control-clicking on the action (“Get Value of Variable”, for example) and choosing “Ignore Input” from the contextual menu. If you don’t do this, Automator will actually add the input from the previous step to the next one, which is definitely not what you want in this case.
Oh, and if you just want the automator workflow file so you can add it to your own system, you can download it here:
If you need more help with Automator and Services, Sal Soghoian has some good information and tutorials here:
(Once you’ve gotten through the first few steps of the tutorial, you should be able to just replicate the picture above to make the Move Items service yourself).
December 30th, 2016 by Jon
So I’ve noticed in Sierra that some of its “helper processes” (apps that run in the background to do various tasks) will occasionally start using 100% CPU for no reason. In particular, I’ve seen the com.apple.appkit.xpc.openAndSavePanelService process stay pegged after a file dialog is done – it just sits there and consumes CPU while doing nothing. Quitting the app that was showing the file dialog will stop the CPU-hogging, but it otherwise continues indefinitely.
I’ve been wondering if this might actually be the source of the much-talked about Consumer Reports findings that the new MacBook Pros have very inconsistent battery life. Their results varied widely from test to test (on the same computer) – maybe one of the WebKit helper processes was just flipping out once in a while due to some underlying bug in Sierra’s interprocess communication or process management services.
While that’s just my own random speculation, the issue of processes running amok seems to be a recurring annoyance to some folks. To help you detect this sort of stuff, I’m adding an option in App Tamer to notify you if a process starts consuming excessive CPU time. If it does, it gives you the options shown in the screenshot.
Can’t hurt, right? Shoot me an email (AppTamer at stclairsoft dot com) if you’re interested in trying it out and doing a little testing for me.
December 16th, 2016 by Jon
So I’ve run into this issue both as a user and as a developer – on MacBook Pros that have both a discrete and integrated GPU, fancy animations will cause the system to switch to the more powerful discrete GPU, reducing battery life. Chris Liscio wrote a great post explaining what’s going on and what to do about it (from a developer’s perspective). The key takeaway for most developers:
This whole problem can be very easy to solve. You just have to set
NSSupportsAutomaticGraphicsSwitching key to
YES in your application’s Info.plist. The trouble is that an OpenGL context is being created, which defaults to switching the dGPU on. Enabling this flag in the plist will very likely fix the problem on its own, as the frameworks should Do the Right Thing (more details below) if they need access to OpenGL.
Go read his whole post for all the details.
December 13th, 2016 by Jon
Default Folder 5.1 is now available, and includes a long list of changes. Key among them are new commands that let you copy, move, and make aliases to files and folders right in your file dialogs. Want to save a copy of that file to your Desktop folder before you make changes to it? Just use the Copy command in Default Folder X’s toolbar and choose the Desktop as its destination.
Default Folder X will now also mirror all of your favorite folders, recent folders and recent files using aliases in your Library folder. If you use another file management utility like Path Finder, Alfred, LaunchBar, etc for quick access to files and folders, you can connect it with your Default Folder X data by pointing it to these folders:
There are other convenient additions as well, like the ability to change the creation and modification dates of files and folders, and Command-selecting an item from a Default Folder X menu to reveal it in the Finder.
And as usual, there are also compatibility improvements and bug fixes – quite a lot of them this time. While Default Folder X has been performing very well for nearly everyone, the automated crash logs have uncovered a handful of infrequent but persistent problems. I’ve done a lot of stress-testing and debugging to ferret them out, making this release more reliable – and thereby less annoying for both you and me 🙂
For a complete list of changes, bug fixes and download links, check out the Default Folder X Release page!