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!
November 17th, 2016 by Jon
Wait. Who? Sal Soghoian is Product Manager of Automation Technologies at Apple. That basically means he has been the motivating force behind AppleScript, Automator, application scriptability and the technologies that underly them. He’s been doing it for the last 20 years, and I don’t think most Mac users understand how important his influence has been to the platform we use and love. He’ll be leaving Apple on December 1, as his position has been “eliminated for business reasons.”
While I’ve met Sal several times, I don’t know him on a personal level. I’ve seen him speak numerous times, and like many long-time Mac developers, have benefited from his passion and consistent evangelism of system-level scriptability.
Why do I care? Indeed – why do we care about this? Well, let’s rewind a bit and set some groundwork for why Sal’s contributions matter so much.
Interoperability – from Copy/Paste to AppleScript. We all take copy and paste for granted – of course I can copy an image out of Photoshop and paste it into Mail, right? Well, it didn’t always work so easily – the Mac was the first major platform that standardized that by providing system-level support for standard image types and an extensible way to move them between applications. The key was that it was natively supported by the system, so developers could add it to their apps and it worked the same way, with the same basic data formats, in all applications. You could copy and paste between any applications.
Like copy and paste, in 1993 Apple added system-level support for scripting. Instead of every developer inventing their own, custom scripting language that only worked in their application, Apple created AppleScript – and more crucially, AppleEvents beneath it that provided a rich way to send commands and data from one application to another. Many applications have scripting dictionaries built into them, letting you, or any application, send commands to do useful stuff.
Anyone can create simple or hugely complicated AppleScripts to do all sorts of things – from changing the format of all image files in a folder to automating email handling to batch-processing audio and video clips for movies. You can use all the best-of-breed tools on the Mac and string them into workflows that meet your specific needs. That’s always been one of the Mac’s big advantages – you can combine applications to accomplish more than any of the individual apps can do themselves. Apple’s Automator application even tried to make this accessible to everyone – with varying levels of success, depending on who you talk to.
But I don’t use AppleScript. So I don’t care, right? You may not directly use AppleScript, but many applications use AppleScript or AppleEvents in lots of little ways. iTunes, for example, lets you pause, play, go forward and backward a track, change playlists, add properties to songs, and a zillion other things. Those little iTunes controller apps that live in your menubar or dock? They use AppleScript to talk to iTunes. The ones that add lyrics to the currently playing song at the push of a button? Yup, AppleScript. Applications that grab the current page from your browser? AppleScript. The “contact us” button in an app that automatically creates an email in Mail with a subject and the To: address filled in? AppleScript. There’s probably something on your Mac that uses AppleScript or AppleEvents, even though you’re not aware of it.
So where does Sal come in? Sal is the guy at Apple who has kept this whole vision alive. He prodded developers to add AppleScript capabilities to their applications. He kept system-level scripting a priority – or at least on the radar – at Apple. He spoke at WWDC and numerous other conferences, showing how powerful the technology was. He explained to developers how a little work on their end could yield huge benefits for scripting-aware users.
My fear is that with Sal’s departure, Apple’s waning interest in scripting, and application interoperability in general, will be gone for good.
Losing interoperability. So if system-level scriptability disappears, what do we lose? For starters, it makes it harder for one application to talk to another or to use another application’s capabilities. Those iTunes controllers wouldn’t be able to talk to iTunes. My own product, Default Folder X, tracks your recently-used folders and then lets you go back to one of them in the Finder, Path Finder or Terminal. The latter two wouldn’t be possible (or would be much harder) without AppleScript. And when someone tweeted me that they wanted to use iTerm2 instead of Terminal, I could add that in 10 minutes because iTerm2 supports AppleScript.
Yes, those are little things, but sometimes they’re the little things that separate an acceptable application from an awesome one. I’ve always felt that the interoperability between Mac applications was one of the things that distinguished the Mac from other platforms like Windows. Even when you can get the same applications on both OS’s, everything is just tied together better on the Mac. I hope that doesn’t change.
Oh, and if you do use AppleScript? Yeah, this sucks even more.