Re: Keeping a Folder's icon with packagemaker/installer
Re: Keeping a Folder's icon with packagemaker/installer
- Subject: Re: Keeping a Folder's icon with packagemaker/installer
- From: Russ <email@hidden>
- Date: Sun, 7 Dec 2008 12:39:44 -0800 (PST)
Unfortunately, adding the extra level of folder does not help. It looks like Installer.app just does not know how to turn back on the custom-icon attribute bit.
>From the SetFile man page, even though SetFile is in /usr/bin/SetFile, it is present only if developer tools are installed?
I guess none of this is necessary to run iTunes.
----- Original Message ----
Sent: Saturday, December 6, 2008 10:30:30 AM
Subject: Re: Keeping a Folder's icon with packagemaker/installer
On Dec 5, 2008, at 6:29 AM, Russ wrote:
> Battling packagemaker 3.0.1 (172)
>
> The contents I am installing is a folder into /Applications, my app bundle sits in that folder along with the help files. (I am simplifying to reduce techsupport volume). This setup is routine for 3rd party apps, so I am going with the flow.
>
> The problem at hand is that I have set up, using Finder, my icon on my top-level folder to make it easier to find in the Applications list. This results in an Icon? file being created in the folder. After digging around a while I've seen the actual required name is something like \pIcon\r and this file is size 0 with the icon in a resource fork! (I guess a plain hidden .folder.icn file would have been too easy?)
>
> It appears that packagemaker or installer choke on this file, it shows up at the installation, but without the resource fork, extended attributes, and possibly without the special-character name, and of course it does nothing.
>
> Is there a way to get the installed folder's icon set up right, either by installing the Icon? file correctly or some other (simple) method? Adobe CS3 and Snapz Pro X have got it working somehow. I'd just as soon NOT have to create some (Carbon AE) program to go do this programmatically as a post-installation hack. Thanks.
AFAIK:
If you set your payload root like this:
Payload > My Folder
and set the default destination to be '/Applications', you may face this issue. The fact is that SplitForks does not produce the same result twice in this case.
If you set your payload root to be like this:
Payload > Applications > My Folder
and set the default destination to be '/', this issue will not occur.
> PS: It is a known bug that Packagemaker likes to turn "Allow Relocation"
> back on by itself, right? Pretty sure that's what happens. And that if
> it is on, and the user has dragged the old version of your app to the
> trash, Installer will (re)install the new version into the trash can,
> right?
It is a known bug. Not sure if it also applies to the Trash can though.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden