Help us test Leech 3, our updated download manager

November 18th, 2015 by Rob Griffiths

Do you download a lot of stuff—like really, a lot of stuff—from the Internet? Would you rather not have those downloads tied to your browser? If so, do we have an app for you to test: Leech 3.

Leech is our lightweight download utility, and version three gains some nifty new features: acceleration, scheduling, and a user-settable bandwidth limit. We’ve made some interface changes, too, and made a lot of tweaks under the hood.

Before we do a general release, though, we’d like to stress test Leech 3 by having some heavy-duty downloaders give it a try. So if you download lots and lots of stuff from the net, we’d love to have your feeback.

Note: If you primarily download from login-required servers that use cookies and other mechanisms to verify your logged-in status (filesharing sites, in other words), Leech 3 probably isn’t for you. While we’ve done our best to make Leech work with many such services, there are no guarantees and we can’t make changes to support any specific site. You’re welcome to test Leech 3, but if it doesn’t work on your favorite filesharing site, it’s not going to work on your favorite filesharing site.

So if you’re interested in helping us test Leech 3, please drop us a line and let us know why you’d like to help test Leech. (To participate in the beta, you will be signed up for a Google Groups mailing list, so please send the email from an account that works with Google.)

Usher 1.1.12 released

October 1st, 2015 by Rob Griffiths

Sorry for two updates in two days, but a couple users—including me!—noticed an issue in Usher 1.1.11: Changes to the library weren’t sticking between relaunches, and Usher was recreating thumbnails on every launch.

You’ll only have this problem if you keep your main Usher library file on an external volume (which isn’t recommended, but some of us live on the edge!). The problem was that Usher’s path determination for these library files was failing, leading to a failure to write the library file on quit.

Usher 1.1.12 fixes that problem, and is available now via in-app updates, or by downloading the new version from our site. Sorry about that, and thanks to everyone who reported it!

All direct apps updated ahead of El Capitan’s release

September 28th, 2015 by Rob Griffiths

There are a couple of changes in the soon-to-be-released El Capitan that required us to update our direct-sales app update mechanism—an incredible open-source framework known as Sparkle. (App Store versions don’t have this update mechanism, because the App Store app handles app updates.)

Because of how we implemented Sparkle, we found that the updater wasn’t working properly in El Capitan. So we needed to fix this prior to El Capitan’s release. As a result, today we have updated every single direct app we sell (and even one we give away):

Butler, Desktop Curtain, Key Codes, Keymo, Leech, Moom, Name Mangler, Time Sink, Usher, and Witch

We have pushed all these updates live, so you should see them automatically (if you have our apps set to auto-update), or you can look in the Preferences > Updates section of a given app and manually check for updates. You can also download the complete new version from our site, if you prefer (just delete the old one and replace with the new; you won’t lose your settings.)

Our site has learned to speak securely

September 28th, 2015 by Rob Griffiths

Every year, we get a few inquiries about why our web site doesn’t use https (i.e. TLS/SSL) to encrypt communications between the user and our site. Our stock answer has been that SSL is slow, expensive, and complicated for a two-person company to manage—and that was true for many years.

However, when I received the latest inquiry about encryption on the site, I thought it was time to revisit the subject. What I found is that SSL is no longer slow or expensive—and the complexity level has dropped dramatically. So we did a bit of work to update our pages, installed our shiny new security certificate, and as of now, you can securely browse Many Tricks by using this URL:

Note that we have not made this the default—but if you load the https site, you won’t be able to load the http version (thanks to something called HTTP Strict Transport Security).

When you’re browsing our https site, you should see a small lock icon next to the site’s name, as seen below in Safari, Chrome, and Firefox:

We don’t collect any financial information here (all purchase details go through our processors, which have always used TLS/SSL encryption). But many people like the security of knowing that their interactions with a given site are encrypted. And now, they can be when you visit

SHA-2 Hashes

The other thing we’ve done is create a page of SHA-2 hashes for all our apps. That page contains a list of SHA-2 hash values, and explains how to use these values to insure that what you download from us is the same as what we uploaded to the server. (Note that this is mostly useful for any potential download interceptions; if someone hacks our server such that they have full access, they could simply modify the SHA-2 values so that everything still looked right to a user.)

Please let us know if you have any troubles with either the https site (or our SHA-2 hash values)—we think we’ve tested everything, but it’s quite possible we’ve missed a page somewhere.

Resolutionator 1.0.1 gets Docky with it

September 8th, 2015 by Rob Griffiths

Today we released Resolutionator 1.0.1, which makes a number of minor changes and fixes (release notes). It also adds one major feature: the ability to change resolutions via Resolutionator’s Dock icon (click for a larger image).

Control Resolutionator via the Dock

If you have Resolutionator set to check for updates automatically, well, this might be old news to you. If you don’t, check for updates now, or just download the newest version if you prefer.

Welcome, Resolutionator

August 4th, 2015 by Rob Griffiths

Meet Resolutionator, the newest entry in Many Tricks’ stable of apps. Resolutionator makes it brain-dead-simple to switch the resolution on your display(s), and was developed with retina displays in mind (though it’s perfectly functional on non-retina displays, too).

Like many of our other apps, Resolutionator came about due to an internal need—I use a 13″ retina MacBook Pro, and as crisp and gorgeous as that 1280×800 ‘retinaized’ display is, that’s just not a lot of room when working with lots of windows. As a result, I found myself constantly switching resolutions—I’d use a higher resolution when working on complicated projects, then switch back to the default retina resolution when browsing the web or reading email.

In prior versions of the Mac OS, switching resolutions wasn’t a big deal—an optional menu bar icon provided quick access to any available resolution. But some years back, this feature vanished, never (at least so far) to be seen again. In its place is a convoluted process that requires launching System Preferences and clicking buttons. If you change resolutions once a week, it’s not too bad…but if you change multiple times a day, it gets old, and fast.

Switch via pop-up or menu barEnter Resolutionator, which recreates the old menu bar prompt to let you quickly change the resolution on any and all attached displays, as seen at right.

But Resolutionator goes well beyond the old stock resolution switcher.

You can assign a keyboard shortcut, and then switch resolutions via a pop-up menu. And whether you use a keyboard shortcut or the menu bar icon, Resolutionator lets you switch the resolution on all attached displays from the same location.

Want to conserve menu bar space? After assigning that keyboard shortcut, switch Resolutionator to faceless mode, and it runs completely invisibly, activated only when you press the assigned shortcut. (It can also run as a normal application, complete with Dock icon, if you prefer.)

Those features are useful, though not all that exciting. The exciting feature in Resolutionator is its secret superpower…

Resolutionator’s secret (OK, it’s not really secret) superpower is that it can offer you resolutions—including some that offer more pixels than your display contains—that OS X won’t let you use.

On my 13″ Retina MacBook Pro, for instance, OS X’s Displays panel lists four possible resolutions, ranging from 1024×640 up to 1680×1050.

Out of the box, Resolutionator shows me those four, plus a “native pixels” resolution of 2560×1600. When I enable the “show non-retina resolutions” option in Resolutionator, I see a total of 12 resolutions, including one (2048×1280) that I find very usable when I need screen real estate.

You can go further, if you wish: enable the “show silly resolutions” option, and you’ll gain access to resolutions that are greater than the number of pixels on your display—the last two resolutions in the image at right show more pixels than are available on my MacBook Pro.

How does such magic work? OS X handles the hard part, scaling down the entire OS so you achieve the chosen virtual resolution. It may sound silly (hence the option’s name), but it can be very useful: On my 11″ Air, which has a maximum resolution of 1366×768, Resolutionator will let me choose 1920×1080 (and higher, but those are ridiculously hard to read). Is it usable for reading emails or small-text web pages? Not really, but it’s great for eyeballing a page layout without scrolling.

Anyway, there’s more detail on the Resolutionator web page, so head over there, take a look, and download the free trial. If you like what you see (or see more of), a measly $3 will get you a license. If you switch resolutions a lot, we think you’ll find Resolutionator an indispensable tool.

An update on the Witch update for OS X 10.9.5 users

July 20th, 2015 by Rob Griffiths

When we updated Witch to 3.9.5, we did our usual internal testing before setting it free: Both Peter and I tested on our production machines running 10.10.4 (Yosemite), and in virtual machines running 10.11 (El Capitan) and 10.9 (Mountain Lion). Neither of us had any issues with any of these tests.

But after release, we heard from a number of 10.9.5 users that Witch was repeatedly crashing. We tried to replicate the crashes here, but didn’t have a lot of luck. From the crash logs, Peter was able to see that the crash was caused by some text handling code that works fine in 10.10 and 10.11. He spent many hours trying to work around this problem for our 10.9.5 users (we sent out two further betas for them to test), but in the end, he wasn’t successful: we can’t make Witch 3.9.5 run reliably in 10.9.5.

This means that OS X 10.9.5 users will need to install and use Witch 3.9.4. (At present, there are no planned new features for the Witch 3.x series, so OS X 10.9.5 users will have the same features available to them as users on newer versions of OS X. All new features will appear in Witch 4, which will require OS X 10.10 or newer.)

Here’s how to install Witch 3.9.4, and set it up to make sure you remain on Witch 3.9.4.

  1. Download Witch 3.9.4.
  2. Open System Preferences, right- (or Control-) click on the existing Witch System Preferences panel and choose the “Remove” option in the contextual menu. (You will not lose any of your settings!)
  3. Open the downloaded Witch 3.9.4 disk image, then double-click the Witch System Preferences panel. You can choose to install for all users or just for the current user.

Witch 3.9.4 is now installed and should be ready to use. Witch is set to not update for users on OS X 10.9.5; if you ever update to 10.10 or newer, Witch will update itself—assuming you’ve left the “Check for updates automatically” box checked (on the About tab in Witch’s settings panel. So we recommend you do leave that box checked, to make sure you get the latest-possible version of Witch if/when you upgrade OS X.

Good things come in threes—Name Mangler 3.3.3 released

July 1st, 2015 by Rob Griffiths

Today we released Name Mangler 3.3.3 for both App Store and direct users. The interface has been modernized, and we’ve added a couple useful new features, including access to grandparent (and higher) folders via metadata. You can read the release notes for the full scoop.

App Store buyers should see the update shortly (if not already) in the App Store app; direct buyers will get an in-app update notice, or they can download the full version directly from our site.

How-to: Give Moom extra room to work in El Capitan

June 30th, 2015 by Rob Griffiths

If you’re a developer (or public beta tester) using El Capitan, you’ve probably discovered that you can hide the menu bar (via System Preferences > General > Automatically show and hide the menu bar).

If you use this feature, and you’d like Moom to use the extra pixels afforded by the hidden bar, here’s how. Open Terminal (no need to quit Moom first), paste the following text, and press Return:

defaults write com.manytricks.Moom "Ignore Menu Bar" -bool YES

From now on, Moom will freely place windows in the top portion of the screen. This change will affect everything Moom does—those 23-ish pixels at the top of your display are now part of Moom’s real estate.

Later on, if you decide you don’t like the auto-hiding menu bar and disable it, you’ll want to also disable Moom’s use of that space—lest you find windows partially hiding behind the menu bar. To do that, go back to Terminal (again, no need to quit Moom), paste this text, and press Return:

defaults write com.manytricks.Moom "Ignore Menu Bar" -bool NO

With that command done, Moom will once again respect the menu bar’s real estate.

Avoid download issues with App Store purchases

June 22nd, 2015 by Rob Griffiths

Over the last few days, several users let me know they were unable to download our apps from the Mac App Store. They reported that they were receiving this error message when trying to purchase or update:

App Store Error: Failed to verify the preflight file. It is not signed by Apple.

Emails like this are frustrating, because we have absolutely no official way to help such users—Apple handles everything related to the store after we submit our app. They test the app, hopefully approve the app, and then host it for downloading. If the app makes it through this process, it’s pretty clear the code itself is good, and any download issues are related to the user’s system.

In theory, Apple (in exchange for their 30% cut of our revenue) should be helping these users solve such problems. But based on what I’ve heard, that’s not usually the case, so they end up writing to me. After a bit of web searching, I found the cause and solution to the problem: Keychain Access.

In particular, the settings for OCSP and CRL in Keychain Access > Preferences > Certificates. For some apps, and for some users (but not for all apps, and not for all users; I don’t know why), these values must be set to “Best Attempt:”

Keychain Access' Certificates prefs

If these two values are set to anything else, it’s possible that some apps and/or updates will fail to download with the above-noted error message. I’ve never personally touched those settings, and I was curious why others might; a friend pointed out this thread, which recommends changing the settings to reduce background bandwidth usage by the ocsp process.

In any event, if you’re having troubles downloading apps and updates—not just ours, but from any developer—from the App Store, check these settings in your Keychain Access app.