User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 The Mac OSX installer can be dramatically improved by creating a symbolic link on the disk image to the Applications folder; creating an Arrow icon and simple instructional tex, "To install Firefox/Thunderbird drag its icon to the Applications Folder." Here's a review of the installer in Tidbits, a popular weekly 'zine http://www.tidbits.com/tb-issues/TidBITS-809.html#lnk1 "Ironically after my article about simplifying installation in TidBITS-807, the Firefox disk image provides only graphical instruction that's actively confusing. An arrow leads from the Firefox icon itself to a smaller, greyed-out version of the Firefox icon that is presumably being dragged, to judge from the non-Mac-like pointer and + badge, and then to a greyed-out icon that looks like the Applications folder. Unfortunately, it's all representational - the Applications folder is just a picture, and not a symbolic link, and there are no textual instructions to clarify what to do. I've already heard of people not realizing they had to copy the Firefox package and instead running it from the disk image. Worse, the instructions on the Firefox Web site say "double click the Firefox Disk Image to open it in Finder, and then drag the Firefox application onto your hard disk. Drag the icon to your Dock if you want it to appear there." I'm sure there are people who will promptly drag the Firefox icon from the disk image to the Dock, instead of copying it to the Applications folder and then dragging the copied version's icon to the Dock. Obviously, there's nothing all that hard here, but that's no reason not to make it easier yet." Reproducible: Always Steps to Reproduce: 1. Create a symbolic link to the Applications folder. In the terminal type: ln -s /Applications ~/Desktop Move this link to the disk image. http://www.macdevcenter.com/pub/a/mac/2005/09/02/easy-access-to-application-folder-from-a-disk.html has a great description and screenshots

See bug 283598 comment 47 (and following comments).

That won't work on a localised version of the OS.

Yes, this is a WONTFIX per bug 283598 comment 47,

*** Bug 337539 has been marked as a duplicate of this bug. ***

*** Bug 333350 has been marked as a duplicate of this bug. ***

Oops, I *thought* I remembered talking about this before. Sorry about the dupe. But do see attachment 221644 [details] [diff] [review] for evidence of other applications using this system. I also note that bug 283598 comment 47 came with its own workaround. I think this is worth re-investigating, and would be a significant user experience gain. As an alternative, we might just consider abandoning DMG and going to .pkg installers, but that might kill poor Rob Strong. :) ss: would you mind re-opening?

(In reply to comment #6) > But do see attachment 221644 [details] [diff] [review] [edit] for evidence of other applications using check that. attachment 221664 [details]. I'm gonna stop writing bugmail this late. :(

Reopening: the l10n impact mattered in bug 283598 because we were past a l10n freeze, not because we couldn't ever do it.

I'm still strongly in the WONTFIX camp for other reasons (beyond l10n impact). (Though reopening is definitely fine as we discuss this again.) TextWrangler is a much more "pro" app geared toward users who understand symlinks. (When was the last time a simple end user needed a more advanced text editor?) New users to Mac OS X which download Firefox because it's a brand name they recognize probably won't understand symlinks as well as the pro user does. I don't think I've ever seen a symlink in a zip file (or something similar) on Windows which links to Program Files. Nor would one be welcome on that platform. I think OS X falls in this category as well. This confuses enough end users that it isn't desired behavior (in my opinion).

In contrast, having the user find the Applications folder is a major ask for the non-geek. I've watched my wife struggle through that more than once (if the app isn't on the Dock, it doesn't really exist for her. Agreed that only the true geek knows this is a symlink. But, the question is really, 'is the current method of installing easier or harder (and more or less confusing) than using the symlink approach. One Mac influencer thinks the current method is actively confusing.

(In reply to comment #9) > TextWrangler is a much more "pro" app geared toward users who understand > symlinks. (When was the last time a simple end user needed a more advanced The user doesn't need to understand the symlink. The user has to drag the application icon into their applications folder and then close the window. > recognize probably won't understand symlinks as well as the pro user does. I > don't think I've ever seen a symlink in a zip file (or something similar) on > Windows which links to Program Files. Nor would one be welcome on that Of course not. Windows has an installer which actually installs the application (which isn't bundled as a nice .app package) into the Program Files directory. The DMG system for installing software kinda blows because it gives the user too much choice, and too little guidance. The user needs to open the Finder, and then drag the app from one window to another (at which point it doesn't actually move) and then remember to eject the disk. Ugh. Even Apple thinks this sucks, as evidenced by the fact that they use .PKG installers for all their own software. Easing that drag and drop operation is key.

(In reply to comment #11) > The user doesn't need to understand the symlink. The user has to drag the > application icon into their applications folder and then close the window. Of course they don't *need* to. But the issue is that it causes confusion for some users. The feedback that various other software vendors have received is crazy talk like "How did you access my hard drive? You can see all my apps! I didn't authorize that!"... But again, I'm talking about *very* basic end users, of which Firefox is targeting. I'd much rather see a reworking of the current dimmidge instructions to take away any confusion that currently exists.

ss and I chatted on IRC, where he told me more about how Camino looked into this, and how Adium already does this, and how Adium gets support calls because sometimes, etc, etc. What it comes down to is a horrible interplay of user expectations. New Mac users will be confused by DMG installers. Existing Mac users will have been trained to expect DMG installers to behave a certain way. ss says that Pro Mac users will use Camino, but I think that was just a jab ;) -- either way, they'll be able to figure it out. The real goal here is to make it easy and clear what a user has to do in order to install our product on their system. The problem with the current DMG installer is that we have no idea *where* the Applications folder is. This proposal is about putting a symlink to that folder right in the DMG, thus knowing how to get to the applications folder. But, this carries the problem that the user might wonder what the heck their applications folder is doing in our DMG. So, perhaps a better solution would be to open the DMG with the full Finder UI including the sidebar. That way we'll know that the Applications folder will be on the left hand side. Then, we can use graphics like the ones we currently have to instruct the user to drag the icon into the Applications folder that's right over "<---" there. Novice users get instruction, existing users get familiarity, and power users use lynx in a terminal. Everyone's happy.

Probably a dumb question, but is there such a thing as a write-only symlink (or a way to acheive this through permissions)? If there is, users couldn't open the alias to see their all their apps 'included.'

Quicksilver automatically detects the DMG location and copies itself to the right location? Any reason we shouldn't do that?

Comment on attachment 222190 [details] Auto-detect! This, in combination with comment 13, is definitely the way to go. Anyone wanna figure out how they did this?

*** Bug 341569 has been marked as a duplicate of this bug. ***

If you want to revisit the symlink idea in light of the fact that other apps now use it, that's fine. I was initially opposed to it because I feared users would find an applications folder in the disk image and exclaim, "I downloaded my hard drive?!" Even those who aren't so distrustful but do understand the folder-file hierarchy model might be confused by finding their apps folder seemingly inside the disk image. A secondary concern is localization of the applications folder name. But if you want to talk about that from a usability perspective, I'm open to revisiting the issue. Preventing us from running out of the dmg is absolutely a horrible idea.

Mark, I'm interested as to why you think it's a horrible idea. I was under the impression that users were never meant to run the application from the DMG, but would be willing to hear alternative perspectives. (I have also been told that OS X will happily localize the display of the "Applications" text even though the folder itself is always called "/Applications" on the actual disk.)

We do support running FF1.5+ directly from a readonly mount such as a DMG or CD.

> (I have also been told that OS X will happily localize the display of > the "Applications" text even though the folder itself is always > called "/Applications" on the actual disk.) That's true - as long as the directory to be localized is named "Applications" and contains a file called ".localized." We can't take advantage of that, because our "Applications" entry needs to be a symbolic link. It's not enough that it's a symbolic link that points to the real /Applications (which does contain a .localized file), the system won't present a localized name unless the entry itself is a directory. Apple provides another way to provide custom localized display names for any directory, but doesn't offer any options to localize display names for files or symbolic links. Darn. http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/DisplayNames.html If we wanted to do the symbolic link thing, we'd need to do one of two things: - (Easy) Give the link an empty name, like " " - (Hard) Build each locale's disk image with the proper localized name for the Applications folder. This is feasible for Firefox because it ships as a different download for each locale, and doesn't really rely on OS X's support for multiple locales in a single package. Shipping a symbolic link named "Applications" in non-en disk images has nonzero evilness.

We either want to do something like Quicksilver does (comment 15) or the localized symlink (comment 21). But we *do* want to do something like this for Firefox 3.

I have attached a patch which adds --symlink option to mozilla/build/package/mac_osx/pkg-dmg The idea is that you add the argument "--symlink /Applications" and then there is a symlink on the disk image to folder on the local disk. Don't know if this will be the final direction for firefox, but here is the patch to make it an option.

Comment on attachment 242881 [details] [diff] [review] This is a patch to mozilla/build/package/mac_osx/pkg-dmg to support adding a symlink to the .dmg Index: pkg-dmg =================================================================== --- pkg-dmg (revision 7526) +++ pkg-dmg (working copy) @@ -62,6 +62,7 @@ [B<--sourcefile>] [B<--verbosity> I<level>] [B<--dry-run>] +[B<--symlink > I<absolute-filename> =head1 DESCRIPTION @@ -191,6 +192,13 @@ actually executing them. When commands depend on the output of previous commands, dummy values are displayed. +=item B<--symlink> + +When this option is present, a symbolic link is placed at the top +level of the disk image refering to the I<absolute-filename> +specified after the command. This is to be used for creating a +link to the /Applications folder as an example. + =back =head1 NON-OPTIONS @@ -404,7 +412,7 @@ } # Non-global variables used in Getopt -my(@attributes, @copyFiles, $iconFile, $idme, $licenseFile, @makeDirs, +my(@attributes, @copyFiles, $iconFile, $symlinkFile, $idme, $licenseFile, @makeDirs, $outputFormat, @resourceFiles, $sourceFile, $sourceFolder, $targetImage, $tempDir, $volumeName); @@ -441,6 +449,7 @@ 'sourcefile' => \$sourceFile, 'verbosity=i' => \$gVerbosity, 'dry-run' => \$gDryRun, + 'symlink=s' => \$symlinkFile, 'config=s' => \%gConfig); # "hidden" option not in usage() if(@ARGV) { @@ -611,6 +620,12 @@ } } +if(defined($symlinkFile)) { + if((symlink($symlinkFile,$tempRoot.'/'.simple_basename($symlinkFile))) != 1) { + cleanupDie('symlink creation failed'); + } +} + if(command($gConfig{'cmd_chmod'}, '-R', 'a+rX,a-st,u+w,go-w', $tempRoot) != 0) { cleanupDie('chmod failed'); @@ -1426,6 +1441,12 @@ cleanupDie('exiting on SIG'.$signalName); } +sub simple_basename { + my $name = shift @_ ; + $name =~ s/^.*\/// ; + return $name ; +} + sub usage() { print STDERR ( "usage: pkg-dmg --source <source-folder>\n". @@ -1441,6 +1462,7 @@ " [--attribute <a>:<file>] (set file attributes)\n". " [--idme] (make an Internet-enabled image)\n". " [--sourcefile] (treat --source as a file)\n". +" [--symlink <file>] (a file to link to)\n". " [--verbosity <level>] (0, 1, 2; default=2)\n". " [--dry-run] (print what would be done)\n"); return; Index: pkg-dmg =================================================================== --- pkg-dmg (revision 7526) +++ pkg-dmg (working copy) @@ -62,6 +62,7 @@ [B<--sourcefile>] [B<--verbosity> I<level>] [B<--dry-run>] +[B<--symlink > I<absolute-filename> =head1 DESCRIPTION @@ -191,6 +192,13 @@ actually executing them. When commands depend on the output of previous commands, dummy values are displayed. +=item B<--symlink> + +When this option is present, a symbolic link is placed at the top +level of the disk image refering to the I<absolute-filename> +specified after the command. This is to be used for creating a +link to the /Applications folder as an example. + =back =head1 NON-OPTIONS @@ -404,7 +412,7 @@ } # Non-global variables used in Getopt -my(@attributes, @copyFiles, $iconFile, $idme, $licenseFile, @makeDirs, +my(@attributes, @copyFiles, $iconFile, $symlinkFile, $idme, $licenseFile, @makeDirs, $outputFormat, @resourceFiles, $sourceFile, $sourceFolder, $targetImage, $tempDir, $volumeName); @@ -441,6 +449,7 @@ 'sourcefile' => \$sourceFile, 'verbosity=i' => \$gVerbosity, 'dry-run' => \$gDryRun, + 'symlink=s' => \$symlinkFile, 'config=s' => \%gConfig); # "hidden" option not in usage() if(@ARGV) { @@ -611,6 +620,12 @@ } } +if(defined($symlinkFile)) { + if((symlink($symlinkFile,$tempRoot.'/'.simple_basename($symlinkFile))) != 1) { + cleanupDie('symlink creation failed'); + } +} + if(command($gConfig{'cmd_chmod'}, '-R', 'a+rX,a-st,u+w,go-w', $tempRoot) != 0) { cleanupDie('chmod failed'); @@ -1426,6 +1441,12 @@ cleanupDie('exiting on SIG'.$signalName); } +sub simple_basename { + my $name = shift @_ ; + $name =~ s/^.*\/// ; + return $name ; +} + sub usage() { print STDERR ( "usage: pkg-dmg --source <source-folder>\n". @@ -1441,6 +1462,7 @@ " [--attribute <a>:<file>] (set file attributes)\n". " [--idme] (make an Internet-enabled image)\n". " [--sourcefile] (treat --source as a file)\n". +" [--symlink <file>] (a file to link to)\n". " [--verbosity <level>] (0, 1, 2; default=2)\n". " [--dry-run] (print what would be done)\n"); return;

Sorry for the bugspam but I wish to report that we're seeing a high number of Mac installation problems on the MozillaZine forums. The problem is common enough to have warranted creation of these two "support images" http://img354.imageshack.us/img354/535/installingfirefoxtd6.jpg http://img89.imageshack.us/img89/2628/macdmgvl1.jpg and obviously a KB article http://kb.mozillazine.org/Installing_Firefox#Mac_OS_X I don't understand the issue but it's a high profile problem at the moment. Recent (withing a month) threads displaying the problem: http://forums.mozillazine.org/viewtopic.php?t=495606 http://forums.mozillazine.org/viewtopic.php?t=494298 http://forums.mozillazine.org/viewtopic.php?t=494131 http://forums.mozillazine.org/viewtopic.php?t=484168 http://forums.mozillazine.org/viewtopic.php?t=486922 http://forums.mozillazine.org/viewtopic.php?t=485543 http://forums.mozillazine.org/viewtopic.php?t=484475 etc etc ps. there also is a related bug entry 254234

I'm becoming more an more convinced, FWIW, that we want to ship Firefox 3 in a .zip. More and more Mac apps are being shipped that way, it's easier for the user and fixes the problem of people always running Firefox from the DMG. Although I will be interested to see if Apple addresses this issue at all in 10.5, since there have been endless flamewars on various lists about this very issue.

How do we display a license if Firefox ships in a zip?

Why exactly do we need to display a license? Could this be built into Firefox instead? Alternatively, we could use an "internet-enabled disk image," the upshot of which is that we end up with Firefox.app sitting on the user's desktop. I'm not a big fan of them, but if showing a license is absolutely required (how do we do this on Windows and Linux?), perhaps that's the way to go then.

I'm no lawyer, but I thought we did have to display. It could definitely be built-in to Firefox, but that seems like a pain and a lot of work (which probably has to be done before beta 1 if there are string changes, no?). I know Windows uses an installer. Not sure what Linux does as I've really only dealt with nightlies on that platform. Presumably, most Linux users get Firefox from their distro and our license is part of that or is covered in the distro's license.

(In reply to comment #31) > I'm no lawyer, but I thought we did have to display. See bug 302080.

So, why don't we just have the symlink as a folder with the name " "? No localization, no mess. Try this in you home directory: ln -s /Applications " " Notice how the OS assigns the symlink the correct icon automatically (which users see in the sidebar all the time). In fact this is the way our dmg looks now. Only thing different would be that they would actually do the drag in the direction the arrow is pointing, to the thing the arrow points at. ;)

Yup, I suggested that a year ago (comment 21).

(In reply to comment #34) > Yup, I suggested that a year ago (comment 21). Let's do it then -- what build system changes are going to be needed? It looks like that script does part of what we want, what about the packaging? We're going to want to move the icon to the right spot (Adium uses some nasty Applescript to do that, I'm assuming we do something similar).

The build system change will be a patch to pkg-dmg. I don't really like the patch here, --symlink should work just like --copy does, supporting multiple symlinks and different names for the link and its target. The patch here won't let us name the link " ". We'll also some packager magic to pass the option in. We'll also need new .DS_Store files and possibly a new disk image background. I generate those by hand, sort of. For this change, I should be able to add icon positioning information by hand-tuning the .DS_Store. We don't create .DS_Store files for icon positioning and other window settings dynamically at build time - you call your script to do that nasty, and ours would be nasty too. Actually, it would be damn fragile.

Yeah, the Adium script is quite fragile. "Hand making" a .DS_Store should be alright. What's the timeline on something like this, Mark? Anything I can do to help accelerate things?

moving out bugs that don't need to block b1

Mark, any updates? If you're going to work on this, btw, could you take it from me?

Sad to see this marked P5 :\ It's one of the major pain points on the Mac.

This is the installer, and it basically works fine now though of course we could make improvements like this. "major pain points" sounds a little dramatic to me...

I'd tend to agree more with Colin in comment 41 - I have seen numerous less-technical friends run FF from the dmg and wonder why they have so many issues around add-ons, caching and upgrades. They often abandon the browser based on this as they don't know what the issue is don't know how to fix it. I've seen these same users use applications that have an alias to the applications folder icon in the dmg window, and they don't seem to have an issue. Seems like a decent pain point - would really be great to see this in FF3 final.

I also have first hand accounts of people running Firefox from the DMG and being annoyed that they have to download it again every time they restart their computer (which they did for awhile, but ultimately switched to Safari since they have to open it to download Firefox each time anyway). What we need to remember is that for a lot of OS X users, Firefox is the only third party application they will every install, so it isn't surprising that they wouldn't know how to install something (I even found it a little confusing when I first switched to the mac).

Wow, I did not mean to cause so much discussion with my bug-report :) As I studied computer science, I of course know those issues. Whenever I use a Mac, I have to switch all my computer knowledge off to get things done. But you really get used to this easy-stuff... :) If you try out the symlink-solution, just drop me a line or send me a test-bulid. I'm happily willing to help you testing *smile* Just one question: Isnt the Applications-folder always in /Applications? I'm using the german version of MacOS X 10.5 - and all folders are in the root-dir and they are in *english* (when you use the terminal/xterm to look at you hd). So I really like the idea of the " "-symlink to /Applications... Greetings from Austria, Gery

This patch adds a --symlink parameter to pkg-dmg (funnily I came up with the parameter name as Robin without this bug *g*), which allows adding symlinks by changing the parameter passed to rsync from --copy-unsafe-links to --links. Actually, this patch is a core patch and not Firefox-specific, we need this for .dmg work on SeaMonkey...

Comment on attachment 291091 [details] [diff] [review] --symlink for pkg-dmg as a variation on --copy This uses rsync --links, but what we really want is a way to make arbitrary symlinks in the dmg filesystem by calling symlink() without having to have some "source" symlink to copy over.

Use Perl's symlink() function instead of copying existing symlinks. Note that symlink() (like ln -s) does not create missing path hierarchies!

Comment on attachment 291294 [details] [diff] [review] --symlink for pkg-dmg as a variation on --copy, v2 >Index: build/package/mac_osx/pkg-dmg > pkg-dmg --source /Applications/DeerPark.app --target ~/DeerPark.dmg > --sourcefile --volname DeerPark --icon ~/DeerPark.icns > --mkdir /.background > --copy DeerParkBackground.png:/.background/background.png > --copy DeerParkDSStore:/.DS_Store >+ --symlink /Applications:Programme To make it clearer that the thing on the right side of the colon is the in-dmg target, and to make it clearer that you can supply an in-dmg path like the rest of the options do, the example should show: --symlink /Applications:"/Drag to here" >-my(@attributes, @copyFiles, $iconFile, $idme, $licenseFile, @makeDirs, >+my(@attributes, @copyFiles, @createSymlinks, $iconFile, $idme, $licenseFile, @makeDirs, Exceeds 80 characters. >+# copyFiles($method, @arguments) >+# >+# Copies files or create symlinks in the disk image. >+# See --copy and --symlink descriptions for details. >+# If $method is 'copy', @arguments are interpreted as source:target, if $method >+# is 'symlink', @arguments are interpreted as symlink:name. It's source:target either way. Maybe you want to call it symlink:target. I don't like "name" because both the referer and referent are names. You should also document that if :target is missing, source will be replicated (or linked) in the dmg at the same path as source. >+sub copyFiles($@) { [...] >+ $target = $tempRoot; This treats $tempRoot like a global. You can get away with this, but I think it's cleaner to pass it as an argument to this subroutine. There are only a few things treated as globals in this program, and they're declared way up at the top with "g" names. > " [--mkdir <directory>] (make directory in image)\n". > " [--copy <source>[:<dest>]] (extra files to add)\n". >+" [--symlink <source>[:<dest>]] (extra symlinks to add)\n". > " [--license <file>] (plain text license agreement)\n". > " [--resource <file>] (flat .r files to merge)\n". You should move all of the (parenthesized) descriptions over three spaces so that everything lines up again.

Comment on attachment 291294 [details] [diff] [review] --symlink for pkg-dmg as a variation on --copy, v2 >+ if($method eq 'symlink') { >+ $success = symlink($source, $target); Oh, hmm, another thing is that this doesn't take $gDryRun and $gVerbosity into account. I'd add an |elsif($command eq 'symlink')| branch to commandInternalVerbosity (next to 'unlink') that looks like this: elsif($command eq 'symlink') { if($verbosity || $gDryRun) { print(join(' ', 'ln', '-s', argumentEscape(@arguments))."\n"); } if($gDryRun) { return 1; } return symlink(@arguments); } And, from copyFiles, call it as: $success = commandInternal('symlink', $source, $target); Make sure the fake "ln -s" messages show up and disappear as expected at different --verbosity levels, and give it a spin with --dry-run.

>--symlink /Applications:"/Drag to here" Instead of naming the folder "Applications: drag to here" can we provide a background image with an arrow? I know a lot of mac applications do some really creative and elegant images in their DMG file. If you give me the specs of the file we need, I'm sure one of the graphic designers we are working with would be happy to make it. Also, do we get the "Applications" localization for free from OS X? If so, we may not want to add "drag to here" due to the l10n impact (in addition to sounding a little awkward).

> Instead of naming the folder "Applications: drag to here" My comment only applies to the documentation supplied with pkg-dmg showing an example use of the tool. It means that for the example usage supplied, pkg-dmg will create a symbolic link in the disk image named "Drag to here" which links to /Applications. It's just documentation, and it's got nothing to do with how the feature will actually be used. For Firefox, the name will be ' ', so as to not be displayed and therefore not have any localization impact. See supra.

Addressed all review comments. BTW: it's rather weird that command's and commandInternal's return values have exactly opposite meanings...

Comment on attachment 291736 [details] [diff] [review] --symlink for pkg-dmg as a variation on --copy, v3 [checked in] commandInternal is supposed to be a direct replacement for the Perl system call wrappers, which, unlike shell commands and C equivalent system calls, return true (instead of 0) to indicate success. That might be a better explanation for your (!) comment than just saying "that's how it is." commandInternal('unlink', ...) is suposed to be a drop-in for unlink(...) that handles $gVerbosity and $gDryRun.

Comment on attachment 291736 [details] [diff] [review] --symlink for pkg-dmg as a variation on --copy, v3 [checked in] I'll update that particular comment on checkin.

Comment on attachment 291736 [details] [diff] [review] --symlink for pkg-dmg as a variation on --copy, v3 [checked in] Since this is already blocking Firefox3 you don't need a+ - you can land when the tree is open.

Comment on attachment 291736 [details] [diff] [review] --symlink for pkg-dmg as a variation on --copy, v3 [checked in] Landed on trunk with Mark's explanatory comment. And I won't do the actual Firefox patch, though, since my "target" is bug 406448.

Mark, are you still able to do the Firefox-specific bits, or do we need an owner for that?

I can do the Firefox bits, but I don't really have the time or inclination to do the artwork. We need a new disk image background. See bug 406448 for a C-Monkey example. Attachment 291486 [details] is a placeholder image, although they're going to come up with a new image that doesn't have any English text in it (localization impact!) If someone can provide that, I'll do the packager stuff and a new dsstore file.

>but I don't really have the time or inclination to >do the artwork. We need a new disk image background. Taking, I'll discuss the design with the rest of the ux team and find someone to get the artwork done. How soon do you need the file?

I'll only need a couple of days once I've got the new background to finish this off - it's not really much work, but it's got to be tailored to the image. I guess this will be wanted for the next beta, so I guess the answer depends on the beta's timetable.

The freeze for the next beta will be mid to late January, I'll try to get you the disk image background well before then. Can we also provide a different dmg icon?

Sure. It's best if you can provide it in a few sizes: 512x512, 256x256, 128x128, 32x32, and 16x16. If you can get it into icns format (/Developer/Utilities/Icon Composer.app), that'd be good, otherwise, I can put them into that format. Newer OS releases use the larger sizes and they'll come in handy going forward for resolution independence, although I'd say they're not crucial for the disk image icon if it's difficult to get anything larger than the 128x128 size.

Not going to block on this, but really really really want. Alex, can you get the images done? Let's just get the minimum we need done here before b3, or this will, sadly, miss Fx3.

>Alex, can you get the images done? I'll see if the proto guys have any cycles, otherwise I may look into contracting this out to get something in time. If I get a background image and a DMG icon we will be able to land both, right?

No problem on my end.

Ok, I'll try to get you these files as soon as possible. What format should the DMG background image be in, and are there any particular size restrictions?

http://mxr.mozilla.org/mozilla/source/other-licenses/branding/firefox/background.png is the current background image used by Firefox, and see bug 406448 for the new background image SeaMonkey is going to be using with this patch.

Just so I am totally clear, can we set the size of the DMG window to whatever we want so that we display all of the background image we are having produced?

Alex: From what I understand, yes. We apparently can set the size of the DMG and the position of the icons on it. I heard it's some kind of HTML or such. We just should keep the size conveniently small but large enough to fit everything we need. We tried to keep the SeaMonkey image at a size approximately as big as the old Firefox one (415x315px).

Oh, and note that we shouldn't have any real text other than the brand name on it as we don't want to introduce a need to localize an image.

Alex, that's right, you can make the image any size you like. The existing image is 415x315, a size which was chosen to give 400x300 of free space for the visible image. Different OS versions treat the image in different ways, and so there wasn't any guarantee that the bottom-most 15px or right-most 15px would be visible - they may be obscured by the scrollbar. When you're coming up with your image, you should avoid putting anything important in these areas. I prefer and recommend PNG, but most common formats should work (JPEG, TIFF, and even GIF). I bet you could even supply vector art in a PDF. The current image is PNG.

(In reply to comment #65) > Not going to block on this, but really really really want. Alex, can you get > the images done? Let's just get the minimum we need done here before b3, or > this will, sadly, miss Fx3. To be clear, the minimum that can be done here is to use our existing artwork and just put the symlink to the Applications folder overtop of that part of the image; we've already got pictographs illustrating what it is that a user needs to do (drag the application into their applications folder) in that image. My preference would be to split more detailed artwork off into another bug, though I understand that causes some engineering effort headaches as it would mean whipping up the DMG stuff twice. Still, I'd rather see that than have this miss beta 3.

I have a strong preference for only having to generate an updated .DS_Store file once.

>I have a strong preference for only having to generate an updated .DS_Store >file once. Ok, how about you generate the file shortly before freeze, and if we have the artwork by then we will land it. Otherwise we'll go with the old one.

Just as a point of reference, here are some creative DMG background images: http://softwaretrenches.com/images/dmg_skype-1.png http://softwaretrenches.com/images/dmg_appzapper-1.png http://softwaretrenches.com/images/dmg_delicious_library.png http://softwaretrenches.com/images/dmg_democracy_player.png From http://softwaretrenches.com/2006/09/dmg_disk_image_is_the.html We are looking into raising the bar both in terms of creativity to give the install experience a uniquely OS X feel. Hopefully we'll have the artwork ready in time for the freeze.

Here is the new look for our dmg.

Here is the background image shown in the example.

Comment on attachment 299926 [details] The background image Mark: any chance that if I beg a lot we could get you to throw together the new DMG with symlinks by the end of today? Not a huge deal, just a nice to have for Beta 3 code freeze. :)

This zip file contains the replacement background.png (from attachment 299926 [details]) and a new .DS_Store file that adds icon placement for the symbolic link.

Comment on attachment 299925 [details] Example of the new dmg background artwork I would post an image of the updated dmg, but it looks exactly like this one.

Comment on attachment 300109 [details] Background image and .DS_Store a=beltzner

Comment on attachment 300110 [details] [diff] [review] Add symbolic link to disk image during packaging beltzner asked me to look at this because of the deadline. Works as expected :) r=ardissone

Comment on attachment 300110 [details] [diff] [review] Add symbolic link to disk image during packaging a (and yay!) = beltzner

Chicked en on the trunk.

This is verified on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3 for en-US, but broken for the locales. Bug 416055 tracks the issue and fix for the latter.

Anyone know how pc magazine could have ended up with this screenshot in their review of beta 4? http://www.pcmag.com/slideshow_viewer/0,1205,l=225313&s=1489&a=225317&po=7,00.asp?p=y

The beta 4 dmg looks fine on my machine, can anyone else reproduce?

That's to-the-pixel the layout you get from right-clicking the window background, choosing "Show View Options" and then "Arrange by: Kind" so I'd guess that's how, but offhand I don't see how to pass that down to the dimmage as a default (or why they would do it to just that window, and then screenshot it).

(In reply to comment #91) > That's to-the-pixel the layout you get from right-clicking the window > background, choosing "Show View Options" and then "Arrange by: Kind" so I'd > guess that's how, but offhand I don't see how to pass that down to the dimmage > as a default (or why they would do it to just that window, and then screenshot > it). The "Use as Defaults" button on 10.5, perhaps--except, like Phil, I can't make a "Use as Defaults" change affect the .dmg.