1) PREFERRED: implement the Snarl/GfW API directly in its code. This is so incredibly easy it can be done instantly and with zero bloating. No nasty linker libraries, COM objects; just simple in-line code.

2) NEXT PREFERRED: create a plugin which interfaces between the application and Snarl/GfW. WinAmp springs immediately to mind here. NullSoft don’t want to keep updating their core app code so they’re kind enough to create an API for 3rd party devs to use. So why not use it?

3) FINALLY: if all else fails, create a proxy application. This would be a separate application (i.e. process) which would run and do whatever necessary (screen sniffer, message queue sniffing, etc.) to capture the events it wants and then forward them to Snarl or GfW.

Also, Snarl offers an alternative to (3) whereby the proxy application can be coded as a plugin to Snarl itself. This has the benefit of not chewing up resources as a separate process but instead runs in Snarl’s own process space.

The BIG ISSUE here is that developers of applications need to get their head around the idea that Windows now has notification engines available for it. There’s no animosity between the Snarl and GfW teams so your app either supports Snarl or GfW or -ideally for the end user- both.

I agree that there needs to be a common notification API/framework/whatever and I’m sure we’d all be happy to (a) contribute and (b) subscribe to it.

In short, the only thing Growl has over it’s Windows opposites is a head start.

“It is not about doing the work yourself, it is about making it more difficult for developers to do the wrong thing which in turn would make it easier for end users.”

On Mac, the APPLICATIONS HAVE IMPLEMENTED GROWL. Growl didn’t integrate the applications.

The Growl team has, in a few cases, included apps like GrowlMail or GrowlSafari, and even HardwareGrowler … but those are very much external apps like the ones that Growl for Windows and Snarl use

The difference is that on OS X they didn’t have a “notification tray” like Windows did at first, and Growl was a good solution, and eventually became so common that many Mac developers have chosen to implement support for it.

The situation on Mac for third-party apps is exactly the same as on Windows: when a developer writes an app without Growl support, users have to complain and ask for it — the difference is, on Mac, Growl has been around for over 5 years, and has a much higher percentage of users.

Growl for Mac has the exact same issue as Snarl/GfW, the only thing it has in it’s favor is time.. it’s been out long enough for developers to get use to having it as “standard”.

Growl for Windows and Snarl aren’t even the issue, third party devs don’t have to worry about it, all the NEED to support is the Growl PROTOCOL…

So the major issue seems to be that app developers aren’t currently integrating Growl/Snarl support in their apps.. the only thing to change that is to ask for it.

You are not seeing the difference between Mac growl and the Windows ones: in Mac applications themselves are integrated. In Windows third party developers have to do that and that calls for a framework in programming sense if you know what I mean. And frameworks can enforce their views of best practices. Look at MS Enterprise library, most of Ayende Rhino stuff and so on. There are plenty real frameworks out there for you not to call these two a framework.

A keyboard can SEND commands to *any* application it wants to — the applications are expecting messages from the keyboard.

But in that analogy, the notification framework is the application, the keyboards are the other applications — they’re the ones that have to SEND the notifications.”

Both Growl and Snarl provide frameworks and libraries to help application developers take advantage of their notification frameworks — but neither of them can force the app developers to use them (any more than the original Growl can).

What’s your suggestion?