Something new: Resolutionator

December 15th, 2014 by Rob Griffiths

resolutionator_iconThe “something new” portion of today’s promised “something different, something new” is a public beta of Resolutionator. And what is Resolutionator? As noted in our teaser last week, it’s a tool to help you with your resolutions in the new year.

resolutions1No, not those resolutions, but resolutions like those seen at right. That’s right; Resolutionator brings back the menu bar resolution switching feature that Apple saw fit to remove at some point in the past.

But as with all our apps, Resolutionator is capable of many additional tricks. You can…

  • Use more resolutions than those available in the Displays System Preferences panel.
  • Switch resolutions via an onscreen menu, accessed via a user-defined hot key.
  • On some Macs, use resolutions greater than the available pixels. For instance, you can set a 13″ Retina MacBook Pro to display at 2880×1800 pixels, greater than its 2560×1600 true resolution. It sounds like magic, but it’s real, and it works.
  • Set resolutions for any attached displays via either the menu bar or floating resolution switcher.

Who might find Resolutionator useful? Owners of Retina Macs who find themselves switching between “OMG it’s stunning!” retina mode and “I need to see more data” more space modes. Users with multiple displays who change resolutions on one or more of the connected displays. Users of Macs with smaller screens (11″ MacBook Air, anyone?) who occasionally wished they could see more data on their screen. And probably many other people who have usage scenarios we haven’t even thought of yet.

We’ve been using Resolutionator internally for a few months, and we think it’s nearly ready to go. But before we release version 1.0, we’d like to get some feedback from the real world…and that’s where you come in: If you’d like to help beta test Resolutionator, drop us a line and we’ll provide a download link and some “getting started” instructions.

Note: Resolutionator is just an app that uses APIs provided by OS X to get and set display resolutions; it can’t harm your display by putting it into a mode it can’t support (because the monitor tells OS X what it can do, and Resolutionator uses those values for its list of available resolutions).

So if you’d like to help us test, drop us a line and we’ll get you set up.

Coming Monday: Something new, something different

December 12th, 2014 by Rob Griffiths

The holiday season is in full swing, and come Monday (December 15th), we’ll be joining the festivities. How, exactly? Tune in Monday for the full details!

For now, let’s just say that the “something new” will help you with your resolutions in the new year, and the “something different” will directly affect your wallet this holiday season.

In other words, if you’re thinking of buying something from us soon, you may want to wait until Monday to see what we’ve got to say!

Witch switching glitch ditched—help us test the fix!

November 16th, 2014 by Rob Griffiths

Our apologies for the lyrical headline, but after fighting OS X’s Spaces feature for a few months, we couldn’t resist a bit of humor…

Excellent news, multi-display Witch users: we believe we have worked around the most-annoying Witch issue in OS X 10.9.5 and Yosemite (OS X 10.10): The inability to activate a window on another display when switching via Witch. The window would pop to the front, but not activate.

Apple changed something in OS X 10.9.5, and left it changed in OS X 10.10…and whatever it was they changed, it broke Witch’s ability to properly switch windows across displays. You’d only see this problem if you had “Displays have separate Spaces” enabled in System Preferences > Mission Control. But as this is the default setting, most users were experiencing the problem.

If you’d like to help us confirm the fix, read on for the instructions.

Read the rest of this entry »

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…

Read the rest of this entry »

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.

Read the rest of this entry »

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.

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?

Read the rest of this entry »