Re: Tracking files the right way
Re: Tracking files the right way
- Subject: Re: Tracking files the right way
- From: Mike Shields <email@hidden>
- Date: Thu, 29 Aug 2002 19:22:40 -0600
Bill,
You see Apple has a whole section in Inside Mac which details exactly
how to track aliases for the proxy icon in the title bar - including
what to do when the user drags the file in the filesystem to the trash
- and it's all explained here:
<
http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/
WindowManager/ProgWMacOS8.5WindowMgr/WindowMgr.13.html>. This is all
something that can only be done with an alias. It's also a good
beginning way for an app to handle tracking files across launches. I
implemented this in PowerPlant and my app worked wonderfully for
keeping track of where the file lived in the filesystem. The only
argument I've heard for using paths over aliases is that someone wants
to be able to trick an app into creating a new file by moving the file
being edited from underneath the app. Lame reason IMHO.
The problem we have with aliases now is that it relies on path LAST. An
alias would work much better if it used the path first. This would
prevent the "drag an app/file/folder to the trash and watch the alias
gladly find it for you when there's a new one in the original place"
problem there is now.
Paths suck because they are so fragile that it's not funny. Change the
name of the file and BOOM, path is broken. Change the parent folder
name and BOOM, path is broken. This is problematic for files located in
the user's home dir, which is theirs to play with and manipulate as
they see fit. If iPhoto or iTunes used an alias for the location of
their libraries, we could actually move them around with impunity
without either app breaking. But since they have to do it themselves
(because everything MUST be a path) they do just enough and fix
problems as people complain.
It would make a lot of sense for there to be a system service to handle
tracking files instead of making developers do it themselves, over and
over again. Aliases used to provide this. Now it's up to developers to
all get the differences in file locating correct with all the oddities
that unix brings along such as symlinks, the location of a folder being
different on different machines, etc. Aliases could again provide this
service and provide the means for unix-heads to track things by path as
they're used to. I personally think that's a better way - and I'm NOT a
unix/NeXT guy.
And Bill, once again in Classic Mac OS, Apple wrote for you code to
handle atomic file saving (look in MoreFiles) and HFS+ even supports
that natively (FSpExchangeFiles). This is all something that we're
aware of and agree with.
On a side note: The biggest problem I've had with the transition to OS
X is that the new developer community springing up is throwing away a
ton of good ideas for behavior from the < OS 9 community. I really feel
that MacOS apps have in general been more intuitive and had better HI
that apps coming over from NeXT or other OSes. This is something that
people seem to ignore - my guess because it's not Cocoa. If people
would go back and look through the mounds of Apple technotes and Inside
Mac documentation, they can find lots of of sample code that
illustrates behavior that 1) old time Mac users expect and 2) is
generally just good HI.
Mike
PS: I wonder how well file tracking could be done in cocoa itself by
creating a class that's archivable that contains a path and alias,
thereby providing the behavior we want. Hmm... I might have to look
into this.
@interface NSFileRef : NSObject <NSCopying, NSCoding>
@end
Hmm...
On Thursday, August 29, 2002, at 03:47 PM, Bill Bumgarner wrote:
Yes -- you are absolutely correct, I screwed up my vocabulary and was,
in this context, using Alias and FSRef to mean Alias. Sorry about
that.
It doesn't change the original point: That using Aliases does not
necessarily yield an intuitive user experience without a bunch of
additional effort on the part of the developer. I have wasted many
hours talking my mom or sister through a problem related to an Alias
pointing to the wrong thing because it "behaved correctly".
Some examples (maybe these aren't directly Alias related, but these
all have to do correctly tracking file locations):
- iTunes effectively expands all paths contained in the music
database such that the stored path (alias? doesn't matter) does not
contain any symlinks or other abbreviated forms of paths (like, say,
~bbum/ instead of /private/automount/foo/dog/Users/bbum). As a
result, iTunes breaks horribly if the path to your home account
changes. In particular, it doesn't work when using the same account
from an OS X Server vs. OS X client box on a single network.
- (maybe fixed in 10.2) If I set OmniWeb as my default browser and
upgraded OmniWeb in the typical 'mount the disk image, drag and drop
the app into my Applications directory, click "replace" when the
finder asks', the system preferences happily maintains a reference to
the ORIGINAL version of OmniWeb -- the version that is now in the
trash! As soon as I empty the trash, SP reverts to IE. Not at all
a good user experience.
- If I edit an ASCII template file for Radio UserLand (a fairly
typical old school Mac classic App) with TextEdit, emacs, or any other
editor that saves a backup file and does so atomically (as a good
program should), Radio Userland will continue to use the last revision
of the file and won't reference the new file until I save the file
*again* and thereby delete the backup file to which the reference was
still pointing. Office used to do something similar and I frequently
found myself editing the OLD version of some random document where I
had been sent a newer version via email and had tried to copy it over
the old version.
Now, certainly, most of these issues could be considered actual bugs
in the applications and not necessarily bugs inherent to the design of
aliases (or file system references). But that is part of the point
-- this is something that the developer needs to think through
carefully. The default behavior of either Aliases or Just Plain
Paths is far from ideal.
The one default behavior of Aliases that I find particularly annoying
is epitomized by the third example. It is occasionally very handy
that an app like IB, TextEdit, emacs, etc... saves the last version as
a backup version (i.e. edit 'foo.txt', click 'save', TE moves the
current file to foo~.txt and saves the new content to foo.txt).
However, Aliases interaction with this situation is really damned
annoying -- an Alias will follow foo.txt to foo~.txt. It should note
that 'foo.txt' is there, of the same type, and has a later
modification date and optionally ask the user if the alias should be
fixed to point to the new version (or, optionally, just fixed the
alias).
b.bum
On Thursday, Aug 29, 2002, at 16:50 US/Eastern, Nicholas Riley wrote:
A FSRef is not an alias; a FSRef is only valid for the lifetime of the
app. Aliases include path information. If you use aliases sensibly
in your code (and their behavior is free of bugs), everything should
work.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.