3 ms·

Now, you have version 1.0 of Cool.app, and version 2.0 Cool.app. 2.0 removes some files from the distribution, and adds some new. Cool.app is a bundle, i.e. fol

by dchest 17y ago

Now, you have version 1.0 of Cool.app, and version 2.0 Cool.app. 2.0 removes some files from the distribution, and adds some new. Cool.app is a bundle, i.e. folder that looks like file in Finder. Obviously, you want to replace the application completely instead of merging. What would you do?

ComputerGuru 17y ago
Packages are treated as individual files everywhere in the Finder UI, this wouldn't be an exception.
- dchest 17y ago
  Right. But now we have another problem. Our Cool.app stores user documents in packages. We have "Work.cool", which is treated like a package in Finder. Now we send this document to a person who doesn't have Cool.app installed. Then we send him another version of this document. How would merge/replace work for him? Since he doesn't have Cool.app, ".cool" folders are not registered as packages, they look like folders to him. I see one solution to this problem: let user decide what to do. Apple could add "Merge" button (or maybe a better title meaning "Replace files inside the destination folder with files in source folder") in addition to "Replace" in "what do you want to do" dialog. (Note that you can't simply name this thing replacing as in Windows, because it's really merging). This would also require some kind of comparison dialog to ask users what files to overwrite. I think Apple just went with a simplest solution here instead of introducing the whole new concept of merging and new UI to users to potentially create a confusion ("hm... what should I do - what's Merge and what's Replace?"). I'm not sure if it's good or bad, but I personally never miss Windows-like merging mistakenly called replace. The better thing to fix (unrelated to merging), I think is to put the replaced folder to trash instead of overwriting it, to allow users to undo their action (see http://daringfireball.net/2003/03/i_love_it_because_its_trash http://daringfireball.net/2003/03/i_love_it_because_its_tras...). However, this creates a confusion again ("what's this thing doing in my trash, I didn't delete it")... UI is hard.
- ComputerGuru 17y ago
  @dchest: Technically, these files belong in the user-specific ~/ directory and not the package itself, according to the ADC specifications, if I'm not mistaken.
  - dchest 17y ago
    By removing some files from distribution I mean, for example, getting rid of some resources, like nibs or images, etc.
    - ComputerGuru 17y ago
      I guess the simplest solution would be to use metadata to identify a package as being a package and not a folder? That way it wouldn't matter what software was installed, etc?

by dchest 17y ago

ComputerGuru 17y ago

Packages are treated as individual files everywhere in the Finder UI, this wouldn't be an exception.

dchest 17y ago
Right. But now we have another problem. Our Cool.app stores user documents in packages. We have "Work.cool", which is treated like a package in Finder. Now we send this document to a person who doesn't have Cool.app installed. Then we send him another version of this document. How would merge/replace work for him? Since he doesn't have Cool.app, ".cool" folders are not registered as packages, they look like folders to him. I see one solution to this problem: let user decide what to do. Apple could add "Merge" button (or maybe a better title meaning "Replace files inside the destination folder with files in source folder") in addition to "Replace" in "what do you want to do" dialog. (Note that you can't simply name this thing replacing as in Windows, because it's really merging). This would also require some kind of comparison dialog to ask users what files to overwrite. I think Apple just went with a simplest solution here instead of introducing the whole new concept of merging and new UI to users to potentially create a confusion ("hm... what should I do - what's Merge and what's Replace?"). I'm not sure if it's good or bad, but I personally never miss Windows-like merging mistakenly called replace. The better thing to fix (unrelated to merging), I think is to put the replaced folder to trash instead of overwriting it, to allow users to undo their action (see http://daringfireball.net/2003/03/i_love_it_because_its_trash http://daringfireball.net/2003/03/i_love_it_because_its_tras...). However, this creates a confusion again ("what's this thing doing in my trash, I didn't delete it")... UI is hard.
ComputerGuru 17y ago
@dchest: Technically, these files belong in the user-specific ~/ directory and not the package itself, according to the ADC specifications, if I'm not mistaken.
- dchest 17y ago
  By removing some files from distribution I mean, for example, getting rid of some resources, like nibs or images, etc.
  - ComputerGuru 17y ago
    I guess the simplest solution would be to use metadata to identify a package as being a package and not a folder? That way it wouldn't matter what software was installed, etc?