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

This entry was posted on Friday, October 19th, 2012 at 10:59 am by Rob Griffiths, and is filed under Moom, Products. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.