Archive for December 2008

Version 0.33

December 31, 2008

Version 0.33 (beta) is out! Download the latest version here.

This update fixes a bug in the “Mute Internal Speakers” Automator action.

It also includes fixes from Version 0.32, which I had not officially announced, pending more feedback from testing.

Version 0.32 restored Adium integration, and included some minor UI tweaks.

As always, updating is very strongly encouraged during the beta period. I try hard to make the latest build work, but I do not support old beta versions. Please let me know if you find any bugs.




The Technical Story of the Adium Fixes in Version 0.32

December 31, 2008

Here are the problems I had updating my Adium plugin for version 1.3 of Adium, in the order they were discovered.

First, Adium plugins now must declare a minimum version of Adium. If you don’t say “I require at least version x.x of Adium” then Adium assumes the plugin is too outdated to work and won’t load it. (Turns out that was the right assumption for my plugin!) You declare a minimum supported version by adding a value for AIMinimumAdiumVersionRequirement in your info.plist.

Second, AppleScript support for getting the current status message is broken. So I had to add a way for IMLocation to ask the plugin for the current status message. (It also means that I’m stuck requiring a plugin for any integration with Adium, which is a shame.) For what it’s worth, I prefer the new AppleScript interface for Adium (modulo the “not working right now” bit).

Third, the way plugins are written for Adium has changed. From a software-engineering perspective the changes are for the best, and will make a better Adium. But of course I’m complaining because I had to do more work :-).

Plugins used to inherit from AIPlugin, which had a field named adium that was analogous NSApp. Now plugins conform to the AIPlugin and AIPluginInfo protocols, and can inherit from anything. (Hint: #import <Adium/AISharedAdium.h> will give you the adium back, but now as a proper global.)

Fourth, the way I was updating the status message for Adium wasn’t working so well. And the more I looked into it, the more it looks like very little (if anything) was changed in Adium. It just had a different way of dealing with statuses that wasn’t working out all that well for me.

Solving this issue took me longer then solving all other problems combined. But in the end it was definitely worth it. I have better integration with Adium now. And I was able to get rid of some update-throtteling code of mine that prevented too many changes to the status being made too quickly (Adium is now smart enough to do that internally!).

Fifth, testing, testing, testing. All code that’s written must be tested. And because so many changes were made to Adium as well as my plugin’s code, I waited a few days before officially pushing my changes, to allow more time for bugs to be discovered.

Adium Support is Broken

December 24, 2008

Regretfully, integration with Adium isn’t working right now.

I apologize for releasing without adequate testing.

I did not change any of the Adium-related code from version 2.9 and I foolishly assumed it all still worked because nobody had complained. But in the 13 months since I had last tested my Adium plugin, Adium was updated in a way that broke it. I had gotten out of the habit of using Adium (I prefer iChat’s simplicity and video capabilities) and so I missed this issue completely.

Unfortunately, it looks like getting the status message from Adium with AppleScript is broken, so I don’t yet have a fix out.

I can get the status type (eg away, available), but without a way to get/set the status message there’s not much useful I can do.

I am working on updating my Adium plugin so I can ask it for all details of the the current status. I expect a fix shortly, holidays permitting.

Leopard Only

December 22, 2008

I owe you an explanation of why version 0.30+ of IMLocation now requires Mac OS X 10.5 Leopard. Originally IMLocation ran on both Leopard and Mac OS X 10.4 Tiger, so why the change?

As I write this, the Omni Group’s data shows 54.7% of people still using Tiger. The number is decreasing, but it’s still a majority. Alienating a majority of potential users is not something I do lightly.

Practical Reasons


At the highest level, IMLocation does stuff so you don’t have to. It all started as a small project in college to get my computer to update my iChat status when I changed classes. That means IMLocation is fundamentally an automation tool.

In Tiger, Apple introduced, “Automator, your own personal robotic assistant that will take care of whatever task you give it.” But, partly out of shortsightedness, and partly because there wasn’t (yet) support for editing Automator “workflows” graphically, I rolled my own “ActionsEditor“.

Then Leopard introduced powerful new widgets that let third-party applications construct Automator workflows in the same way does.

It just didn’t’ make sense anymore for me to maintain my own Automator knock-off, when I could use the real thing. And, the real thing requires Mac OS X 10.5.

Another benefit of using Automator, now people can use special actions that IMLocation can do (e.g. disabling built-in speakers) in their own workflows.

Support and Quality Assurance

Writing code that runs on two operating systems obviously means more work, and that’s a reason for dropping Tiger support. But a bigger problem I had was quality assurance.

Since I don’t have dedicated testers, I have a lot of trouble doing enough testing of things I don’t use day-to-day. It’s not something I’m satisfied with, but it’s something I have to accept, given my resources.

I only have one computer and it runs Leopard. I don’t think I can do the necessary quality assurance to be confidant that things work on Tiger, because I don’t spend enough time in it.

Only needing to test one operating system means, I can ship with fewer bugs.

New and Improved

Leopard also introduced several technologies, like Objective-C 2.0, that are a big help to programmers, but can only run on 10.5. My hope is that by using them, I can deliver a more useful and stable product faster.

Personal Reasons

Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!

The Red Queen

Technology has a shelf-life, and a learning curve. To stay on top of things I need to move.

Time to Learn

A new programming technology is usually bundled with a whole new way to do software engineering. For example, you need to know what Object Oriented Programming is to get the most out of C++, and even if you grok C++, you have to understand what “message passing” implies to get the most out of Objective-C. Just writing code the same way you always did in a new language won’t cut it, you need to experiment, and try new things. But that takes time.

Writing code that only runs on Leopard gives me the time to actually practice programming with newer technology. There’s no substitute for writing code.

Garbage Collection

It took me a long time to finally understand memory management in Objective-C; it was one of the biggest stumbling blocks to writing good Objective-C code. And then Leopard introduced garbage collection (GC), which is a whole new way of (not) doing memory management.

GC promises to make writing code much easier. But in my experience, when you have an issue with memory in a GC-ed system, it’s much more … esoteric … to understand and fix. It’s a poster-child for “there’s no substitute for experience”.

the iElephant in the Room

To write code for the iPhone, you really should understand Objective-C 2.0 — the iPhone’s frameworks use it heavily.

Transitions IMLocation to Objective-C 2.0 is much better practice for iPhone programming then writing Objective-C 1.0 code that is compatible with Tiger.

Version 0.31

December 16, 2008

Version 0.31 (beta) is out! Download the latest version here.

This update fixes a bug that kept IMLocation from asking for the name of a location it did not know.

It also fixes an embarrassing spelling error in an “are you sure?” dialog, which to be honest is something of an embarrassment itself since the best solution is to make the operation undoable so that useless dialog wouldn’t be necessary. But unfortunately I have higher priority usability enhancements to make first, like insuring that basic functionality is rock solid.

As always, updating is very strongly encouraged during the beta period. I try hard to make the latest build work, but I do not support old beta versions. I will probably be pushing updates very regularly in the near future because, things aren’t as stable as they should be yet.



Version 0.30

December 16, 2008

After more then a year, Version 0.30 (beta) is out! Download the latest version here.

There are many “under the hood” changes, but the most obvious changes are adding Automator support, which means Mac OS X 10.5 “Leopard” is required.

Additionally, the options for what to do when an application is being used have been simplified. It turns out it was never useful to automatically unmute sound when the DVD Player is in use.

As always, updating is very strongly encouraged during the beta period. I try hard to make the latest build work, but I do not support old beta versions.