Laurence Harris wrote:
On 5/8/06 11:25 AM, B.J. Buchalter didst favor us with:
Ouch. This is a hack. I wouldn't do that as it creates a custom icon file in
the package that isn't deleted when you remove the custom icon.
One thing that seems to work most of the time for me is to do Get Info on
the app, click on the icon in the Get Info window, and then hit the "delete"
key. This seems to cause the finder to refresh it's idea of the
application's icon from the app itself (or something like that). Most of the
time it makes the correct icon appear.
Hmm. I'll try that next time.
FWIW, I think it's sad that we have to use any hacks at all to get the
Finder to show a correct icon. ;-)
To be fair, I think it's a good thing in general that the Finder caches
data, and I think Xcode could easily do what's necessary to convince
the Finder to refresh the data—such as sending sync events or bumping
the mod date on the app bundle. If we are going to be pointing fingers,
I think Xcode is the guilty party here. The Finder team has clearly
documented the necessary steps to get the Finder to refresh, and I
think it's clear that Xcode isn't following those steps. (FWIW,
CodeWarrior adid not follow these steps either... not that two wrongs
make a right.)
I've written an updater which upgrades app bundles from version A to
version B, and all I had to do was call utimes on the .app container to
bump its mod date once I was done modifying the bundle contents, and
the Finder has always done a perfect job of staying in sync and showing
the latest version number and icon for the app. Assuming you have a
path to the app bundle folder, it's one line of code—not rocket science.
Hmm, maybe I should put a radar in on this one.
|
