Re: Mac OS X 10.1 File Name Extension Guidelines [Fairly Long]
Re: Mac OS X 10.1 File Name Extension Guidelines [Fairly Long]
- Subject: Re: Mac OS X 10.1 File Name Extension Guidelines [Fairly Long]
- From: Tyler LaGrange <email@hidden>
- Date: Sun, 9 Sep 2001 14:53:01 -0400
I really hope that this proposed "Extension Guidelines" document is an
interim solution, not the longterm solution for OSX. This does feel
like a step in the wrong direction, but if it works for most end users
then so be it. I'll live with it for the next six months. But after
that I want something better.
For as long as I have been using a mac and arguing with others about why
I prefer it over a PC, the filename extensions was one of the things
that Me being the mac user, and my friend being the PC user could agree
was better done on a Mac. It is stupid for an Operating system to use
the extensions as the main way to determine a file type.
The proposed solutions by Brendan below are more long term - but a MUCH
more elegant solution to fixing the "problem" of the mac being a
"Network friendly" system. I can't even count the number of times on
Windows I ended up with "somefile.xsl.txt" from notepad - and it wasn't
immediately obvious because the .txt is hidden. Once you are familiar
with how to show the extensions - or get the file info - the problem
goes away - but at first it is frustrating. It appears as if Apple is
trying to avoid such situations and I suppose I can just hope for the
best.
We simply can not resort to the lowest common denominator in order to be
"Network friendly". Like others have said on here - the "benefits" of
owning a mac are slowly dwindling away when we dumb the system down to
play nice with Windows and UNIX. It would be a lot of work for our
systems and the applications we develop to magically add and remove
extensions and/or metadata to play nice with others - but as long as an
API existed, we wouldn't mind adding this stuff in to our apps.
I can't help but feel that this is a sad way of admitting defeat -
instead of fighting to say "Yes - we are correct and file metadata
should be done this way - but we will add some extra system level
features to make it work right with your inferior operating systems
until you catch up with us". That is the apple I want to support.
If we are slowly turning the Mac into just a "prettier interface" on top
of the "same exact OS features we can get on any other Operating
system" - it's going to be hard for us to argue for why we choose Mac
over PC or something else. How long will it be before Red Hat has a
really nice installer - with a pretty interface - and a new "Cocoa-like"
API - and enough application support to pull people to Linux? It will
certainly run on cheaper hardware with "faster" processors.
And on that note - how come all the new macs still have one stupid mouse
button instead of two buttons with a nice little scroll wheel? Aren't
there some better system level features to steal from Windows and UNIX
such as a standard multi-button mouse - instead of stealing the pathetic
way in which they associate file extensions with types and applications?
Tyler
On Sunday, September 9, 2001, at 01:36 PM, Brendan Younger wrote:
Well, since it was kindly pointed out to me that my previous rant might
have been a bit long, here's the short version.
If Brendan Younger were running Apple's UI design shop:
What Apple needs to do to provide the richest possible experience as far
as file typing is concerned:
1. Either enforce the setting of type/creator codes or come up with a
new, fully modernized way of typing a file. (eg. The MIME-like typing
suggested by Siracusa in
http://arstechnica.com/reviews/01q3/metadata/metadata-1.html.)
2. Create a new API along the lines of: -[NSFileManager
createFile:filename inDirectory:dirID ofType:sometype]. When saving to
a volume which doesn't support the typing metadata, then append the
appropriate extension to the file.
3. Have all applications provide a dictionary of the types they can
read/write and the equivalent extensions. (This is how the system knows
what extension to use for #2.)
4. Allow a file to be specified in two possible ways. Asking for a file
of type "HTML" which is named "Moof" and asking for a file named
"Moof.html" are precisely equivalent. That is, if there exists an html
file named "Moof", both methods return the same file (unless there
exists a file named Moof.html also, in which case the second method has
no problems and the first returns both files).
5. When a foreign system which does not know of HFS+ metadata asks for a
directory listing, the filesystem returns names with the appropriate
extensions added. This is the kicker. This is probably why Apple wants
extensions on all files, so that other systems know what to do with them
even when they reside on HFS+ volumes. However, in the utopian future,
most, if not all, filesystems would be able to at least understand some
of the metadata and hence the display of file extensions would be simply
a weaning process.
It is important to note that the above system performs almost exactly
like the one described and apparently blessed by Apple. What, then are
the advantages of my system? Not only does it provide a clear path to a
future without file extensions, but it helps in the following example:
Let's say I'm writing a shell script for some package that I've made. I
have a text editor and a finder window open. When referring to the
names of the files, I go on what I see in the Finder window. If I have
extensions turned off, I never see the extensions and thus get the names
wrong. If I have extensions turned on, I may still get the names wrong
because some files may have the "Hide Extension" bit set. I should not
have to resort to the Terminal simply to tell what the *real* filenames
for my files are. Now in my system, I can see any and all extension
which I have *explicitly* placed in my file's names. Thus, my shell
script works.
Please Apple, don't do something silly when it could be done better and
in a more elegant fashion. Please.
Brendan Younger
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev