Google Notifier
Phil
Is there any way to get Google Notifier to play nice with Growl 1.3?
I used to use Google+Growl, but since 1.3 I just get a "Growl wasn't
found, but can be installed" dialog whenever I run it.
Thanks,
Phil.
Will Fiveash
> found, but can be installed" dialog whenever I run it.
google notifier messages and now that I've updated to Growl 1.3.1 from
1.2.2 this is completely broken.
Rudy Richter
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)
-rudy
Will Fiveash
On Nov 7, 4:43 pm, Rudy Richter <r...@growl.info> 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)
--
Will
Will Fiveash
> 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)
with version 1.2 by changing its public API . If this is the case I
will be less than happy with Growl developers.
--
Will
Rachel Blackman
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.
Phat Bob
I think 1.3 should have been released via the MAS *but*:
a) it should have been free;
b) it should have come with a big "this will more than likely break" health warning;
c) GrowlTunes and HardwareGrowler should have been released via the MAS in parallel;
d) GVD should have been available (built-in?) from day 1;
e) More thought should have been given to providing FAQ's around "common" apps (1password, Dropbox and Skype for example).
Then, 1.4 should have been chargeable.
I think this would have eased the transition from non-MAS to MAS, from PrefPane to app and from non-sandbox to sandboxed.
Having GT and HG also available would have probably reduced the number of support tickets too.
This is just my view however - and of course hindsight is a wonderful thing.
Rachel Blackman
> While I agree and support all this - what frustrates me is that all of these changes have happened in one hit.
Unfortunately, until November 2nd when Apple decided to push out the deadline to March of next year, the official deadline for 'everything has to work with sandboxing' was November 1st. Thus, Growl 1.3 /had/ to do all the sandboxing-related stuff in something of a hurry.
Phat Bob
Rachel Blackman
> --
> You received this message because you are subscribed to the Google Groups "Growl Discuss" group.
> To post to this group, send email to growld...@googlegroups.com.
> To unsubscribe from this group, send email to growldiscuss...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.
>
Phat Bob
Will Fiveash
On Nov 8, 12:46 pm, Rachel Blackman <ceruleanspa...@gmail.com> wrote:
> 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.
supplied by the Growl API and if so, was it a public API meaning that
it was legit for apps to call? If that is the case I don't understand
why that method isn't provided by the Growl 1.3 API which should
simply return true.
If isGrowlInstalled was a private method that apps should not have
called then it's the app developer's fault that their app isn't
upwardly compatible with Growl 1.3. In fact, looking at
http://growl.info/documentation/developer/implementing-growl.php#isinstalledreturnsyes
I see:
"The 1.3 and 1.2.3 frameworks both will always return YES for the
isInstalled method. This method is deprecated going forward. Please
discontinue use of this method as soon as possible."
Does this relate to the isGrowlInstalled method and if so, why doesn't
the google+prowl plugin work with Growl 1.3?
--
Will
Rachel Blackman
> supplied by the Growl API and if so, was it a public API meaning that
> it was legit for apps to call? If that is the case I don't understand
> why that method isn't provided by the Growl 1.3 API which should
> simply return true.
It was public, it is still provided, and it does return YES. In other words, if you use current versions of the framework, it returns what you'd expect.
If you are using an older version of the framework and never upgrade, the framework itself was coded to look for whether the prefpane existed on disk and return that as the result; the convenience method in older frameworks is basically just a 'does this file exist in this location' check. As Growl is no longer in the same place on disk that it once was, that implementation in older frameworks returns NO.
Will Fiveash
wonder why this old framework couldn't have been overwritten by an
updated framework that provides the new is GrowlInstalled method. I'm
assuming the framework is provided by a dynamically linked library and
not statically linked by the app.
--
Will
Rachel Blackman
>>
>> If you are using an older version of the framework and never upgrade, the framework itself was coded to look for whether the prefpane existed on disk and return that as the result; the convenience method in older frameworks is basically just a 'does this file exist in this location' check. As Growl is no longer in the same place on disk that it once was, that implementation in older frameworks returns NO.
>
> Not being a Mac developer and thus never written code to use Growl I
> wonder why this old framework couldn't have been overwritten by an
> updated framework that provides the new is GrowlInstalled method. I'm
> assuming the framework is provided by a dynamically linked library and
> not statically linked by the app.
The framework is generally bundled into the app by most developers; if you were to pop open an application bundle and go into 'Contents/Frameworks' you'd find a 'Growl.framework' rolled into the app itself.
Now it is, in fact, possible to write a program which can go in and pop out the bundled framework, replacing it with a new one. Such a program actually already exists: it's called GrowlVersionDetective, and it's available from the downloads page at http://growl.info/downloads -- when run, it will find the various programs on your hard drive that have versions of Growl bundled, and can replace the framework with a more recent version.
Will Fiveash
On Nov 8, 3:45 pm, Rachel Blackman <ceruleanspa...@gmail.com> wrote:
> >> It was public, it is still provided, and it does return YES. In other words, if you use current versions of the framework, it returns what you'd expect.
>
> >> If you are using an older version of the framework and never upgrade, the framework itself was coded to look for whether the prefpane existed on disk and return that as the result; the convenience method in older frameworks is basically just a 'does this file exist in this location' check. As Growl is no longer in the same place on disk that it once was, that implementation in older frameworks returns NO.
>
> > Not being a Mac developer and thus never written code to use Growl I
> > wonder why this old framework couldn't have been overwritten by an
> > updated framework that provides the new is GrowlInstalled method. I'm
> > assuming the framework is provided by a dynamically linked library and
> > not statically linked by the app.
>
> The framework is generally bundled into the app by most developers; if you were to pop open an application bundle and go into 'Contents/Frameworks' you'd find a 'Growl.framework' rolled into the app itself.
>
That is good to know. The reason I didn't try running that is the
description on the download page states it "checks for growl support
in applications". If the description indicated that it also fixes
apps to be compat with Growl 1.3 I would have used it by now.
Travis Tilley
Will Fiveash
On Nov 8, 3:57 pm, Will Fiveash <will.five...@gmail.com> wrote:
> On Nov 8, 3:45 pm, Rachel Blackman <ceruleanspa...@gmail.com> wrote:
mically linked library and
> > > not statically linked by the app.
>
> > The framework is generally bundled into the app by most developers; if you were to pop open an application bundle and go into 'Contents/Frameworks' you'd find a 'Growl.framework' rolled into the app itself.
>
> That is good to know. The reason I didn't try running that is the
> description on the download page states it "checks for growl support
> in applications". If the description indicated that it also fixes
> apps to be compat with Growl 1.3 I would have used it by now.
Notifier plugin however looking at this app and what you wrote about
frameworks I did the following which allows the Google+Growl plugin to
work so that Google Notifier is now compat with Growl 1.3:
1. quit the Google Notifier app
2. download and extract GrowlVersionDetective.app
3. in a terminal window cd into the path where the app above was
extracted which for me was /Users/willf/Downloads/Growl Version
Detective.app/Contents/Frameworks/Growl.framework/Versions/A
4. cp Growl /tmp/Growl-WithInstaller
5. cd /Users/willf/Library/Application Support/Google Notifier/
GoogleGrowl.plugin/Contents/Frameworks/Growl-WithInstaller.framework/
Versions/A
6. cp Growl\-WithInstaller Growl\-WithInstaller.orig
7. cp /tmp/Growl-WithInstaller .
8. start Google Notifier
GN with the G+G plugin appears to work fine with Growl 1.3 now.
Will Fiveash
On Nov 8, 4:16 pm, Travis Tilley <ttil...@gmail.com> wrote:
> A number of applications (including last.fm for example) didn't use the
> public API to check whether or not growl was running or installed. Many of
> them implemented their own checks in a variety of ways... from checking
> file locations to seeing if there's a process with the name
> 'GrowlHelperApp' (which is now just 'Growl' due to the change to being an
> app). The latter is unexpectedly common (I believe super duper is/was doing
> something similar?).
making a mistake that is likely to hurt their customers in the long
run.
> To complicate matters further, there was at one time a bundle framework
> that included an installer to auto-install growl if it was missing. Due to
> abuse and complaint, this version of the framework was abandoned. There is
> no recent framework+installer, and simply dropping the standard growl
> framework in its place will not work.
other recent post for details. Beyond this, dropping the framework
+installer and not providing an automatic upgrade path to people that
install Growl 1.3 for older apps that are using the framework
+installer legitimately (i.e. calling the public APIs) is on the Growl
developers.
Travis Tilley
Will Fiveash
On Nov 8, 4:50 pm, Travis Tilley <ttil...@gmail.com> wrote:
> I'd like to caution that crashes are a certainty if anything specific to
> Growl-WithInstaller is used. This is why GVD doesn't just swap it out like
> it does other versions of the growl framework.
methods/funtions stubs that just return a success return code? This
would be preferable to having older apps not work with growl at all.
>
> hey... if it works it works. I'm not going to argue with that. ;)
> It'd be mean spirited not to give you a heads up though.
core dumps.