Time Sink and Keymo updated

April 5th, 2016 by Rob Griffiths

Today we released updates to Keymo (1.2.4, both direct and App Store) and Time Sink (1.2.5, for the App Store only).

The Keymo update features our brand-new help system with greatly improved navigation and a much more functional search. (This help system will be rolling out to all our apps in the near future.) With this update, both the App Store and direct versions of Keymo are in sync at 1.2.4.

The Time Sink update brings the App Store version into sync with the direct version at 1.2.5; there are no substantive changes in the Time Sink update.

As always, direct customers can use the in-app updater or download the full version from our site, and App Store customers should see the updates in the App Store app—if not now, then in the very near future.

Do not sync our apps’ prefs file across Macs

April 5th, 2016 by Rob Griffiths

Many users, myself included, own more than one Mac. For people like us, the concept of syncing an apps’ settings across those Macs, so they’re always the same and always up to date, is enticing. But unless the app has been specifically written to support such syncing (i.e. TextExpander, or the snippets/presets portion of our own Name Mangler), this is generally a Very Bad Idea.

In the last couple weeks, I’ve received emails from a few users, complaining of lost settings in a couple of our apps. After some back-and-forth, the common thread among these users was the use of an open source tool called Mackup.

Mackup claims that it will:

  • Back up your application settings in a safe directory (e.g. Dropbox)
  • Sync your application settings among all your workstations
  • Restore your configuration on any fresh install in one command line

If you browse the Mackup page, you’ll find a number of our apps—Moom, Name Mangler, and Witch—listed in the Supported section. This may make you think that we’ve been consulted, and that those apps have our blessing to be used with Mackup. This is not the case at all.

Supported apps are just apps that Mackup itself supports in its configuration; there’s not necessarily any involvement with—or approval from—the app’s original developer. That’s certainly the case with us, as we were never contacted about including our apps on Mackup’s supported list. At present, we do not support preference files synced across multiple Macs for our apps. (We have asked to have our apps removed from Mackup, but so far, there’s been no response from the Mackup developer.)

We do not recommend the use of Mackup, or any other such tool that syncs our apps’ prefs files across multiple Macs. You may lose all your settings, or introduce some sort of command conflict that could cause problems using our apps. Please revert to locally-stored non-synced prefs.

The way preferences files work in OS X now, syncing any apps’ prefs via a sync service is probably not a good idea anyway, unless the app is specifically designed for such sharing. Why not?

In modern versions of OS X, a process called cfprefsd manages preferences. When you launch an app, cfprefsd caches the prefs file values into RAM, and from then on, it’s in charge of how and when prefs changes get written back to disk. There are times when, even after changing a prefs file on disk (say via a Terminal command) that those changes aren’t reflected in the app, even after relaunching it. That’s because cfprefsd overwrote your changes when it wrote out its cached values.

Even if you weren’t to lose your preferences file due to Mackup, it will lead to conflicts that have no easy resolution. Consider Moom being used on two Macs, with a shared preferences file. Moom is an always-running kind of app, so it’s likely to be running on both Macs at the same time. On one Mac, a user adds a custom control; on the other Mac, a short time later, the user creates a different control, but accidentally uses the same keyboard shortcut as they did on the first Mac. What happens when the prefs file is synced between both Macs?

Excluding certain parts of Name Mangler, none of our apps are written assuming that they will have to manage a shared settings file. We have no idea what will happen if something like the above Moom scenario were to occur. But whatever the outcome is, it’s not something we have anticipated, because prefs file are expected to be local, and to only be modified by one instance of the app.

Future versions of some of our apps may support some version of pref syncing. But until they do, please keep our apps’ prefs files local to each Mac. (You can get a head start on configuring a new Mac by copying your apps’ prefs files from another Mac. But copy them, don’t sync them.)

Avoid an OS X text-to-speech bug that affects Moom

February 4th, 2016 by Rob Griffiths

In “OS X El Capitan and tvOS still a bag of hurt for people with motion sickness and other vestibular disorders”, Craig Grannell mentions an odd bug he discovered that affects Moom and other window management apps:

I also recently discovered an issue with window manager Moom, where windows wouldn’t snap, but would instead skid around the display, triggering motion sickness. It turns out other window managers are affected, and the trigger is activating text-to-speech.

Basically, if you use text-to-speech and then use Moom within the same app, you’ll find that Moom behaves in strange and ugly ways: windows slowly wander to their new positions, and you can’t resize and move (i.e. use the grid), as only one of the two operations will complete.

The issue, unfortunately, lies in OS X not Moom, so it’s not something we can fix. There are two workarounds, though:

  • Use text-to-speech via the menus, instead of the built-in hot key. Use Edit > Speech > Start Speaking to start, and Edit > Speech > Stop Speaking to stop. When invoked via the menus, the bug mysteriously vanishes.

    To make this easier to do, you can assign global keyboard shortcuts for Start Speaking and Stop Speaking in System Preferences > Keyboard > Shortcuts > App Shortcuts:

    The defined keys should work in any app that supports text-to-speech.

  • If you quit and relaunch the app in which you used text-to-speech, Moom will return to normal, at least until you again use text-to-speech.

We’ve reported this bug to Apple, so hopefully it’ll be fixed in a future OS X update. Until then, though, if you use Moom (or another window manager) and text-to-speech, you’ll have to rely on one of these workarounds.

All direct apps updated to improve update security

January 31st, 2016 by Rob Griffiths

Yes, that’s right, we’ve updated the updater in our direct apps. Our direct apps rely on Sparkle to inform you when there are new versions available. Over the weekend, we were made aware of a potential vulnerability in how we implemented Sparkle. Basically, if your network is already compromised by what’s called a Man in the Middle attack, then it’s possible an attacker could use the Sparkle update mechanism in our apps to remotely execute code on your Mac. That’s bad.

Although this is a relatively small exposure (as you must already be on a compromised network), we felt it was important to act on it right away, so we’ve updated all of our apps to use Sparkle over secure HTTP (HTTPS). Please update any directly-purchased Many Tricks apps immediately.

Important: There’s a bit of a Catch-22 here … in order to get you this update, it must come over insecure HTTP, because that’s how Sparkle in the app you’re using is configured. If you are concerned that you might be on a compromised network, please do not update using the in-app updater. Instead, just download the relevant app(s) directly from our site, which uses HTTPS.

If you have any questions on this update, please leave a comment or email us directly, and we’ll do our best to address your questions.

Note: Although our App Store apps don’t use Sparkle, we know they’re out of date with some of the other minor bug fixes that came with these releases. We’ll be submitting updates to the App Store next week to get App Store users current.

The Many Tricks holiday sale event and charity drive

December 14th, 2015 by Rob Griffiths

People ask us all the time, “When are your apps going on sale?” And we always reply “We don’t know,” because, generally, we don’t know. But we know now: Our apps—when you purchase directly from us—are on sale for the remainder of 2015, and there are two ways to take advantage of the sale.

Option One: Own Them All

First off, you can own them all for just $50—that’s $62 off the normal price of $112 for all 10. All ten apps, fifty bucks total. These are fully licensed versions, not some special one-off, so they’re all eligible for upgrade pricing when major new releases come out.

On the charity drive front, we will donate $10 for each bundle sold to the United Nation’s refugee fund, to help with the ongoing global refugee crisis. And to get things started, we’ve already donated $500 to the fund.

Option Two: Save Some Coin

If you don’t really want all our apps (we don’t understand such thinking, of course!), you’ll want to use option two: Every purchase is 30% off for the remainder of the year.

We will donate 10% of our net proceeds from any individual sales to that same UN refugee fund.

About the Mac App Store

You may have noticed that this sale is only available to customers who purchase directly from us; our App Store app pricing is unchanged, and we can’t create a bundle of apps there anyway.

So why aren’t the individual MAS versions on sale? Quite honestly, we feel Apple has ignored the MAS for too long, and as a result, the customer experience is not what it should be. Add in the recent snafu with certificates, and we would like to reward those who choose to purchase direct. That’s why this sale is for direct customers only.

So there you have it, the Many Tricks year-end sale event and charity drive.

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:

https://manytricks.com

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 manytricks.com.

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.