We should update our dmg to include an Applications alias like many other apps have done and has now become semi standard. I know there was some argument over this in the past, but more and more those arguments don't seem as strong (I was one of the ones arguing against it previously). We should also update the image and potentially the dmg icon.
I am still opposed to this idiocy.
There's no real guarantee that users understand that system at all either. A far better solution (IMO) that's started to make the rounds is a dialog at startup that says, bascially: You're running from a disk image. [Yeah, I know] [D'oh! I can has copy in Applicationz and relaunch] That way the sum total of the solution for users who don't understand disk images is to press the default button. We can conditionalize this code on the presence of CAMINO_PROFILE_DIR, so that portable Camino and testing from disk images are not affected.
Created attachment 287906 [details] Camino.pkg Oh! That gives me an idea - there's something I've been wanting to try. Drop this 108kB .pkg into a folder adjacent to Camino.app (1.5.3) and double-click it. Observe. Here's an option: we ship Camino.pkg in the disk image, and if Camino sees Camino.pkg next to itself when it launches, we can toss up Stuart's "I can has copy in Applicationz and relaunch" dialog. If the user clicks Stuart's button by the same name, we'll call out to the installer.
I'm pretty sure there's open-source code for handling this (without having to ship a package)
The idea behind the package is that it's familiar and we can stick it right in the dimmidge next to Camino.app. People will recognize and double-click it. Two or three enterprise sysadmins will probably like it because it eases deployment on managed networks (although they'll only see it this way if they come from the Windows world and they liken Apple.pkg to Windows.msi).
adn 1t letz u use r3p@1r p3rM|$5io|\|s 2 b00st p3rf~~!!!!!!!!!!!!!11111111111oneone111111eleven1
I'm concerned that moderately clueful users won't know whether to use the .app or the .pkg (and that we'll get hate because if we "need" a package then we must not be a good Mac app).
Right, I thought we were going to do bug 355884 instead.
My idea was that we could do both - the 355884-style dialog would launch the installer. But that's OK, if everyone hates the .pkg, I don't mind. I was mostly interested in seeing whether a .pkg could install some set of files that live outside the .pkg instead of reading from Archive.pax.gz. It can, so I'm satisfied.
Okay okay. No Applications alias. But can I at least update the graphics? :) (One question: Since we don't use the graphics in the l10n version of Camino, why have we been afraid of putting text in them?)
We haven't been. Firefox has. I have no problem with changing the graphics.
We do want to, at some point.
Anyone have any thoughts on this? Are we doing a better dmg, or are we doing some kind of installer junk, or both?
Retitling to make it clear what this is currently about (as I understand it from the recent comments). -'ing for 1.6; if we get new graphics, we can use them, but it's by no means a blocker.
Is the consensus still to not have an Applications alias? I don't think it would be confusing if you design it right. Please no .pkg.
The consensus is comment 8.
Why opt for user error correction rather than prevention? Even BBEdit (the example that Wevah gives in bug 355884) has updated their disk image to include an Applications alias.
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]