Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'The author responds' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
The author responds
Authored by: noworryz on Mar 08, '03 11:42:23AM

The article author responds to your comments:

Thank you for all your kind comments!

Several people have suggested getting rid of .DS_Store files or using Path Finder, which avoids them. What this idea implies is eliminating a key Finder feature: the ability to shuffle icons within a folder the same way you shuffle sheets of paper on a desk. It's the heart of the desktop metaphor.

Not everyone uses this feature. Unix users probably only use list view. Windows users probably have been mind-raped too many times to care. However, many Mac users, especially those in the graphic arts industry, are passionate about how they organize their icons. They shuffle icons to provide information about workflow, or file importance, or to make an artistic arrangement. They would crucify Apple if the feature were removed.

So Apple really didn't have a choice whether or not to save the location of each icon. The only question is how best to do it in the the new, multi-user world of OS X. Let's look at a few possibilities:

  1. Use the same concept as OS 9, without thinking through the implications of multiple users or permissions. This is the method Apple chose.
  2. Do it as above but fix the permissions issues. This is what I suggested -- minimal changes to make it bearable.
  3. Create a separate state file for each user in each directory. This is a possibility but, whoa, that's a lot of files, especially on remote file servers.
  4. Use a big database in the user's Home directory tree, which saves the state of wherever they've been. This might work, but what do you do about removable media? What happens when a CD is inserted?

As you can see, every method is a compromise. Apple made a decision to go with the .DS_Store files, probably for historical reasons. Their implementation leaves something to be desired, as many of you have stated. I hope they spend more time thinking about the issues to make it easier for the users.

[
Reply to This | # ]

split the difference
Authored by: sevenoftoine on Mar 08, '03 03:32:31PM

If you have read-only media, you could have a .DS_Store there to represent a view of the contents, and then keep a modified version of the same under your home directory. That way, you keep the integrity of the presentation as defined by the creator of the files, but if you go ahead and move them around, your homedir version now overrides the original.

-- Antoine Durr



[ Reply to This | # ]
Another solution
Authored by: mj on Mar 08, '03 05:52:04PM

What seems like a good solution to me is to do something similiar to the .DS_Store files, but much more cleanly. Let all view information be stored in a .DS_Store file that is located in the highest directory in which you have write access, or if you have a home directory on the disk, to somewhere in your prefs folder. Then when a directory or file is copied to another disk, that information can be merged rather easily into the appropriate .DS_Store on the other disk. To find the view info, just traverse the directory tree to the root and use the first .DS_Store relevant.

Something else that could be done instead of/in addition to this is to store info for other disks in your home prefs folder, and have this info perged every so often, though for disks that you really do use more than once, just rarely, this would have an unsettling effect, but in this case, the .DS_Store files idea I mentioned above would kick in.



[ Reply to This | # ]
Another solution
Authored by: punkmanandy on Mar 09, '03 03:59:12PM

what happens if it is a shared volume that can be accessed at several different points in the directory hierarchy, ie a users home folder?



[ Reply to This | # ]
Another solution
Authored by: GaelicWizard on Mar 09, '03 06:47:25PM

This all depends on the user using Finder. Most (not all) of the Finder-set settings in the .DS_Store files are retained whether I move the folder in Path Finder or in the terminal. But if there is no *real* file in a folder, then unless i use the finder to move it ALL my settings are lost for that folder.

---

Pell



[ Reply to This | # ]
Interesting ideas, people...
Authored by: noworryz on Mar 09, '03 03:20:23PM

You two have suggested interesting concepts:

  1. Use a database in each user's home directory that overrides .DS_Store files.
  2. Compress .DS_Store files to the top level on each volume.

The big issue, though, is how to let the user understand and control whether or not the .DS_Store file (or files) gets written to a removable volume, especially when the permissions do not allow it.

Perhaps when the user ejects a removable volume, the Finder could ask "Do you want to make the folder view changes you made to YOURVOL the default for all users?" It would then ask for the admin password if the permissions were wrong.

--Glenn

[ Reply to This | # ]