But to get back to the conversation that prompted this thought, the same thing could be done with a .dmg; instead of requesting to move itself when a program finds itself unzipped in ~/Downloads, a program could prompt to copy itself to the Applications folder and relaunch from there if it finds itself running from within its disk image. To imagine the dialog, the buttons would be "Copy" (default), "Copy, then Eject and Trash this Image" (for convenience), and "Run from Here" (or perhaps not—there's no really good reason to include it.) You don't have to include the decision between "Copy and Run" or "Just Copy" because the program is already "running" (from the user's perspective); they double-clicked it, didn't they?
But because they see the program as "running" from inside the image, they might try to launch the program again from within the .dmg after it had already been copied (if they didn't choose the Trash Image option.) Thus, the program should probably check for a copy of itself in /Applications and exec(3) it if it exists and is the same version, to avoid the lag of re-installing on every start. Though, since you want to kindly escort the users away from the .dmg, it might be better to present another dialog with the options "Run from /Applications" and "Copy Again" (to overwrite the old app—in case of a bad install or somesuch), giving them a small speedbump and a hint about where to find their app. The we-already-did-this dialog could even offer to automatically add an alias of the app to the Desktop or the Dock, "so you won't have to see this again."
no they aren't. self extracting DMGs are the recommended (by Apple, I believe) installation method. Open DMG > Application auto extracts to desktop > when first opened asks if you want it moved to Application folder.
why not move itself to Applications folder? You'd probably not find it without looking for it. The desktop is nice and visible.
I'd rather get a .dmg than a .zip with an executable in it.
most of the good ones have a "drag to applications folder" shortcut inside of them inside anyways so I don't see the problem with that particular convention.
You are used to it. So am I. If you use a stupid design often enough you become immune to its failings. The concept of disk images is needlessly complex, confusing and way too abstract.
You download a file that is a image of a disk, you have to mount that file, you have to drag the contained app to wherever you put your apps and then unmount the disk image. Can’t you see the craziness of this approach?
On a Mac your app is a single file (it isn’t, but behaves that way) you can drag anywhere and if you don’t like it anymore you trash it. Delivering your app with a .dmg breaks this simple model. Suddenly this app you see sitting there must be first dragged somewhere before you can use it (and you don‘t even get a warning if you don’t). And you have to handle a completely virtual disk image as if it were some real disk. Crazy.
So why did .dmgs become the preferred method of delivery in the first place? I'm assuming it has something to do with the fact that there's an HFS filesystem inside, so metadata/resource forks/whatever are transparently retained? Or is it just because you can run programs from within it without extracting them (which is quite useful when you have, say, the 1GB XCode .pkg)?
I guess it would be best if you could just download the app. But, since it’s a directory (bundle), that’s not practical.
Zip, however, seems to become a sort of standard wrapper for those kinds of bundles. iWork’09 files are just zipped bundles so that you can easily send them via email and nothing breaks if you do.
In this case, he's emulating the effect of an exception in a language which doesn't support them particularly well[1]: logging the exception message and then moving to a "rescue" or "catch" block which does necessary cleanup.
This is one of the few uses of goto which I find acceptable, and it's only necessary because these languages lack exceptions. Using goto for normal control flow, or even complex error handling, can be quite the nightmare. Particularly bi-directional gotos.
Given the situation though, that it seems he's avoiding exceptions out of habit or performance concern, I'd still use an exception in this case, rather than the goto, to protect myself from probable misuse and unpredictability.
Don't see whey we can't write a project that solves this problem on a general level with a similar method. When a .app appears in specified folders ask to move it to an applications folder. Watched folders default to ~/Desktop and ~/Downloads and the app folder defaults to /Applications.
Objective C or regular c gotos represent logic jumps which are hard to track by tools and humans.Debugging is difficult when code conditionally jumps around blocks instead of following a flow pattern easily discenible by reading the code. If good code is poetry code that uses gotos are google translations of poetry :-).Technically sound , emotionally funny
But because they see the program as "running" from inside the image, they might try to launch the program again from within the .dmg after it had already been copied (if they didn't choose the Trash Image option.) Thus, the program should probably check for a copy of itself in /Applications and exec(3) it if it exists and is the same version, to avoid the lag of re-installing on every start. Though, since you want to kindly escort the users away from the .dmg, it might be better to present another dialog with the options "Run from /Applications" and "Copy Again" (to overwrite the old app—in case of a bad install or somesuch), giving them a small speedbump and a hint about where to find their app. The we-already-did-this dialog could even offer to automatically add an alias of the app to the Desktop or the Dock, "so you won't have to see this again."