> On Nov 7, 4:43 pm, Rudy Richter <[email protected]> wrote: >> This is actually on my list of abandoned projects to fix. Jesper has >> been too busy to update his Google+Growl so he put it up on github and >> i'm going to be working on it. I'll try and get a build posted this >> week. (I seem to be collecting unwanted projects as of late) > > BTW, I'm curious about whether Growl 1.3 broke backwards compatibility > with version 1.2 by changing its public API . If this is the case I > will be less than happy with Growl developers.
The issue is as follows: * The older method of communicating between Growl and the hosted framework cannot work within the sandbox that Apple introduced in Lion. * Apple is requiring everything in the app store to be sandboxed starting in March of next year (originally they had targeted November 1st). As a result, everything in the app store would stop working with Growl because the communication method would be cut off from within the sandbox. This would've been... bad. So, Growl needed a redesign so that it could work with sandboxing. Growl 1.3 supports GNTP properly (and uses an XPC to do so from within a sandbox, if necessary), but also still supports the older method if you're not in a sandbox; this allows Growl 1.3 to still receive notifications from older apps. Similarly, the 1.3 framework also works with the older method, so an app built using the 1.3 framework can talk to 1.2 just fine. (And the 1.3 framework also has a mini-Growl built in, allowing notifications to display even if Growl itself isn't installed.) So, in theory, everything's copacetic; you use the old method for legacy support, and the new method where it's required by the security model, and everything goes nice and smooth. Where the problem arises is that the older frameworks implemented the 'isGrowlInstalled' convenience check by literally looking for the old prefpane on disk. The old prefpane no longer exists -- in order to play with all of the App Store rules and get Apple's blessing, Growl had to turn into a standalone app. This wouldn't be a problem -- the notifications will still run just fine regardless of what isGrowlInstalled returns -- except that instead of just generating notifications, a lot of third-party apps use an older framework and used the isGrowlInstalled convenience method in wrapper logic to determine whether or not they should fire notifications /at all/. And because Growl just worked, a lot of things never bothered to update their frameworks. (I'll own up; I was one of the developers who did that, too. Trillian prior to build 1.2 won't work with Growl 1.3 for precisely this reason.) In such a case, the older framework using the 'is there a prefpane in the location I expect' check, returning isGrowlInstalled = NO, in an application that uses that check to determine if it should generate notifications at all... well, the end result is no notifications. The current 1.2.3 framework (for people who still need to support PowerPC or Leopard) and 1.3 framework can both be used as drop-in replacements to correct this, which is why GrowlVersionDetective can solve the problem as an interim solution for anything that hasn't released a new update.
signature.asc
Description: Message signed with OpenPGP using GPGMail
