Archive for the ‘Development’ Category

Default Folder X 5 Progress Report

Friday, October 16th, 2015

Wow – I’m getting inundated with email and tweets asking what the status is and when it’s going to be done. It’s great to hear from everyone and I’m sorry to keep you waiting. Some bits have taken quite a bit longer than I expected :-/

So, taking a break from coding for a few minutes, here’s a summary of where things are:

  1. DFX5Shot File dialog stuff is all working except for handling default folders. Recents, favorites, hierarchical menus and the new drag and drop bar work well. Here’s a quick screenshot of what’s on my screen today (that’s the tagging view showing below the dialog, including recently used tags, and the drag and drop bar on the left).
  2. DFX now also automatically adds a button to your Finder toolbar, and clicking it slides out the drag and drop bar below the current Finder window. This lets you toss a file into the bar, switch to another Finder window, and then drag it to where you want it.
  3. There’s more information in the attribute tabs below the file dialogs and it all works more smoothly than it did in v4 (and the code is way better now – much easier for me to work with!).
  4. Update checking just went in – it wasn’t hard, but just hadn’t been on my hot list until I got all DFX’s basic features working and debugged well.
  5. So what’s left? The big thing is getting the preferences finished. There’s a lot of configurable stuff under the hood (the menu structure, shortcuts for a ton of things, etc), but I may hold off on actually putting that in the prefs due to the amount of time involved. Other things: I have to drop in the licensing engine and get the upgrade process put together (both for licensing and upgrading from old prefs).
  6. There are still a lot of features and suggestions on my To-Do list, but I’m making sure the fundamentals work well for the first release and getting it into people’s hands as quickly as possible, given how much feedback I’m getting that you just want that stuff to work on El Capitan first and foremost.
  7. Oh, and yes, there’s the appearance… This is what I’ve got now, and like v4, version 5.0 will probably ship with one appearance. Then you’ll all send me hate mail about what you think of the new look and I’ll add other appearance options (including something that takes up less screen real-estate).

I’m trying to balance features with getting it into your hands ASAP.

So the bottom line? We’re half way through October and it’s not feature-complete, so it’s not going to be fully tested and done by the end of the month, as much as I’d like it to be 🙁 But I’ll have a public beta in your hands by the end of October that will be solid and will get your workflow sped back up again.

OK – back to work….

Default Folder X and El Capitan

Friday, July 10th, 2015

ElCapitanScreenshot2 As some of you have undoubtedly noticed since installing beta 2 of El Capitan (aka Mac OS 10.11), the current version of Default Folder X is not compatible with the upcoming OS X release. The Default Folder X background application will run, but cannot enhance the file dialogs of many applications.

To dip into the technical side a bit, this is due to Apple’s new System Integrity Protection, which prevents Default Folder X’s scripting addition from loading into some applications and, most importantly, into the “PowerBox” helper app that presents Open and Save dialogs for all sandboxed applications.

Never fear, however – Default Folder X isn’t dead. I’ve been hard at work on a major revision of Default Folder X that will support El Capitan (yes, I saw this coming). It uses a completely different method for enhancing your file dialogs, and adds a number of handy new features and changes that you folks have requested.

I don’t yet have a firm release date – to be honest, I may have to scale back in a few places to get this into your hands before El Capitan ships, but it’s on the way. The upgrade will be free for anyone who purchases Default Folder X in the 6 months before the new version is released, which means if you buy now, you won’t be paying again for version 5 in a few months.

More news as things develop – for now it’s back to Xcode for me…

– Jon

P.S. And yes I KNOW the website relaunch is way overdue, but software comes first.

P.P.S. For more on System Integrity Protection, read Glenn Fleishman’s article at

New Jettison 1.5b4 public beta

Sunday, June 28th, 2015

For those of you testing (or interested in testing) the new version of Jettison, I’ve got a new build that corrects some timing issues with driver reloading and with the handling of SD cards. Grab it at:

Public beta of Jettison 1.5 – new and improved!

Wednesday, June 17th, 2015


After a lot of restructuring, debugging, testing and wrangling with various types of disks, Jettison 1.5 is close to finished. It handles ejecting and remounting more smoothly, and includes a workaround for situations where the old version failed to eject drives at sleep time because the screen was locked.

What I need now are some volunteers to do some final testing to make sure Jettison works well in all situations. If you’d like to try it, just download a copy here:

Once you’ve installed it, drop me an email at to let me know you’re testing it, then send any issues or questions to the same address if you encounter anything.


– Jon

Default Folder X : Making space for longer filenames

Friday, March 27th, 2015

Notice anything different about the “Save As” dialog below? I’ve highlighted part of it in red to give you a hint 🙂

The edit field for the filename is much wider than usual – you can actually see the entire (long) name that Safari supplied for me. I’ve gotten a lot of requests for this in the past, but haven’t been able to make it happen until now. If you’re interested in trying it out and giving me feedback, I’m busy testing it and could use your help.

The details:

  • This is a Yosemite-only feature at the moment
  • It’s only been tested with a handful of applications and needs more exercise
  • If it doesn’t work in some application, the results shouldn’t be awful – some UI items will just be misplaced

If you’d like to help out (or are just anxious to get your hands on this) you can download this pre-release version of Default Folder X:

Please send your feedback to


– Jon

App Tamer 1.3.2: Retina displays and background scrolling

Tuesday, January 15th, 2013

Version 1.3.2 of App Tamer is out, sporting high resolution graphics for all you lucky Retina Display owners. It also lets you scroll the windows of applications that are stopped in the background. This lets you read web pages while Safari is in the background, for example, even if you have App Tamer’s AutoStop feature set to stop it so it doesn’t use extra CPU time.

I’m also excited about an upcoming feature I’m working on for App Tamer 2.0. It lets you set a maximum amount of CPU to give an application – it doesn’t stop the app, but just slows it down if the app starts sucking down too much processing power. I’ve found it very useful in keeping Spotlight from taking over my machine while I’m working, and limiting churn from other applications that inevitably spike the CPU right when I’m trying to get something done. It’s still in need of a lot of integration – the feature works but there isn’t any real UI for it yet (it currently just limits Mail, mds and the Finder to no more than 10% CPU as a proof of concept). It’s very cool to watch it do its thing, though!

Default Folder X 4.5b8 Corrects Mountain Lion Issues

Friday, October 5th, 2012

A new public beta of Default Folder X 4.5 is available, resolving a number of issues that have been occurring when running under Mac OS 10.8.2 “Mountain Lion.” It fixes problems with Default Folder X appearing intermittently or refusing to respond to mouse clicks when you use it. It also properly accesses iCloud items, adds support for additional applications, and resolves a number of bugs.

Complete details and download links are on the Default Folder X Beta Testing page.

Default Folder X 4.4.7b1

Sunday, November 6th, 2011

We’ve put up a quick public beta just to make sure there are no lingering problems with Default Folder X 4.4.7. I finally tracked down the issue that’s been dogging us since Lion’s release – the beta should cure any remaining compatibility problems (namely with Bias Peak and Apple’s Keynote, but there may be others, including GraphicConverter and System Preferences).

Please take the time to download a copy from the Default Folder X Testing page and put it through its paces. Your feedback will really be appreciated.


– Jon

Get your permissions right!

Wednesday, March 30th, 2011

Thought I’d post about this little developer experience because it was incredibly frustrating and not at all obvious. Maybe this will save someone else the headache that I’ve been through.

Background: When preparing an application for release on the Mac App Store, you code sign your application, then bundle it into an installer pkg which is also code signed (using either Xcode organizer or the productbuild command line tool). When the application is installed, it gets extracted from that .pkg file, the user runs it, and it checks for a Mac App Store receipt. If there’s no receipt, OS X checks to make sure that the application is signed correctly, then contacts the Mac App Store to get your receipt.

Problem: This would all work for me as advertised except that when the receipt check failed, OS X would complain that my application wasn’t code signed, and therefore wouldn’t contact the App Store to get the receipt. From a user’s perspective, the app would just fail to launch.

I’d followed all the instructions. I double- and triple-checked to make sure the application was signed before I built the .pkg file. I tried building the .pkg using both the Xcode organizer and productbuild – they both worked with no problems or error messages. Yet when the application came out of the .pkg file on the other end, it was always unsigned! I deleted all of my certificates, regenerated them, and redownloaded them from Apple’s developer site (several times). I checked every step along the way in my build process – they were all working. It was incredibly frustrating because the signed app went into the ‘black box’ of the .pkg file just fine, but came out on the other end without its code signature.

Solution: After tearing my hear out for a while, googling for answers, and checking the developer forums, I finally tracked down the solution. I had a single image file in my application’s resources that had its permissions set to 640 instead of 644, meaning that it was not readable by everyone. That threw the entire game off – apparently when the installer unpacked the .pkg file, it ran into this problem file and either stopped short of installing the code signature, or invalidated the signature.  Either way, the application it installed was useless.  Simply changing the permissions on that one tiff file fixed the problem I’d been fighting with for days.

Soooo….  If your app builds and runs fine UNTIL you package it, and then comes out unsigned on the other end, check the permissions on the resources in your application.  And Apple, please emit some kind of warning when hapless developers feed productbuild a file with the wrong permissions that’s gonna screw up the whole process.

Tip: There’s a really cool developer utility called Cong, written by Stephane Sudre.  It checks your application for all kinds of minor errors, from localization goofs in .strings files to incorrect Info.plist entries to missing files in your package.  I’ve contacted Stephane and checking file permissions is now on his To-Do list for Cong.  If you’re a developer, get a copy of Cong – a simple drag-and-drop could save you a lot of time and trouble!

App Tamer almost finished!

Friday, September 10th, 2010

So I’ve been working on this little application that fixes an annoying problem in OS X.

You may have noticed that the remaining battery life on your MacBook Pro (or whatever laptop you have) often plummets if you leave Safari displaying an ad in the background. That’s because most web browsers, as well as a number of other apps, continue running tasks or animations even when they’re sitting idle in the background. This can be pretty frustrating if you’re actually trying to conserve battery or use that CPU power for something useful.

I wrote App Tamer to fix this.  It pauses apps in the background to prevent them from chewing up CPU time (and battery life). I know, I know – you’ve probably seen some utilities that do this already. BUT – here’s the cool part – App Tamer stops and starts applications automatically. You don’t have to distract yourself by manually stopping and starting applications – it just magically works.

Have a look at the App Tamer page for details.  It’s in the final stages of beta testing, and you’re welcome to download a copy of the latest beta and try it for yourself. Let us know what you think at