DrunkenBlog

Christopher Forsythe, of Growl for Mac OS X

Another special treat for my 13 14 loyal readers: Christopher Forsythe, the creator of Growl for OS X was gracious enough to sit down for another lengthy chat about the project and where it's heading.

Chances are, this'll be the first time many of you have heard of Growl, and there'll be linkage at the end to get you started.

At first glance, it might be easy to dismiss Growl as superfluous eye-candy. However, once you spend a bit of time with it, you realize what it's trying to do and just how much it can help you.

If you're familiar with Growl, feel free to skip to the interview.

As a primer:

Growl is open source, with two parts: The Growl app, which the user downloads and installs and runs in the background and controls via the System Preferences, and the code a 3rd party app builds in to give it Growl support. You can also send messages through it yourself via the CLI, AppleScript, etc.

Part of the problem with describing Growl is that it's like RSS: if you read enough on the web, and are willing to adjust how you do it slightly, you'll get a massive productivity boost. If someone only reads a few websites, it's easy to wonder what all the fuss is about.

And if you use your computer for less than four hours in a day, very soon you might be wondering what all the fuss is around Growl. Growl isn't huge yet, but it will be, as like RSS it allows you to shape how information is funneled to you, but for the simplest of things: alerts and notifications.

One of the problems with a multi-tasking, internet-connected operating system is that you're bombarded with information, but then have to physically do things in order to get what you really want. And like death from a thousand cuts it slows you way down.

iChat is an especially egregious example of this: when you get a new message, iChat throws up a little bubble letting you know you have a new message and from whom. This is good, as there are times when you don't want to stop what you're doing to chat with a random person. But iChat, in it's own passive-aggressive way, insists that you deal with it, because that bubble doesn't go away. It just stays there, taunting, only a slight step above the usual horrid bouncing dock icons.

These are some of the things Growl is designed to make better, and why Growl has me excited. Over the course of the day, eliminating these constant little iterruptions really does add up.

Without further ado:

What's your coding background, and how'd you end up using Macs?

Very literally I am still learning to code. Right now I'm more of a project manager in respects to Growl, but hopefully soon I'll be at a level where I am comfortable with my coding abilities.

A very wise hacker once told me that in order to learn how to program, you need a book. In order to program well, you need a project. Something you can learn with, and something you can break things on. That originally was iTonamaton, a Cocoa IRC bot for OS X. Well... that project is now dead (looking for someone who will take it over if they wanted to).

Now it is Growl, except this time I can pick any assortment of languages to go with. One day I can be attempting to learn Python enough to post a notification with it, the next I can be reading the Ruby book in order to try to make a Binding for Growl.

Either way I'm really happy working on it, and attain my goals. I do have some code in Adium, the original version checker for that project was some of my code with a lot of help from everyone.

As to the second part of your question, I got a Mac to really just try it out. Not a lot of people in my area had even heard of a mac, much less knew how to use it. I had been using Linux for a while, and other operating systems too. I really wanted something different, so I started investigating my options. It was either OS X, Plan 9, or some other random OS that I was going to try. My computer was starting to show its age at the time, and I also wanted a laptop to use with school.

I priced different systems, and for the price, the iBook was cheaper/easier. My time was kinda precious, so setting up the system and learning it is something that came into the equation. I also wanted to do wireless, which kinda killed Plan 9.

Is your iBook what you're using to develop Growl?

I use my iBook. It's a nice little 14 inch 700 mhz machine. I also use some shells on different machines around the world, and honestly couldn't tell you what those are without a little investigation.

Help me out here: Programmers usually crave as much screen real estate as humanly possible, yet the iBook is limited to 1024x768 and only supports video mirroring... how are so many Mac developers able to do their thing on iBooks?

It's comfortable. My hands fit, and it sits in my lap. Also, I originally didn't intend to start learning to code on it, I kind of just walked into that. I've used large sized screens, they are nice, but for what I do, the iBook works pretty well.

My original requirements were that whatever I bought ran ms office, that I could run some sort of local terminal, and that it was a laptop. This thing does a ton more.

Growl is called a 'global notification system', which tells most people absolutely zero about how it can help them. How would you explain what Growl does, and how it can help your average user?

That term was more for developers than for users. What this means is that any app can use Growl for their notifications. That's the global part.

The system part is that users can decide what to allow to actually send growl notifications. Thus giving the user the power.

Also, this allows users to decide how the notification should look from the predefined notification types. The system part also means that users can configure notifications to not appear. They can turn off certain notifications for apps.

An example is that Colloquy has about 21 notifications. If you didn't want 3 of those, you can turn them off in Colloquy. Or you can do it in Growl, and not worry about configuring Colloquy at all for this.

Growl gives the feeling of an itch being scratched... what was the catalyst that made you sit and say, "You know, what's missing from Mac OSX is a global notification system."?

It's partially from a long standing issue from within the Adium project, and partially from using other applications with different notification systems and going "Ugh".

Adium's bigger problem with notifications is that nobody could decide what was best, which led to the larger problem of the huge amount of preferences in Adium for the Event Notifications. Users of Adium who have used it for a longer time will also take note that the Bezel that was the earlier notification system had an even larger amount of preferences. This is because different people desire different things.

It's not bad to have all those preferences, in fact that's part of what makes Adium cool, the fact that it works well for many people. But this was just for one application. Multiple applications may need this level of customizability, meaning the user will need to reconfigure it to how they like over and over again. Plus the developer(s) of other applications will need to reimplement basically the same thing over and over again. That's part of where it came from.

The other part is that myself and others were really just tired of dock bouncing or applications popping up a little window saying "yada yada", but that I would have to switch to that window anyhow to look at that.

If I'm working on a urgent email, but a dock bounces somewhere else.. I can either ignore it and keep working on the email, or ignore the urgent email for a minute and work on the app that had the dock bounce.

Either way, I wouldn't know what the other app is doing without switching to it. And this is where Growl really excels. Meta data about whatever you have trying to notify you, giving you a more informed decision.

What led you to decide to distribute Growl as open source instead of shareware or freeware? It's your baby after all, filling a niche, and it's hard to find a better market for shareware than on the Mac...

When I first approached Karl (the other lead) with the idea for Growl (wasn't called that back then, heh), he liked it a lot as well. He had already written the Bubbles for Colloquy, and him and Tim from that project were OK with using that for Growl. So we had that point.

I also think that in order to make something like this work, you can't sell it. Users who would help to push the software wouldn't have bought it. Later I found out about other notification systems, which for the most part hadn't gone past a very small group. I think the main part of why these didn't fly is because they were not free/open source.

With the way Growl is right now, anyone can pick up on how to make a display, and anyone can read the code and add on features/fix parts. And hence the power of open source, and why we have so many developers on Growl itself. Without everyone on the Growl team, we wouldn't have Growl.

Speaking of the Growl team, the first thing you notice when looking through the code and commits is the large number of contributers, and the second being how many of them have names that are associated with other projects. Who all is working behind the scenes, and have you been surprised by the number of people jumping into the code?

Yes, I was and still am very surprised at the response from all these great developers. We have a ton of developers who I never expected would be interested in this sort of thing.

In no particular order, I'll list each, and the other project(s) they are affiliated with. (Sorry if I forgot anyone, and anything you are associated with):

• Christopher Forsythe: This is me of course. I work on Adium, Growl, and I do a little bit on IMGames which lets you play games between chat clients which support it.
• Karl Adam: While not working on Growl, Karl also works on a number of other projects. Some of these are his own making (Bitzy, Nosferatu), and then another is Colloquy.
• Kevin Ballard: Kevin is out of TildeSoft (think Rendezvous-Browser, Safari Source and Notification Watcher). He also works on Colloquy.
• Toby Peterson: Toby works on the OpenDarwin project, specifically DarwinPorts.
• Vinay Venkatesh: Vinay is working/has worked on pic2icon, mp3alarmclock, MacAmp, Cocoa Sprite Kit, and Adium. Vinay also worked for Apple Computer and for Lucent at some points.
• Mac-Arena the Bored Zo: Mac-Arena works on the Adium and Growl project, and has contributed to ShadowIRC.
• Nelson Elhage: Nelson works on Adium, Growl, and also works a little on IMGames.
• Jorge Salvador Caffarena: Jorge works on Adium and Growl. When he's not working on those, he works at Kualo Software.
• Matthew Walton: Matt has contributed in some ways to gtkmm and gtk2hs. Growl is the first project he has commit access to.
• Adam Iser: Adam is one of the leads and is the founder of the Adium project. He may also be looking for a coding job shortly, if anyone is looking for someone to code for them.
• Evan Schoenberg: Evan is the co-lead on Adium.
• Patrick Linskey: Patrick is out of MIT. He is working on an application called iChatBetter that will hopefully make... well, iChat better. He also works on Solarmetric KodoJDO.
• Derek Scott: Derek is working on an application called ForumGrowl. I think it'll revolutionize the way at least I use forums, and hopefully other people too.
• Don Smith: This is the first project that is public that Don has worked on.
• Mark Rowe: Mark works on Fire, libmsn, a little on Trac.
• Graham Booker: Graham also works on Fire.
• Jeremy Rossi: Worked hard on the Python bindings for Growl, and created the Sailing Clicker script.
• Timothy Hatcher: Tim is the lead developer of Colloquy, a Cocoa IRC client. He and Karl made the Bubbles for Growl.
• James Van Dyne: As far as I know, James has only worked on Growl and GrowlTunes.
• Ender: I do believe this is Ender's first project to work on.
• James Cox: Works on our PHP, and takes care of hosting for Growl and other projects.
• Andrew Wellington: Andrew works primarily on Proteus. He also made MacYAC, which will be distributed when Growl releases .6. This is a client for the YAC server on Windows which displays caller ID information from your phone. Andrew also contributes to the Adium and Fire projects.

Woa, just them? :) Still, even with lots of coders interested in the source, Growl would seem to be heavily bound by the 'network effect', meaning the more apps supporting it the more valuable it is.

To that end, how many apps currently support it, and have you seen increasing interest from developers looking to include support?

I'll answer the second part first. I've received at least 3 emails just this week regarding Growl support in applications. One of those though was in response to an email I sent the author in the first place. Some people hadn't heard of Growl, others just had questions. Either way, I'm always emailing developers, and the response has been pretty good. Most people like Growl once they take a look at it.

As to the amount of applications can use Growl, that really depends on if you count the bindings or not. Without the bindings we wouldn't have quite as many applications. With them we have support for Growl in 19 3rd party applications, and 6 home grown ones. And this number is increasing weekly.

We now have Finder and Entourage support via Applescripts that will be distributed in the next version. There are also some 3rd party applications that I am hoping will have support in the next month or so.

The really cool part is applications I didn't expect to have a way to implement Growl, have implemented Growl in a fashion that I myself am amazed at, and find quite useful.

Drive Gauge is a prime example of this. It lets you know when a drive is x% full. Rather useful.

Bindings? What are these bindings you speak of?

Bindings are what is known as wrappers, basically wrapping one thing in another thing, for which you can then use in your desired tool. Some Bindings I can see being made are for C#, C++, Ruby, Lisp, Scheme, and Haskell. We have a RB Binding in the works too.

A Binding is what allows something written in one language, say aMSN for example, to use Growl, which is written in a completely different language. aMSN is written in Tcl/Tk, whereas Growl is written using Cocoa (Obj-C).

Bindings make it very feasible to implement Growl in things that would normally not consider using Growl at all.

Drive Gauge telling me my drive is x% full is a good example of a notification I might want to have thrown towards my cell phone or email, rather than sitting up on my display at home. How tied is the Growl daemon to the display?

Growl is not tied to the screen one bit. We have two examples showing that this is the case, the email plugin and the nslog one. The email one, well, emails notifications to you, whereas the nslog one writes to a log file.

Other things could happen too, stuff that we haven't thought of yet, but may be useful to others as well. Future applications such as sms would be rather feasible.

Since you mentioned AppleScript and Bindings, it's worth noting that there's an assortment of languages already supported, everything from Cocoa and Carbon to a slew of scripting languages. What kind of interest have you seen among scripters, and how difficult is it to throw up a Growl notification using AppleScript/Python/etc.?

Oh we've had a lot of interest. Lots of scripters like Growl, it's really easy to use with say Perl or Python. AppleScript is also easy to use Growl with, and many people have already made scripts using all of these.

Bindings really make it easy to use Growl in your language of choice, instead of using Growl in only one language. Each language is a tool, and not all tools can be used for the same purpose, same as with Growl. It helps to know that if you plan to implement Growl, then you are not limited to just one set of tools.

Not only that, but if you have a language that Growl doesn't support that you'd like to implement, it's not too hard a thing to make them.

How difficult is it for a developer to build in Growl support for their application?

I've had some developers tell me they have implemented support for Growl in their application in ten minutes. For most it takes a little longer than that, but overall we've tried to make it as easy as possible.

The hardest part is weak linking a framework. We're working to make things easier where we can, and if anyone has any feedback please email the discuss list with the problems (and possible solutions).

For drunkers who aren't developers, what is weak-linking in general and why is it the hardest part?

First you'd have to describe a framework. A framework is like a tool in a giant tool chest. You have a whole bunch of tools, but only one works to do what you need. Growl uses a framework called the GrowlAppBridge to detect if Growl is present. Applications use it to decide options for their apps at run time, among other things.

What weak linking does is make it so that, if the framework is not present, your app can still work fine. This is something needed for developers including Growl support in their application. It's not that it is hard, it's that weak linking isn't as straight forward as everything else is. Weak linking is more like just telling your application "Hey application, use this if it's there, if not, don't use it.".

There's another OS out there, which starts with a W, which has similar functionality built-in. The luster of this feature quickly tarnished when it was heavily abused with the equivalent of spam. Are there possible security issues with Growl, and the potential for abuse?

There are a couple of problems with the system that you are referring to. One of the problems as a user of this system (I originally came from Windows, and use it at work daily) is that the user can't control who netsends come from if they have it enabled. People can send them over the internet if you don't have it blocked. There is absolutely zero control that a user has, other than to just turn the blasted thing off. Which is what a lot of people do.

What we want to do, is allow for network notifications, but only if the user specifically turns them on. This is a per host thing, that will look similar to XCode distributed build preferences.

It will probably not make it in for a few more releases. But we are really aware of these issues as well. Most of the Growl developers have at one point or another used Windows, and know that this is a major concern for this system.

One of the great things about something like Growl is it absolves developers of having to roll their own solution to the problem; they're just plugging into a service. But services like these might be considered to be fundamental, and a fundamental service has a habit of getting rolled into the operating system. Is Growl on borrowed time?

Growl is licensed [BSD] so that Apple could snag up all the code, and with little or no work on their own, put the system into OS X (hint hint).

Apple has (I have heard, as I mentioned I never used a mac for more than twenty seconds before 10.2) done something like this before, so I can see it happening again. It would be rather easier to convince developers to implement support for Growl at that point, as basically we wouldn't have to.

Growl is licensed under BSD, so as you said Apple could just wrap it up and include it. But because it's based on Distributed Notifications, a Cocoa technology, does this pretty much rule out someone from the Gnome/KDE projects wrapping it into Linux?

Actually, think again. There are some projects out there now working to attain somewhat the same thing. The biggest part of that whole nutshell is the Desktop Notification Spec which Christian Hammond and Mike Hearn are working on.

Once this is done, then it would be easy to do pretty much the same thing as Growl, but in a way that fits Linux/BSD/others more.

We have MacOS 10.4 coming in six months or so, and with it, Dashboard. How do you see Growl and Dashboard integrating or coexisting?

I honestly think I'll use automator more than anything else. Dashboard doesn't impress me yet, I have a bad taste in my mouth from using Konfabulator, but other people like that sort of thing. I also think a lot of the widgets don't quite fit yet, but hopefully that will change.

On that note, a lot of people have asked for a display that they can customize using HTML/CSS/PHP/whatever web techonology that is normally used only in browsers. Thanks to the advent of Safari and WebKit, this is a lot easier.

Currently it probably wouldn't be feasible for 10.3, but maybe with the non-browser specific optimizations of webkit and what not, it'll be feasible later.

Why do you say it wouldn't be feasible for a display based on WebKit in 10.3 when, well, other apps you contribute to are doing it?

What the person originally requesting this was wanting, was for us to make it so that, for instance, they could get a notification that their GMail account received a new email. They'd click said notification, then it would expand, open up GMail, log in, open the new message, and display it there. They could choose to then use a Growl notification to send their email and do other things.

That's not what Growl is, nor what it is intended to do.

A webkit notification on the other hand would, in fact, be kinda nice. Defining within limits what your notificaton looks like is kinda cool. The problem here is that it would be too slow to display probably. A lot of us don't want to do the work to only find that it's slower than required for a notification.

Thus the problem, and why we are waiting for 10.4. With 10.4 and Dashboard, we should have optimizations that are not only used for a browser, but for non-browser things, such as what Growl does.

Some people are comparing Growl to Dashboard though, which is kinda the wrong line of thinking. Dashboard is a platform for easy application creation (if you know the technology already), one that you can push to the side if you need to even. Growl is a controlled notification system. The benefits of each are good for a lot of people, but I don't think they are very related in what they actually do.

All of this is to say, wait for 10.4 if you want CSS notifications, you might get it. But it needs to be evaluated.

Growl bubbles are able to expand vertically downwards, but seem to be locked horizontally which has been a point of contention for some. You've gone on record as saying you don't seeing horizontal expansion happening... why?

We had a rather lengthy 2-3 day argument just over vertical expansion of just the Bubbles. The consensus for now is to allow for vertical expansion in Bubbles only. Horizontal expansion will be re-evaluated at a later date, but right now it's an aesthetic issue in regards to multiple notifications at the same time.

It's good to be King. However, does it strike you as odd that you are giving users control over how they are bombarded with alerts and notifications, and then not giving them control over aesthetic issues? I.E., what might be aesthetically pleasing on an 12" iBook may not suit someone's needs on a 23" Cinema Display...

Here we have two separate issues. The issue with the larger displays will be addressed at a later date, possibly with new plugins fit to that screen size. So far we haven't had anyone with a Cinema Display bring to our attention that this is a real issue though.

This isn't really odd. The sideways expanding actually hits on a few issues. First, it's isolated to just a few display plugins, for which the authors don't want expansion. These are their babies, and they get pretty much full say of what goes on in a plugin. Later, we can have plugins that do more, and will better accommodate more people.

Another issue here is focus. We're trying to focus here on just notifications. The size of the notifications we have is enough to get an idea of what these notifications are about, and if you want more information on that kind of meta data, you start needing to go to the application sending the original notification anyhow.

We're still considering things, but a lot of people have voiced dislike of the proposed sideways expanding as well.

Ok, so sideways is out for now. But I got a fever, and the only prescription is getting my alerts from Strong Bad. The default themes for Growl bubbles are pretty and present the information cleanly, but there are only two. Is this a situation you see improving?

Well you are in luck. We have at least two more displays that will be available with 0.6, and possibly more. One is called Smoke, the other Music Video. Both should be pretty customizable.

In the coming months we should have more displays. We should hopefully have a lot of options for people by the time Growl hits 1.0.

And if you could get us permission from the homestarrunner folks, we could probably make a nice notification window featuring some things from their site. :D

If you could push a feature request or perhaps a bug on your wish-list to the top of Apples' radar for OSX, what would it be?

That's a tough one because there are so many to choose from. XCode needs to not crash, needs to not completely lag with doing auto-complete, needs to be a lot faster and handle modified files better, needs to be less buggy overall.

SCM [Source Code Management] in Xcode could use a lot of work with regards to cvs and svn integration. It would be nice to have built in auto-documentation tools, regression testing, refactoring utilities. Something to troubleshoot distributed notificatons would be awesome as well.

XCode is free, but the Windows developement tools I have heard are 100 times better when it comes to usability. I have never tried them, but if this is true I'll be very sad when I do try them.

Since you mentioned Distributed Notifications again, it's worth noting that these are basically messages fired out from one app to the OS, which then cascades them down to apps that are running and listening. What sort of performance hit, if any, does Growl place on the user's system?

Almost zero, like any app should. When first starting on Growl, I'd leave builds running for weeks at a time. I now leave Growl running all the time, with no adverse problems on my machine.

That's really the nature of Distributed Notifications though, it runs really low on the performance scale. If you were to leave an application monitoring Distributed Notifications on your system for say an hour, you'd have a pretty decent sized list of notifications to actually look through. And that's for the entire system. Distributed Notifications get sent back and forth on your machine all day long, and you don't even see it. That's why it's great for this type of system.

The biggest performance hit with Growl is when notifications display. They take up little in resources as well, which we are always working to make even less. This is part of why Webkit currently isn't something we want to look into.

As was mentioned above, we should be seeing MacOS 10.4 released within six months. From a developer point of view, what are you most looking forward to?

I'm personally looking forward to XCode 2.0. On the Growl side of things, we could possibly use CoreImage or whatever prettiness they are coming out with over at Apple. I am hearing good things about 10.4, but haven't really thought about it much as it's a good 3-6 months away.

What are you doing when you're not coding?

My wife and I spend a lot of time together. When we aren't hanging out it's probably because we both work, or are carpooling the hour to and from home and work. I also try to learn more things, reading what I can. I also have the strange habbit of wanting to help people.

Every time I mention I'm going to be sitting down with Christopher Forsythe, people just start babbling about tattoos. Could you elaborate?

Who told you that? :D

This one made me chuckle. How in the world did you find this one out? It seems I have a reputation for liking tattoos. I have 2 currently, and have plans for a lot more in the coming years. It's a rather old, rather expensive habit.

You're not getting off that easy. What and where?

Hahah :D

I have tribal art on my back and on my right arm.

In the spirit of the site, what's your alcoholic beverage of choice?

Gah! So many to choose from, can I pick two? Hehe :D

Different occasions call for different things. I like Grey Goose for occasional drinking. It's pretty smooth, and not too expensive. It also is available most places. Mixed with things it's pretty good.

drunkenbatman Addendum:

Growl is growing very quickly, and while it's a very solid foundation it's still rough in areas. There are parts of the experience that could be streamlined, but we're on the ground floor here and just a step away from the first.

For example, Adium comes with the plugin installed which can easily be turned on, while Fire and Proteus have more involved steps until their new versions come out.

Chances are there are apps you use that would benefit from Growl, but don't yet have support. In some cases, a user who knows AppleScript can essentially add this in themselves; in others they just need some users whispering in their ears letting them know they want it.

As promised, some linkage to get you started:

• The Growl Homepage.
• A list of applications that currently support, or have Growl support forthcoming.
• The Growl documentation, which, while it's very short and easy, you'll want to follow.
• When using the GrowlNotify command-line app, which I often do, I've found using a command like: echo "Rawr" | growlnotify "Hello" works best. If you're trying it from the sparse instructions, and it seems to just sit there, hit control+D which will fire it off.
• The Growl forums are a good place to report issues or to get ideas on how to use Growl.
• Don't ignore the bunches of scripts you can get as a package from the download page, as many of them are really worthwhile. As an example, GrowlMail is still very rough, while the AppleScripts are great.
• Do checkout GrowlTunes from the download page for iTunes integration.
• As mentioned in the chat, The Red Pill has a good page on integrating some existing AppleScripts with Mail, as well as using it with Quicksilver and your iPod.