Change Moom’s keyboard/grid bezel timeout delay

October 30th, 2014 by Rob Griffiths

One of Moom’s tricks is the ability to move and zoom windows via an onscreen bezel—this feature is enabled in Moom’s Keyboard preferences; assign a hot key to display the keyboard controller, and optionally show a cheat sheet (to help remember the commands you’ve assigned). You can also optionally repeat the same keystroke to have Moom display an onscreen grid.

As an example, here’s the onscreen grid with cheat sheet:

Moom's onscreen grid

Moom’s onscreen bezels automatically disappear after either three seconds (no cheat sheet visible) or nine seconds (cheat sheet visible)—either after taking an action (if you haven’t marked any of the “auto-dismiss” boxes in the Keyboard section of Moom’s prefs) or after doing nothing.

If you’d like to change this, you can. Open Terminal—in Applications > Utilities—then paste the following into Terminal. (Note that if you’re on OS X 10.8 or earlier, you need to quit Moom first.)

defaults write com.manytricks.Moom "Auto-Deactivate Interval" -float 1.0

The 1.0 is the default timeout in seconds; replace that with whatever time interval you’d like to use, then press Return. You won’t see any output, but relaunch Moom, and the bezels should follow your chosen auto-dismiss interval. If you ever want to reverse this, quit Moom, paste the following in Terminal, and press Return:

defaults delete com.manytricks.Moom "Auto-Deactivate Interval"

Moom should now be back to its default timeout settings.

Our apps and OS X 10.10 (Yosemite) compatibility

October 19th, 2014 by Rob Griffiths

Now that OS X 10.10 (aka Yosemite) is officially out, here’s a status report on our apps. The short version: they all work fine, with some minor visual oddities here and there.

Primary applications

Our primary apps—Butler, Desktop Curtain, Keymo, Leech, Moom, Name Mangler, Time Sink, Usher, and Witch—are all compatible with Yosemite.

Some of these apps have some cosmetic issues we’ll be addressing via updates in the near future, but they’re relatively minor adjustments. We’re also working on finding a solution for a Yosemite issue that’s affecting some Witch users.

Baubleries and Safari extensions

The following run without any issues: Key Codes, as well as our two Safari extension (⌘-Click Avenger and Unread→Tabs).

We do not recommend the use of Open-With Manager, Safari Guardian, or Service Scrubber on Yosemite (or more generally, any release newer than Mac OS X 10.5).

Displaperture and Menu Bar Tint: Both of these apps need to be re-signed for Yosemite, and we will do so in a future update. Until then, to run them you’ll need to manually allow each to run in the Security & Privacy System Preferences panel—on the General tab.

You can either change the “Allow apps downloaded from” pop-up to Anywhere, or click the button you’ll see that asks you if it’s OK to run the apps, even though they’re from unidentified developers. (You’ll see this button after trying to run the app once.)

Overall, the upgrade to Yosemite should be a fairly painless one for users of any of our applications.

A workaround for a Yosemite/Witch issue

October 16th, 2014 by Rob Griffiths

Over the course of the Yosemite beta, we’ve had a few reports of users not being able to make Witch work properly. If you’ve got this problem, you’ll know, because you’ll see this dialog every time you try to call up the Witch switcher panel:

For the sake of search engines, the text reads:

“witchdaemon” would like to control this computer using accessibility features

Grant access to this application in Security & Privacy preferences, located in System Preferences.

You’ll see that even after you think you’ve done what it asks you to do, and then you’ll get frustrated and upset and angry and blame us and send me nasty emails. And I completely feel your pain. And I wish I could tell you that it’s a bug in our code that’s causing the problem, so that we could fix it. But it’s not.

Instead, it’s an issue with Yosemite and how it handles (or rather, doesn’t handle) granting Accessibility access to helper apps that are included within another app’s bundle. So as much as I’d love to tell you we’re working on a fix, this isn’t something we can fix. (We may be able to work around the OS X issue, which is what we’re trying to do now. But that’s not fixing the problem, it’s avoiding the problem.)

The good news is that you can get Witch functioning again, even before Apple fixes the issue (or we manage to work around it). Here’s how…

The problem is caused by OS X not adding Witch’s helper application—named witchdaemon—to the Privacy tab of the Security & Privacy System Preferences panel. At least, it doesn’t appear it’s being added. We believe it is being added, but it’s invisible—which is just as bad as not adding it, because you can’t put a check mark in an invisible check box next to an invisible item.

The workaround is to add the helper app to the panel yourself. This won’t solve the invisibility problem—it’s still not going to show up, even after you add it—but it will get Witch working again. That’s because when you add an app to the panel yourself, OS X adds it with the (invisible) check box already (invisibly) checked.

A video walkthrough

If you prefer visual guides, watch the video below; it walks through the entire process for the App Store version of Witch. (If you’d prefer, you can watch the 1280×800 version instead.)

Direct customers: The direct version of Witch is a System Preferences panel; it won’t be found in Applications, but in either your user’s Library > PreferencePanes folder, or the top-level Library > PreferencePanes folder. One of the two will contain a file named Witch.prefPane.
Open the proper folder, then follow along in the video ignoring the bits about the Applications folder. Also note that you’ll only have to open the pref pane’s app bundle to find witchdaemon, unlike App Store buyers who have to open two app bundles. See the written instructions below for more help if needed.

And now, on to the written instructions…

App Store customers

  1. Open System Preferences, and go to Security & Privacy, then click on the Privacy tab. Click on Accessibility in the sidebar. Leave this window open somewhere onscreen.
  2. In Finder, go to the Applications folder, and right-click (or Control-click) on Witch. In the contextual menu that appears, select Show Package Contents. This may or may not open in a new window.
  3. In the new window (or the same window, if a new one didn’t open), double-click Contents, and then PlugIns within contents. This will reveal a Witch.prefPane entry as the only contents of that folder.
  4. Right-click (or Control-click) on Witch.prefPane and choose Show Package Contents. Again, this may or may not open in a new window.
  5. Double-click Contents, then Helpers, and you’ll see witchdaemon as the only item in that folder. Leave this window open.
  6. Switch back to the System Preferences app, as opened in step one.
  7. Click the lock icon and enter your admin password, so you can make changes.
  8. Click the plus sign at the bottom of the “Allow the apps below to control your computer” area of the window. (You could also simply drag the file into the “well” area without going through the “open file dialog.)
  9. This will present the standard “open file” dialog; click and drag witchdaemon from the open window in step five into the open file dialog, then click Open.

That’s it, you’re done.

Direct customers

  1. Open System Preferences, and go to Security & Privacy, then click on the Privacy tab. Click on Accessibility in the sidebar. Leave this window open somewhere onscreen.
  2. In Finder, hold down the Option key and select Go > Library. In the Library folder, double-click on PreferencePanes. If you see Witch.prefPane, you’re in the right spot—skip to step four.
  3. If you don’t see Witch.prefPane here, you must have installed it for all users. Select Go > Go to Folder, and enter /Library/PreferencePanes. This is the system-level Library, and you should see Witch.prefPane here. (If you don’t, it means you either don’t have Witch installed, or you have the App Store version installed.
  4. Right-click (or Control-click) on Witch.prefPane and choose Show Package Contents. This may or may not open in a new window.
  5. Double-click Contents, then Helpers, and you’ll see witchdaemon as the only item in that folder. Leave this window open.
  6. Switch back to the System Preferences app, as opened in step one.
  7. Click the lock icon and enter your admin password, so you can make changes.
  8. Click the plus sign at the bottom of the “Allow the apps below to control your computer” area of the window. (You could also simply drag the file into the “well” area without going through the “open file dialog.)
  9. This will present the standard “open file” dialog; click and drag witchdaemon from the open window in step five into the open file dialog, then click Open.

That’s it, you’re done.

But nothing changed!

You may think this failed, because nothing will look different about the Privacy panel (as witchdaemon is still invisible). But because you added the app yourself, the invisible checkbox has already been checked for you. Invoke Witch now, and it should just work. (Assuming you have already added (App Store buyers) or System Preferences (direct buyers) to that panel. This happens the first time you launch the app/pref pane, and the entry is not invisible.)

We are trying to put together a repeatable use case for Apple (because they pretty much require those for their bug reports), but it’s tricky—this bug is only hitting a small number of our users at present, and we’re not sure why. Hopefully we’ll be able to figure out a workaround and issue an app update to resolve the problem, but at least you can still get Witch working in the interim.

You want updates? We got updates!

August 6th, 2014 by Rob Griffiths

Today, we’re releasing updates to nearly every app in our collection: Butler, Desktop Curtain, Key Codes, Keymo, Leech, Moom, Name Mangler, Time Sink, Usher, and Witch.

Why the massive update day? First off, a few of the apps have some Yosemite appearance changes (any of the apps that have a menu bar icon, for instance)—and we know at least some of you are using the Yosemite preview. So that’s one cause for the massive number of updates. But not the main cause.

The main cause is that Apple is changing the rules for Gatekeeper in the upcoming OS X 10.9.5 (and obviously in Yosemite as well). This change, as discussed on The Mac Observer, could cause many apps (including ours) to warn users about running insecure software. (Our apps are not insecure, but the change in Gatekeper would make it look like they are.)

Because of the unknown release date for 10.9.5, we’ve taken the unusual step of releasing our direct version updates today, before the App Store versions are ready to go. We’ve submitted the App Store updates to Apple, but given the Gatekeeper change and the huge number of apps that need to be reapproved, we don’t know how long approvals will take.

If you’re a direct customer, you can get updates via in-app updating, or by downloading a new version from our web site. Our App Store updates are marked to release automatically, as soon as Apple approves them. As each is approved, we’ll do our best to note it on Twitter, so that you can get the updates as soon as possible.

For full details on any app’s update, go to that app’s page, then click on Release Notes (e.g., Moom’s release notes).

How to: Discover the magic of the sequence identifier

May 19th, 2014 by Rob Griffiths

One of the main features in Name Mangler 3 is multi-step renaming. Instead of being limited to just one renaming step, you can add many steps to one renaming task. In prior versions of Name Mangler, you’d need to use Advanced mode, or run multiple repeated single tasks, to handle multi-step renaming tasks. This is a great change for everyone, and has greatly reduced the need to use Advanced mode.

But Name Mangler 3’s Advanced mode still has a few tricks that you can’t do using the “normal” renaming options. One of the most powerful of these hidden gems is the “sequence identifier” parameter for the sequence action. The help file has this to say about the sequence identifier:

The sequence identifier, if included, indicates that sequence indexes are only inferred from the number of files that share the same identifier, as opposed to the overall number of files to be renamed.

Clear as mud, right? That’s entirely my fault, and I’ll try to come up with better wording in a future update. But for now, here’s a hopefully-clearer description:

The sequence identifier, if included, is used to group files together (by a common criteria) for sequencing. All files that share a sequence identifier will be treated as part of the same sequence.

Hopefully that’s a bit clearer…and here’s a real-world example of how you can put sequence identifiers to use to simplify your renaming tasks.

At right is a collection of photos I took of holiday light displays, divided into three separate “setN” folders (one for each house that I shot).

I’d like to rename the photos to indicate that they’re holiday light photos, and use sequence numbers to differentiate them.

For purposes of this example, the desired name would be “Holiday_Lights_nn,” where “nn” is the sequence number. One way to do this is to use a simple two-step action in Name Mangler 3.

The first step will use the Compose action, to completely remove the old name, and replace it with what I want—in this case, I’d use Holiday_Lights_.

The second step will use the Sequence action to add the sequence number to the end of the filename. (It also needs to include a prefix, to attach the name built with the Compose action.)

The completed two-step action would look like this:

While this works, the problem is that the sequence numbers keep increasing, even as the renaming action moves from folder to folder—the first image in the “set2” folder will start at 06, even though it’s the first image in the folder.

While there’s no way to work around this in Name Mangler’s normal modes, the sequence identifier in Advanced mode was designed to handle cases just like this. Starting fresh, set the rename mode to Advanced, and enter this text:



		from "1"
		increment by "1"
		sleep "0"
		maximum index ""
		minimum number of digits "2"
		identifier <name of parent folder>


With these commands entered in the Advanced section, the preview shows that the sequence numbers will now reset on each change of parent folder. Note that the gray text above is ignored by Advanced mode; any text that’s not part of a command is considered a comment. You can remove the gray text, or replace it with something that makes more sense to you. Here’s how the renamed files look:

Run the rename as shown, and you can see the results in Finder, as seen at right.

If you understand the Advanced mode syntax above, you’re good to go—you can use the sequence identifier in lots of interesting ways, not just for parent folder names.

For example, use unique sequences based on photos’ pixel sizes by using <number of pixels>. Or use <artist> to create sequences by artist in your folder full of audio files.

If, on the other hand, the above Advanced mode commands look like gobbledygook, then keep reading—I’ll attempt to explain what each line does, so you can hopefully take away enough knowledge to put it to your own use.

Here’s how the above script works, line by line…


The concatenate function is used in many Advanced scripts; it doesn’t do anything other than join anything within its confines into a single result. In other words, it’s how the filename is actually assembled from the various bits.


This is simply the static text that makes up the first part of the filename; the trailing underscore is used as a visual separator from the sequence number.


This is the start of the sequence numbering function; what follows are the paramaters to that function.

from "1"
increment by "1"
sleep "0"
maximum index ""
minimum number of digits "2"

This section is the guts of the sequence command. It specifies where to start (1), how many to increase by with each step (1), whether to repeat a number before moving on (0 means do not), what the maximum sequence number should be before resetting (unlimited), and the minimum number of digits in the sequence number (2).

identifier <name of parent folder>

This is the line that does the work to change the sequence number when the parent folder changes. You can use any metadata that Name Mangler is aware of, which gives you a ton of choices for resetting the sequence numbering.

In fact, you’re not limited to just metadata. You can put any Name Mangler expression there. So you can group by a find and replace, by a combination of three metadata items, by random numbers, or whatever you like. There’s almost no limit to how you can create your sequence identifiers.


This appends the dot extension to the newly-created filename.


This last closing bracket marks the end of the concatenate, and hence, the end of the new filename. Advanced mode may not get as much exercise as it did in older versions of Name Mangler, but having access to the sequence identifier feature is one good reason to put it to use.

Butler 4.1.17 released

May 13th, 2014 by Rob Griffiths

Today we released a minor Butler update, with three small but important bug fixes:

  • Keystrokes Smart Items now let you use the current pasteboard via cmd-v keystroke, provided that you add a sufficiently long delay (recommended: 1 second) in front of the cmd-v keystroke.
  • Fixed a display glitch where delays in Keystrokes Smart Items weren’t displayed properly.
  • Fixed an issue with the Screensaver Smart Item.

You can update within Butler (in the About Butler section of its configuration window), or by downloading the full version from our site.

Discounts for companies, resellers, and groups

May 8th, 2014 by Rob Griffiths

Although not many people know it, we provide automatic discounts for multiple-item orders. We don’t publicize this on our pages, but if you order four or more things (four copies of the same app, or four different apps), we automatically take 20% off your total:


And as of today, things don’t stop there: we have a new sliding discount scale that increases gradually up to 50% off, based on how many units you purchase:

Units Ordered % Discount
0 to 3 0%
4 to 7 20%
8 to 10 30%
11 to 23 35%
24 to 36 40%
37 to 49 45%
50 and up 50%

Using this mechanism, we can now support group buy activities (you and a bunch of friends want to save some money on our apps), companies (buying for more than one employee), and resellers (who are buying on behalf of a business). Here’s how you can use our automatic discounts for any of those types of purchases.

Assemble the group

Regardless of whether you’re buying for a group of friends, or buying as a reseller, the first thing you need to do is assemble the group of buyers, and know which app(s) they’d each like to buy. It’s important to have the list of buyers ready before ordering, because we will only send out one batch of license files per order.

In other words, you can’t place an order for 100 copies of Moom today, and then request licenses one at a time for the next three months. You must request all licenses for your order at one time.

Purchase the apps

Next, visit our pages and add the proper mix of apps and quantities to your cart to match the list of buyers. (Use the “Continue Shopping” button on the cart to return to the app pages to add other products to the cart.)

Once the order has been assembled, and matches your number of buyers and units, click one of the two checkout buttons:


Complete the checkout process, and once your payment has been approved and processed, you will receive a license file—just one license file—via email. You can ignore this particular license, as you won’t be using it. Once you’ve received it, though, that means our system has processed your order, and you can request your licenses.

Request the licenses

To request licenses, just reply to the email containing the license file from the purchase. In your reply, include the information needed to create licenses for all the members of your group: Product purchased, user’s name, and user’s email address. There’s no special format required for the list, though tab-separated text would save a bit of processing time on this end.

Resellers can ask for a generic license, which can then be copied and distributed up to the number of purchased licenses, if they’d prefer not to offer customized licenses.

Remember, we will only send out one batch of license files, so make sure you’ve got everyone in the group represented in your list of requested licenses.

When we receive the list of names and email addresses, we’ll confirm the totals match your order, then create all the license files and send them back to you. At that point, it’s your responsibility to forward each buyer’s license on to each user.

And that’s really all there is to it. So whether you and some friends want to save 30% on our apps, or you’re a reseller looking for some margin opportunity without charging more than list, our automatic multi-unit discount system can help you out.

How-to: Replace preference files in Mavericks

January 30th, 2014 by Rob Griffiths

Something many people do, myself included, is copy an application’s preferences file—either from one Mac to another (as a quick way of getting an app configured to my liking) or to replace a damaged/lost preferences file using a Time Machine backup. Until recently, this process was really simple: quit the app in question, trash the existing prefs file, insert the new prefs file, launch app.

Enter OS X 10.9, aka Mavericks, aka “the easy prefs copy killer.” Apple has made changes to the way the preferences system works in Mavericks, and one casualty of those changes is the easy replacement of an application’s preferences file. A brief bit of before-and-after, and then we’ll get to the fix—or just click the Read More link to jump right to the fix.

In prior versions of OS X, preferences files were always read by the application at launch. So as long as the app wasn’t running, if you replaced its preference file, it would read the new file the next time you launched the program.

In Mavericks, preferences are managed by a background daemon, cfprefsd. This service reads the preferences file once, when you first run the app. It then (I believe) receives notifications if you change the program’s settings while the program is running, and then writes them to the actual preferences file at certain points in time. But cfprefsd always has a copy of those settings in its cache, and that’s what the app gets when it checks its settings. (This reduces hard disk access, which is important in conserving battery life in laptops.)

Here’s the important bit: After you’ve launched an app once, it seems that any subsequent launches also get their preferences from cfprefsd. So if you try the old “replace the prefs while the app isn’t running” trick, you’ll be quite surprised to find that your program launches with its previous settings. It will do this even if you simply delete (via Finder) the old prefs file!

So how do you get around this aggressive caching of preference files?

I’m aware of two solutions, though there may be others (please comment, if you know of a better way).

Update based on comments: The best solution, per the comments below, is to quit the app, open Terminal, paste killall cfprefsd then press Return. This relaunches the prefs system; now relaunch the app, and it should read the modified prefs file.

Method One:

  1. Quit the app, and make sure it is not set to run at login.
  2. Delete the app’s prefs file (typically in ~/Library/Preferences, for non-sandboxed applications).
  3. Logout.
  4. Login.
  5. Copy the prefs file you want to use into its home.
  6. Launch the app.

Method Two:

  1. Quit the app, leaving the ‘bad’ prefs file in place.
  2. Open Terminal, paste the following, and press Return: defaults delete com.COMPANY_ID.APP_ID. Note that COMPANY_ID and APP_ID are taken from the name of the app’s preferences file. Using our own Moom for example, the preferences file is named com.manytricks.Moom.plist, so the command would be defaults delete com.manytricks.Moom.
  3. Copy the prefs file you want to use into the ~/Library/Preferences folder.
  4. Launch the app.
  5. I’ve tested both of these methods and found them to work, but would love to discover there’s an easier solution.

    Net net, if you want to replace prefs files in Mavericks, it’s now more complicated than it used to be…but it is still possible.

Usher’s App Store hiatus is over

January 23rd, 2014 by Rob Griffiths

After much back-and-forth with Apple, we’re thrilled to announce that Usher 1.1.8 has been approved for sale in the App Store! Version 1.1.8 is basically the same as the recently-released 1.1.7, with a few additional bug fixes. Both the direct and App Store versions of Usher are now at 1.1.8, and both are available at the lower $25 ($24.99 App Store) price.

Direct buyers can get the update via in-app updating; App Store buyers should see the update in the App Store application shortly, if not already. (If you’re having trouble finding Usher in the App Store, it seems that Usher’s hiatus has caused some difficulty with search. Try this direct link instead.)

We’re sorry we had to (briefly) take Usher out of the App Store, but we didn’t feel right selling it with usability issues in OS X 10.9. But now, it’s back, and at feature parity with the direct sales version.

Ushering in some changes in Usher

December 2nd, 2013 by Rob Griffiths

Today we’re releasing Usher 1.1.7, but before upgrading, you should read this entire blog post, so you understand what’s happening with Usher going forward.

IMPORTANT NOTE: The minimum system requirement for Usher 1.1.7 is OS X 10.7 or newer; if you’re still running 10.6, DO NOT INSTALL THESE UPDATES. You can download older versions on our support page.

Why 10.7 or newer? Apple recently declared an old security-related API dead (i.e. deprecated), and recommended that all developers switch to the newer API, which we did. But that new API requires 10.7 or newer.

First up, in case you missed it, Usher is not presently available on the App Store. This change may be temporary (if we can resolve some issues with Apple), or it may be permanent (at least for this major version of Usher).

Second, Usher’s new price is $25 (on our site only, for now), down from $35. Why drop the price? Partly because we’d like more people to give Usher a look. But primarily because this version removes the ability to download videos from YouTube and Vimeo. Why did we remove this feature?

Both YouTube and Vimeo technically allow video downloading, but only for videos that are explicitly marked as downloadable. Unfortunately, there’s no easy way for Usher to tell the downloadable status of a given video, so it tries to download every video. As this is a violation of those sites’ terms of service, we don’t feel it’s right to leave the feature in Usher.

In addition, this feature is support intensive, because it breaks when either site makes even trivial changes to their pages—and both sites seem to make such changes regularly. So instead of spending time coding new features, we were spending our time trying to figure out how to make downloading work again. In the long run, this isn’t good for us, and it’s not good for our users.

Please note that Usher still includes two ways of downloading videos from many sites: The File > Open URLs menu item, and the Usher > Integrate With Browser bookmarklet. You can read more about both of these features in Usher’s help file.

There are also many web sites that exist solely to help you download videos from the web. Many of them work more reliably than does Usher, so you’re not out of solutions if you’re interested in downloading web videos. Finding such sites, however, is left as an exercise to the reader…but if you can use a search engine, you won’t have too much trouble with that exercise.