Growl 1.3 framework requirement

[Chris Forsythe]

FYI, we have found a problem which will likely affect any application which does not use the newer Growl frameworks. Applications will need to update to the 1.2.2 framework in order to work with Growl.

If the application you work on is using Growl.framework 1.2, or any version below that, then please update to Growl.framework 1.2.2 as soon as you can. There are no api changes, it should be a simple drop in replacement.

Chris

[Christopher Forsythe]

Also, to check the version of the framework that you ship, you can open the Info.plist that lives inside the bundle. This is under the Resources directory.

You will be looking for the CFBundleVersion key.

Chris

[Peter Hosey]

(sent to all three groups this time)

On Sep 15, 2011, at 22:49:16, Christopher Forsythe wrote:
> Also, to check the version of the framework that you ship, you can open the Info.plist that lives inside the bundle. This is under the Resources directory.
>
> You will be looking for the CFBundleVersion key.

An easy way, especially if you work on multiple applications and assuming you use all of them (or at least have builds lying around), is to use the Growl Version Detective:

http://growl.info/files/Growl_Version_Detective-1.0b1.zip

This will use Spotlight to find all installed applications that have Growl frameworks inside them, and shows what version each application bundle has.

[Richard L. Hamilton]

Question: what happens if a framework exists both within an app and in a usual system place (like /Library/Frameworks)?

I'm _guessing_ that if present in both, the one within the app bundle would be used.

But is there any way to reverse that?

The point being that Growl is optional on a system, so apps include their own copy of the framework. But if a compatible (but newer) version were in place at the system level, it would sure be nice if they could use that instead.

I imagine that even if possible, it would require re-linking, so that wouldn't do any good _now_. Maybe it might help in the future, though.

Just an odd thought…

[Chris Forsythe]

Growl .5 was distributed like that. The biggest problem was of course problems with weak linking.

To answer this specific question, I don't think you could easily work around this problem via that method. The much easier solution is to just drop the newer framework into the app which is not working, and to contact the applications developer.

Another thing to keep in mind is that if you are shipping in the app store, you need to strip via lipo the ppc portion of the binary. However, the 1.3 version of the framework will not support 10.5, so no ppc.

Chris

> --
> 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.
>

[Rudy Richter]

Just to be clear, if you're aware of an app developer that is
installing the Growl framework in /Library/Frameworks, grab a wooden
ruler and repeatedly whack them hard across the hands. The framework
does not belong anywhere other than inside the application bundle. In
fact, we will delist any application that does this from our app page.
Don't do it.

as for repairing a binary you can use otool -L to see what how the
various libraries are being linked and you can use install_name_tool
to change the linkage paths in a binary so that they point elsewhere.
you can read up on install_name_tool on its manpage.

we jettisoned the system installed version when it started causing
problems where app developers were assuming a certain version would be
installed only to find their application crash because someone else
had installed an older version in its place. It wasn't worth the
trouble. you ship your app with a known & tested configuration,
produces a much better user experience. Users don't belong in /Library
anyway. :P

-rudy