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:

[concatenate

	"Holiday_Lights_"

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

]

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…

[concatenate

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.

"Holiday_Lights_"

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.

[sequence

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.

<.extension>

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:

qty4

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:

qty4

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).

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.

Usher has gone on an App Store hiatus

November 28th, 2013 by Rob Griffiths

As of today, the App Store version of Usher is no longer available for purchase. It may reappear in the future, if we can resolve some issues with the App Store. For now, though, we have removed it from sale.

Why did we do this, and what does this mean for App Store buyers?


Why did we do this?

We’ve been trying for a few weeks now—without any luck—to get a minor update approved for Usher. The App Store version of Usher has been in limbo for a long time, as they asked us to make some changes we weren’t willing to make at that point in time.

As a result, the App Store version of Usher is 1.1.3, while the direct version is 1.1.6. This wasn’t much of an issue until Mavericks came out. There are a couple of Mavericks-related issues that affect usability, so we agreed to make the changes Apple requested, and submitted a 1.1.7 update.

Unfortunately, the update has been rejected twice, and looks like it won’t ever be approved without us undertaking what is, in essence, an Usher 2.0 total makeover project. While we intend to do this in the future, it’s not a simple fix we can push out quickly to resolve the Mavericks issues.

Due to the App Store rejections and the Mavericks-related issues, we have decided to remove Usher from the App Store, effective immediately. It may reaappear in the future, if we can resolve our differences with Apple. But for now, the only way to buy Usher is directly from us, via the Usher web page.

What does this mean for App Store buyers?

With Usher no longer available in the App Store, App Store buyers can’t download Usher—for use on a new computer, or after a total system reinstall, for instance. If and when Usher returns to the App Store, this problem goes away. But for now, it’s a problem.

To solve the problem, we’ve created a way for App Store buyers to get a full direct sales license for Usher. This process will only be available during Usher’s hiatus from the App Store, because it becomes irrelevant once the app is available again.

To convert your App Store license to a full direct license, please follow these steps:

  1. Forward the iTunes receipt that shows your Usher purchase to usher_conversion at manytricks dot com. Make sure the email shows your first+last name somewhere, as we need that for the license file.
  2. Take your existing App Store Usher and archive it somewhere—if Usher never makes it back to the App Store, this will be your only copy of that version. We recommend you create a zip of the application, and keep it somewhere safe.
  3. Download the latest version of direct Usher from our site. [Direct download link]
  4. When you receive your license email, double-click the attached license file, and you should be a full licensed user of the direct version of Usher.

That’s really all there is to the conversion process. All of your existing library and metadata will be retained, as you’re not modifying any of your settings, just which version of the application you’re using.

How-to: Start and stop Leech on a schedule

November 26th, 2013 by Rob Griffiths

One feature that Leech, our simple download assistant, doesn’t offer is scheduling. For many users, this isn’t an issue, as they can use their internet connection whenever they wish. There is a subset of users, though, who have internet connections that may offer more speed at night, or not have capacity limits at night, or may allow unlimited downloading only at night.

A future version of Leech may offer scheduling, but until that comes to be, you can use AppleScript and a scheduling application to handle the task. It’s not overly complicated, but does require a bit of work in Leech and AppleScript.

The first step is to have Leech queue up all download requests, so you can just copy and paste URLs into it during the day, then let it run at night. To put Leech in queued mode, just make sure there’s not a checkmark by the Queue > Start Downloads Automatically menu item, as seen in the image at right.

Once that’s done, you can add URLs to Leech throughout the day, but they won’t start downloading. Next, you’ll need to create two AppleScripts, one to start those queued downloads, and the other to pause them again.

The scripts

Open AppleScript Editor, in Applications > Utilities, then copy and paste this code:

tell application "System Events"
    if (exists (processes where name is "Leech")) then
        tell application "Leech" to activate
        key code 125 using {command down}
    end if
end tell

This is the “start” script, which will tell Leech to start downloading your queued URLs. Note that if you don’t have any queued downloads, the script won’t do anything (as it can’t start a queue that doesn’t exist.)

Save this script somewhere (such as your user’s Documents folder), with a reasonable filename (Start Leech). Do not close this window, though, as we’ll be revisiting it.

Next, open a new AppleScript Editor window (via Command-N, or File > New). In the new window, paste the following code:

tell application "System Events"
    if (exists (processes where name is "Leech")) then
        tell application "Leech" to activate
        keystroke "P" using {shift down,command down}
    end if
end tell

This is the “stop” script, which will put Leech back into pause mode. Save this script (Stop Leech) into the same location as your other script—and as before, leave the window open.

Scheduling the scripts

Now that you’ve got two scripts, all that’s left to do is to have them run on your schedule. I’ll explain how to do this via OS X’s Calendar application; the directions will differ if you choose to use cron or launchd or some other solution.

In order to use Calendar, the first thing you need to do is convert your scripts to applications, because Calendar can’t run raw AppleScripts (iCal could, but it no longer exists).

In one open editor window, hold down the Option key, then select File > Save As. In the window that appears, change the File Format pop-up to Application, choose a name for your app (it can be the same as the raw script, if you want, as they have different extensions), and save the program.

Do the same for the other window, so that you’ve now saved two application versions of your scripts. Here’s how my setup looks, with the applications (left) and original scripts (right):

Once the application versions have been saved, launch Calendar and add a new event; the basics don’t matter, as you’ll be editing it. Might as well name it Start Leech, though, to help you visually see each task on your schedule.

When the editing window pops up, set the event start time at or after the time when your internet goes to unlimited mode. You don’t need a long-duration event, so set it for five minutes or similar. Then click on the date to open the scheduling details for the event. Set the “repeat” to whatever matches your schedule—daily, weekends only, whatever.

Next, click on None next to “alert” to set the alert for this event. Pick Custom from the pop-up menu; this will open another window (this is progress, really). In that new window, set the first pop-up to “Open file,” then pick “Other” in the second pop-up.

This will then show the standard Open File dialog; navigate to the folder where you saved the Start Leech (or whatever you named it) application. Select the application (not the script), then click the Select button to close the Open File dialog.

Finally, change the third pop-up menu (the one to set the time of the alert) to “At time of event,” then click OK. The screenshot at right shows how my window looked, correctly configured, just before I clicked the OK button.

You’ve now created a recurring event to start Leech’s downloads queue at your preferred time on your preferred schedule. Repeat the process with a new event called Stop Leech. Set this one to be triggered sometime before your unlimited internet usage ends, and point it at the Stop Leech application.

Wrapping it all up

With the scripts, application, and scheduled events created, you’re basically done. Go ahead and launch Leech and start queueing your downloads. When your defined start time arrives, Leech should automatically start your downloads, and then pause again near the end of your free usage period. (You may want to test things first by changing the start/stop times on your scheduled events to a time when you’ll be at the computer, just so you can see that they do work.)

We realize this is somewhat of a stopgap measure for true scheduling in Leech. However, in testing, it works well, and we hope those of you with time-based internet connectivity find it useful.

Toggle Witch off and on via AppleScript

November 15th, 2013 by Rob Griffiths

Recently, a few users have asked about disabling Witch when certain programs are in the foreground. Typically this comes up because of conflicts between Command-Tab or Option-Tab (the two most-common Witch activation keys) and the foreground app. For example, you can’t use Option-Tab in a Remote Desktop Client Windows window, because Witch will grab it. Or when using Fusion to run OS X in a virtual machine, you may find that Command-Tab is trapped by OS X before it gets to your virtual machine.

In those cases, it’d be nice to easily disable Witch, then quickly enable it again when you’re done with the app in question. As of today, you can’t do this within Witch, although we have plans to change that. For now, though, the best solution is to create an AppleScript that will toggle Witch off and on as needed. You can then use any program that can run AppleScripts via hot keys (such as our own Butler) to give yourself a keyboard combo that toggles Witch off and on.

Setting up the AppleScript isn’t overly complicated, though it does differ slightly depending on whether you’re using the App Store or direct version of Witch. If you’re interested in creating your own Witch toggle, read on for the how-to…


To start, launch AppleScript Editor, which you’ll find in the Applications > Utilities folder. It should open to a blank editing window; click anywhere in that window, then paste this code:

on ApplicationIsRunning(appName)
    tell application "System Events" to set appNameIsRunning to exists (processes where name is appName)
    return appNameIsRunning
end ApplicationIsRunning

if ApplicationIsRunning("witchdaemon") then
    do shell script "killall witchdaemon"
else
    do shell script "open 'REPLACE THIS BIT'"
end if

When pasting, hopefully you noticed the REPLACE THIS BIT portion of the code. That’s what you’ll do next, and it’s where the instructions differ for the direct and App Store versions of Witch.

App Store Witch

Assuming you have Witch installed in the Applications folder, highlight REPLACE THIS BIT in the AppleScript Editor, and replace it with this code:

/Applications/Witch.app/Contents/Resources/Witch.prefPane/Contents/Resources/witchdaemon.app

Make sure you leave both sets of quotations marks (double and single) in place. Also, if you keep Witch somewhere other than in the /Applications folder, you’ll need to replace /Applications/ with the full path to the folder that holds the Witch application.

Direct Witch

The direct version of Witch is a System Preferences panel; this means it could be installed in one of two places: either in your user’s Library/PreferncePanes folder (if you installed for just your use), or in the top-level Library/PreferencePanes folder (if you installed for all users). You can check this in Finder by using the Go > Go to Folder menu item. Activate that, then enter /Library/PreferencePanes. If you see Witch.prefPane listed here, then use the following for the REPLACE THIS BIT section:

/Library/PreferencePanes/Witch.prefPane/Contents/Resources/witchdaemon.app

If you don’t see Witch listed there, that means it’s installed in your user’s Library/PreferencePanes folder. In that case, use the following for the REPLACE THIS BIT section:

/Users/your_user/Witch.app/Contents/Resources/Witch.prefPane/Contents/Resources/witchdaemon.app

Note that you’ll also need to replace your_user with the short name of your user, i.e. the name of your home folder.

Testing the code

Once you have all the code in, click the Compile button, and hopefully, you won’t see any error messages. If you do, compare your code to what you see above, and see if you can spot the problem area.

Assuming it compiles, the next step is to test it. Make sure that Witch is running, then click the Run button in the AppleScript Editor. You won’t see any output, but in a second, you should find that Witch no longer works. Click the Run button again, wait a second (it takes just a bit to start Witch), then hit your Witch activation keys. You should see the Witch switcher appear onscreen.

If you do, great—keep reading. If you don’t, go back and compare the code above to your code, and make sure it’s identical and that you’ve replaced the important bit to make it work.

Next steps

Now that you’ve got your toggle code working, save it somewhere (your user’s Documents folder, for instance) as a script. You can then use your favorite macro tool to execute that saved AppleScript. Or you could put it into your Dock.

If you’re a Butler user, you can create the AppleScript directly inside of Butler. Create a new AppleScript smart item, paste in your code as above, and assign it a keyboard shortcut.

Regardless of how you set it up, just run the script (via Dock or keyboard shortcut or whatever) to disable Witch, and run it again to enable Witch. (Remember it takes about a second for Witch to become active.)

As noted, this tip may be superseded by a future release of Witch…but for now, it’s the quickest way to disable and enable Witch on the fly.