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.
November 13th, 2016 by Jon
Version 1.5.3 of Jettison is now available, correcting a couple of bugs that could cause Jettison to crash. The folks that reported the bug simply noticed that Jettison’s icon would disappear from their menubar sometime during the day. The new version should eliminate that problem.
You can update your copy by downloading version 1.5.3 from the Jettison Release Page or by selecting “Check for Updates” from Jettison’s menu in your menubar.
November 2nd, 2016 by Jon
HistoryHound 1.9.12 and Jettison 1.5.2 both deliver stability improvements and bug fixes to make sure they run without issue on El Capitan and Sierra.
HistoryHound also includes better error handling and its indexing is more intelligent when it encounters web pages that redirect you to a new page. You can now click on status messages in the main window to show you the status of indexing and the contents of your search index, and HistoryHound 1.9.12 supports the Vivaldi browser as well as Safari, Chrome, Firefox, OmniWeb, iCab, Opera, NetNewsWire and URL Manager Pro.
Full lists of changes and download links are available on the HistoryHound release page and the Jettison release page.
October 6th, 2016 by Jon
Just a random PSA for developers: This just happened:
Summary: Bogdan Popescu, the developer of Dash (one of the most awesome programmer’s reference tools ever), contacted Apple to convert his personal developer account into a company account. Apple started the process, then disabled his personal account and revoked his permission to sell apps on the App Store. It looks like another capricious and supremely unhelpful App Store move from Apple. Thanks guys – you make it so much fun to develop for your platforms.