Some ideas for your Donation Day savings

December 20th, 2012 by Rob Griffiths

Update: It seems Apple has ended our App Store pricing somewhat early; all App Store prices are back to their normal levels. (This probably happened in preparation for the shutdown that begins at midnight tonight, Pacific time).

Our own store’s schedule remains unchanged, however: you can buy for $1 through tomorrow morning.

Now that Donation Day is live in most of the world, we thought we’d make the task of donating easier by providing some links to various charities (a few people have asked us for such). Note that the intent of Donation Day is for everyone to donate to a charity of their choosing, thereby perhaps getting some money to charities that don’t usually get much visibility. However, we realize that some people may prefer a bit of guidance on the subject.

So with that said, here are some links to help start your charitable giving campaign…

Hopefully this list gives you a nice start at finding a home for all that cash you saved on your Many Tricks’ purchases today!

Announcing Many Tricks’ Donation Day

December 19th, 2012 by Rob Griffiths and Peter Maurer

In the past, we’ve donated proceeds from our software sales to worthy causes, such as the National Pancreatic Cancer Foundation and Charity:Water. This year, we thought we’d try something different…

On Thursday, December 20*, all of our apps
will be priced at $1 ($0.99 on the App Store).

The catch: We want you to donate the money you saved
(compared to list prices) to the charity of your choice.

For example, if you want to own Moom ($10) and Time Sink ($5), we’ll expect you to donate $13 to your favorite charity. Usher ($35) and Desktop Curtain ($5) would mean a $38 donation. Buy everything in our portfolio for $9, and donate $109 to charity. It’s pretty simple math, regardless of which apps you’re interested in buying. (These donations should be tax deductible, too, but please don’t take our word for that!)

You may wonder how we’re enforcing this donation requirement. The short answer is we’re not. We both firmly believe in the goodness of people, and we’re confident that those who purchase on Thursday will do the right thing. Will everyone? Absolutely not. But we believe that many will, which will hopefully lead to some nice contributions to a wide range of charities.

Sure, we could have kept prices at their normal level, and donated proceeds to a charity or two of our choosing. But we feel strongly that you should be able to pick your own charity, and we hope that by dropping the apps’ prices to $1 for the day, we’ll get more participation than we would by simply donating our proceeds.

So if you’ve been waiting for a good excuse to purchase one or more of our apps, Thursday’s the day. You get the apps you want at an amazing price, you get to choose who gets the money you saved on our apps, and you get to feel good about supporting a charity.

All we ask (ask, not require) is that you let us what you did with the savings. You can either send us an email with the details, or just tweet about it, and copy @manytricks on your tweet. We’d love to know how much money was donated, and to which charities, if you feel like sharing that information.

Happy Holidays!Peter and Rob.

*

Because the world insists on having multiple timezones, our Donation Day pricing will roll out differently for the App Store and for our web site. App Store buyers will see Donation Day pricing starting at 12:01am on December 20th in their local timezones, and it will end 24 hours later.

On our web site, Donation Day pricing will begin at 7am Pacific USA time on December 20th, and end at 7am Pacific USA time on December 21st. This will give buyers, regardless of their local timezone, 24 hours to purchase directly from us, if that’s their preference.

How-to: Add a teleporter to your multi-display Mac

December 7th, 2012 by Rob Griffiths

If you’ve got a multi-display Mac, then you know what a drag it can be to drag things. When you have a window at the lower right corner of your right display, and you need it at the upper left corner of your left display, that’s a lot of pixels to traverse. One excellent solution to this problem is Moom, our window management tool. Amongst its other capabilities, Moom lets you easily jump a window across displays via keyboard or mouse.

But what if it’s not a window, but text, that you need to drag—say from a word processing window to an email window? Moom won’t be much help there. Or you need to drag a file, to drop it on another application or into a Finder folder?

big drag

Again, Moom can’t help you with that task. But our app Keymo certainly can!

Keymo is an app that lets you control the mouse pointer with the keyboard, and it bears some resemblance to Moom. While some of its users have physical handicaps that make using the mouse difficult, Keymo has some talents that appeal to everyone.

One of those skills is its ability to instantly jump the mouse pointer between displays…and if you can send the pointer between displays, well, anything you happen to be dragging will come right along with it when it goes. So read on to see how you can use Keymo to greatly ease the drag of dragging.

After installing Keymo, all you need to do to start teleporting around your displays is set up one new custom action. Open Keymo’s Preferences, and click on the Actions entry in the toolbar. Create a new Action, and make it look like this:

Move cursor in Keymo

You don’t need to assign the same shortcut (^3 in the screenshot) that I’ve used—but you want it to be something pretty easy to type with one hand, as your other hand will be on the mouse or trackpad. If you check the ‘Loop through displays’ box, you’ll be able to repeat the command to jump to the next display in line (or back to the first display, if you’re using two displays).

The ‘Retain relative position’ setting tries to keep the pointer in the approximate same screen location as resolution changes across displays. You can also set this to ‘Retain absolute position,’ which will use the same fixed coordinates on all displays, or to ‘Absolute center,’ which will always put the pointer at the center of the screen.

Once you’ve set up this custom action, you’re ready to put it to use:

  1. Start a drag operation.
  2. While still dragging, press the hot key you assigned to your Keymo shortcut.
  3. There is no step three.

As soon as you press the Keymo shortcut key, the cursor and whatever it was dragging will jump to the next display, from where you can continue your drag. Press the shortcut key again, and Keymo will teleport cursor and dragged object to the next display (which would be the first display in a two-display setup). Repeat as needed.

Here’s a short video that demonstrates how this works, in case the text above is too confusing.

Watch the large version [mp4 only • 1024x640 • 2.6MB]

If you’ve got a trackpad, this is even slicker, because you can enable drag lock (in System Preferences > Trackpad), and then teleport around your displays without having to keep any pressure on your trackpad—just drag, teleport, etc. until done, then tap the trackpad to release the window.

Keymo is only $5, and you can download and use it in trial mode to help you decide if it helps your workflow or not. (While Keymo is presently available on the App Store, we don’t recommend you buy it there, as it’s presently not sandboxed and we’re not sure if it will be in the future or not. If we can’t sandbox it, we can’t update it.)

Witch and RAM usage, both real and not so real

November 28th, 2012 by Rob Griffiths

Witch, our window switching application, is designed to be always-running (what good is a window switcher if it’s not active?). The program itself exists as two components: the user interface, where you modify Witch’s settings, and the background process that watches for the Witch activation keystrokes and builds the list when activated. The background process is named witchdaemon, and some users have emailed us with concerns about the RAM usage of this background daemon.

The emails we receive come in two flavors:

  1. Why is Witch using so much real RAM?
  2. Why is Witch reserving gigabytes of virtual memory (VSIZE in top)?

Read on for the details on both real and virtual RAM usage by Witch—the explanations are somewhat detailed and technical (especially relative to virtual memory), so put on your geek glasses before proceeding.

High real RAM usage

I’ll address real RAM usage first, because it’s both more important and much simpler to understand. To see how much real RAM Witch is using, run Activity Monitor (in Applications > Utilities), click on the Process Name header, and find witchdaemon in the list of processes. Here’s how it looks on my Mac:

The witchdaemon background process

The column of interest is Real Mem, and as you can see, it’s only 13.4MB—and the daemon had been running for nine days when I took that screenshot. On your Mac, though, you may see a much different value, and it could be substantially higher; I’ve had reports of RAM usage exceeding 1GB. So why the differences? There are three things that affect the memory usage for witchdaemon:

  1. The number of windows you’re switching between. Keep more windows open, and generally speaking, witchdaemon will use more RAM.
  2. The setting of the “Show” pop-up menu in the Appearance tab of Witch’s settings. Set it to ‘application icons’ for the least memory usage; using ‘mini window previews if possible’ will use the most RAM.
  3. Using window previews, either via the “Pop up a preview of the selected window after a” pop-up menu (also on the Appearance tab of Witch’s settings), or by pressing the Space Bar with a window selected. Show lots of window previews, and RAM usage will increase.

The reason these last two options use RAM is that Witch caches the images, so that future redraws of the panel will be quicker. For instance, here’s my same nine-days-running witchdaemon after I used a slew of window previews:

After using window previews

At present, this cache isn’t cleared aggressively by Witch, though the system will take it if it needs it. Over time, if you use preview icons and/or window previews, you may see witchdaemon‘s memory usage increase. (The system will do some cleanup; my RAM usage fell to 92MB within a minute or so of taking the screenshot.)

The easiest way to reclaim this memory is to simply open the Witch settings panel—this will restart witchdaemon automatically, and thereby clear the cached image data.

High virtual memory usage

If you’re the type of user who likes to really see the nitty gritty on what your machine is up to, you may occasionally use top in Terminal. top is basically like Activity Monitor, but for command line geeks. If you do, and you use Witch, it may freak you out just a bit when you see something like this:

Output from 'top' sorted by VSIZE

Why on Earth would witchdaemon need 11 gigabytes of VSIZE, whatever that might be? (In Activity Monitor, you can see these VSIZE values, but you must first select a process, then click Inspect; the value is on the Memory tab.)

Regardless of what it VSIZE may be, though, the sheer size of the number is shocking, and probably has you thinking “Geez, Witch is a huge memory hog; that’s horrible!”

As it turns out that this huge figure in VSIZE is nothing to worry about, and it’s not exclusive to Witch. So if you’ve seen it, and wonder if you should care, the answer is you shouldn’t.

If you’re curious as to why you shouldn’t care, then keep reading. (Things are going to get a bit geeky from here on out, so consider yourself warned.)

You’re headed into a maze of twisty little passages, all alike…at least, that’s how I feel when I start discussing OS X and memory management. In short, it’s a very complex and powerful system that generally works very well, but can be really confusing at times. Keep in mind I’m not a programmer (Peter is our founder and programmer) or memory expert, so the following is a semi-educated amateur’s attempt at explaining Witch’s huge VSIZE number, and why you shouldn’t care about it.

The VSIZE column represents the amount of memory ‘marked’ for an application’s potential use. The important bit is that it’s not reserved, protected, or otherwise used; it’s simply marked, as in “Witch may need 11GB of RAM at some point.”

If you look at the VSIZE figures in total, they can be shockingly large. If you look at my screenshot above, there’s a summary at the top; one of the lines summarizes the virtual memory situation:

That 308GB of VSIZE reflects the memory that has been marked as possibly required for my currently running apps—yikes! But the reality is that this amount of memory will never be used or needed. Even more important is that application authors don’t control this VSIZE figure; the system does it itself, based on what the author’s code needs to do. So why is it so big? The honest answer is that I don’t know why, nor seemingly does anyone out there, at least based on some internet searches.

You can, however, see exactly what’s in that huge VSIZE space by using the vmmap tool. Enter this command in Terminal:

vmmap -resident `ps ax | grep [w]itchd | cut -b 1-5` | grep "Summary for" -A 999

That looks complicated, but what it does is run vmmap on the process ID of witchdaemon, and then displays only the summary portion of the output (as there are thousands of lines). The output on my machine is as follows:

==== Summary for process 66301
ReadOnly portion of Libraries: Total=143.7M resident=80.9M(56%) swapped_out_or_unallocated=62.7M(44%)
Writable regions: Total=8.4G written=7248K(0%) resident=30.0M(0%) swapped_out=0K(0%) unallocated=8.4G(100%)

REGION TYPE                      VIRTUAL RESIDENT
===========                      ======= ========
CG backing stores                  9100K    5824K
CG raster data                      228K     192K
CG shared images                   1280K    1256K
CoreGraphics                         16K       8K
CoreServices                       6232K    6232K
IOKit (reserved)                  256.0M       0K        reserved VM address space (unallocated)
MALLOC                            337.2M    6520K        see MALLOC ZONE table below
MALLOC (reserved)                   7.8G       0K        reserved VM address space (unallocated)
MALLOC freed, no zone              72.0M     196K
MALLOC guard page                   104K       0K
MALLOC metadata                     740K     260K
Memory tag=240                        4K       4K
Memory tag=242                       12K      12K
Memory tag=243                        4K       4K
STACK GUARD                        56.0M       0K
Stack                              9752K     116K
VM_ALLOCATE                        16.2M    16.1M
__DATA                             12.1M    9808K
__IMAGE                            1240K     344K
__LINKEDIT                         36.8M    10.9M
__RC_CAMERAS                        248K       0K
__TEXT                            106.9M    70.0M
__UNICODE                           536K     456K
mapped file                        23.3M    8492K
shared memory                     135.8M   111.6M
===========                      ======= ========
TOTAL                               8.8G   247.4M
TOTAL, minus reserved VM space    825.0M   247.4M

                                          VIRTUAL   RESIDENT ALLOCATION      BYTES
MALLOC ZONE                                  SIZE       SIZE      COUNT  ALLOCATED  % FULL
===========                               =======  =========  =========  =========  ======
auto_zone_0x100263000                      256.2M      4240K      17546      1698K      0%
DefaultMallocZone_0x1001d0000               72.0M      2168K       7793      1597K      2%
DispatchContinuations_0x10026c000           8192K        96K          1         32      0%
environ_0x100202000                         1024K        12K          1         16      0%
DefaultPurgeableMallocZone_0x1007d6000         4K         4K          0         0K      0%
===========                               =======  =========  =========  =========  ======
TOTAL                                      337.2M      6520K      25341      3296K      0%

This command shows you the breakdown between what’s marked (VIRTUAL) and what’s being more actively used (RESIDENT). The lines I highlighted in red show three items that take no RESIDENT RAM, but have huge VIRTUAL values. Add them up, and of the 8.8GB in total VSIZE, roughly 8.1GB of it is taken up by things that aren’t using any RAM—and that aren’t controlled by Witch.

The RESIDENT column shows Witch using 247MB of RAM, but that doesn’t seem to be accurate either. To me, the best summary of Witch’s actual memory usage is found in the Inspect panel in Activity Monitor; here’s what it looked like while writing this blog entry:

Here you can see that the witchdaemon process is using only 20MB of real memory, has 163MB of shared memory (used for inter-application communication, as I understand it), and has 7MB of private memory. (We are rapidly approaching the limits of my knowledge of OS X’s memory management system, so I’ll stop now!)

In summary, Witch’s VSIZE figure is high. But it’s nothing we’re doing to create it ourselves, and it’s not something we can reduce. The biggest chunk of it, the 7.8GB for MALLOC (reserved), isn’t anything we can remove, as it’s the OS that’s putting it there. Why is it putting it there? Who knows. But here are a couple of related articles that show it’s not a Witch problem:

Finally, Apple’s support article on Using Activity Monitor contains some tips on how to use Activity Monitor to understand memory usage.

Avoid a Mountain Lion bug that can affect Name Mangler

October 31st, 2012 by Rob Griffiths

Recently, we’ve been getting a few complaints from users, complaining that Name Mangler won’t accept dragged and dropped files.

We were trying to figure out what was going on, given we haven’t changed those apps. It seems the answer is a bug in Apple Events (which handle inter-application communication) that was introduced in 10.8.2. This blog entry explains the problem relative to “Open in Finder” no longer working.

Most importantly, that blog entry also contains a number of fixes. The least painful, though most geeky, is to open Terminal (in Applications > Utilities), paste this command, and then press Return:

sudo killall -KILL appleeventsd

When prompted, enter your admin password and press Return again, and you’re done.

This command forces the Apple Events engine to relaunch; once that happens, the issues you’re experiencing will go away, at least for a while.

Hopefully Apple will fix this in 10.8.3, as it has the ability to interfere with any program that communicates with another application.

Moom and Tweetbot for Mac

October 19th, 2012 by Rob Griffiths

If you use Moom and Tweetbot, get Tweetbot 1.1, as it addresses the issues discussed below. This article remains here for historical purposes only.

There’s been quite an explosion of Twitter discussion about Tweetbot for Mac and Moom this morning. The key issue, of course, is that Moom doesn’t work with Tweetbot for Mac. Instead of trying to carry on numerous 140 character conversations explaining the issue, we thought we’d use this blog post to explain exactly what the issue is, what we’ve done as a short-term fix, and what the long-term fix should be.

Why doesn’t Moom work with Tweetbot for Mac?

Moom relies on something called the Accessibility system to do what it does. The good news is that OS X includes Accessibility support automatically in standard windows. That is, if the developer uses OS X’s built-in tools to work with windows, Accessibility support is a free add-on—the developer doesn’t need to do any extra work to support Moom.

But some applications use custom window code—for various reasons, they choose to create the windows and buttons on their own. In those cases, Accessibility support must be added by hand.

Can’t you fix this?

Not entirely, but we can work around certain aspects of the problem. The engine behind Moom is based on Accessibility support, and being able to see the button locations to make Moom’s zoom button controls overlay appear. We also use the Accessibility system to perform certain sanity checks to make sure we don’t resize windows that really shouldn’t be resized — experience shows that you shouldn’t rely on whether those windows advertise themselves as being resizable.

That said, we realize that theoretical explanations don’t help our customers. So we implemented a workaround in this Moom beta (build 3045). We did two things in this build:

  1. We skip the aforementioned sanity checks, which allows Moom’s keyboard mode, custom controls, and snapping mode to work with Tweetbot.
  2. We’ve implemented a Tweetbot-specific workaround for detecting their non-reporting green zoom button. This is a conceptually horrid thing to do, because if the Tweetbot UI changes, there’s a good chance our workaround will then fail. The upside, though, is that hovering over the green button in Tweetbot now shows Moom’s palette.

We suggest installing this release of Moom without overwriting your existing (App Store/independent) copy; put it in a sub-folder in Applications, or somewhere else entirely. That way, you can easily revert to the release version if you have to do so. We’ll roll these changes into our next update, at which time you can then remove the custom version and update your “real” version of Moom.

Are there any issues to be aware of when using Moom and Tweetbot?

There are a few things you need to be aware of when using this workaround version of Moom with Tweetbot:

  • Tweetbot has a maximum window width (for any given single-column window), something we’ve not seen in any app with resizable windows. This means that even though you can use the palette and keyboard to resize the window, you can’t force it to get wider than Tweetbot allows. (If you snap together two or more columns, of course, the window can be wider, and Moom appears to properly handle the merged window.)
  • You can move Tweetbot windows completely offscreen with the keyboard controls. That’s because the window doesn’t have a title bar, and as such, isn’t automatically protected from such actions by the OS. To prevent issues here, we suggest using the “Move – Confine to display” keyboard controls, instead of just “Move.”
  • It’s fragile. As noted above, our solution is very much dependent on Tweetbot not changing their interface at all. If they move their green button location, Moom’s hover palette will stop working. If the pop-up palette stops working after a Tweetbot update, this is most likely the cause of the problem.

What could Tapbots do to fix the problem on their end?

The easiest course of action for them would be to add a bit of code that exposes the buttons in their custom window to the Accessibility system. On the first day the initial Alpha release of Tweetbot came out, we contacted them about this and offered to send a bit of sample code that does just that — well-tested code that a number of other developers have used to make their applications work better with Moom and the Accessibility system in general.

We never heard back from Tapbots regarding our request, and we never saw them reply to the countless users that asked them about this on Twitter. So we followed up again this morning, and this time, we did hear back. The good news is that Tapbots has Accessibility support on their to do list, so it’s coming. The bad news is that there’s no definitive timeline, but they’re going to do their best to get it done sooner rather than later.

If you’d like to see Moom and Tweetbot work together the way they should—and not thanks to some far-from-ideal workarounds we’ve put in place—the best course of action is to contact Tweetbot support (there’s a button at the bottom of that page), and politely ask that they add Accessibility support, and/or contact us for assistance, as we’re willing to help. (In addition, if you’d like to use wider Tweetbot windows, you might also ask them for that; we cannot override the application’s stated maximum window width.)

Butler 4.1.14 released

October 12th, 2012 by Rob Griffiths

Butler 4.1.14 is now out, and if you’re running OS X 10.8.2, it’s a very highly recommended update. That’s because the main purpose of this release is to work around a bug that Apple introduced into inter-application communication in 10.8.2. The result of this bug is that Butler would appear to hang at times, typically when it was talking or listening to iTunes.

We’ve worked around that bug, and fixed a couple of other things, and the result is Butler 4.1.14. Get it via in-app updating, or by downloading it directly from the Butler page here.

Obligatory footnote: Yes, we’re still planning on releasing Butler 5. We don’t yet have a beta or release date, but as soon as we have either, we’ll make sure everyone knows about it.

Moom 3.0.1 adds retina support

October 2nd, 2012 by Rob Griffiths

Hot on the heels of the retinaized Witch comes Moom 3.0.1 with the same high resolution support for the stunning retina Macs. There are also a number of other bug fixes in this release, so it’s highly recommended for all Moom users.

Direct purchasers can get the update via in-app updating, or by downloading a new version from the Moom product page. App Store users should soon (if not already) see the update in the Updates section of the App Store application.

Note: Because this is a bug fix release, we were able to update the App Store version of Moom, too. Long term, barring changes in Apple’s policies, App Store users will want to (for free) migrate to the direct sales version. Here’s how (and why).

Witch 3.9.2 brings retina display support

October 1st, 2012 by Rob Griffiths

Witch 3.9.2 has been released, in both the App Store and via our web site. The big news in this release is support for retina Macs, along with a workaround for duplicate entries for Total Finder windows in the window switcher. We’ve also done our best to make Witch work better with Desktops in Mountain Lion, and fixed a glitch that could prevent preview images from displaying.

Direct purchasers can get the update via in-app updating, or by downloading a new version from the Witch product page. App Store users should soon (if not already) see the update in the Updates section of the App Store application.

Note: Because this is a bug fix release, we were able to update the App Store version of Witch. Long term, barring changes in Apple’s policies, App Store users will want to (for free) migrate to the direct sales version. Here’s how (and why).

Witch 3.9.2 requires 10.7 or newer, due to changes in Xcode. If you’re running 10.6.8, you’ll want to remain with Witch 3.9.1. We’ll do our best to bring back 10.6.8 support in a future update, if we can.

Key Codes 2.0 released

September 27th, 2012 by Rob Griffiths

Key Codes 2.0 is now available via the Mac App Store and directly from our web site. This free utility is of interest mainly to developers, and anyone else who’s curious about the actual codes their keyboards send to the OS.

Version 2.0 of Key Codes is Many Tricks’ first retinaized application (Moom and Witch will be next, and will hopefully be approved for sale shortly; stay tuned for news on that front.)

Beyond support for retina display Macs, Key Codes 2.0 will keep the last entry visible as you scroll back through history, and includes a handy Clear button. Direct versions now include Sparkle, for easy in-app updating.