Mac OS X 10.1 File Name Extension Guidelines
- Dear Cocoa Developer,
Mac OS X introduces file name extensions. In adding this capability to Mac
OS X, we've worked hard to provide maximum compatibility with other
operating systems, as well as files exchanged with other users over the
Internet, while preserving the user experience Macintosh users are familiar
with.
The guidelines below provide an in-depth explanation about how this will
work in Mac OS X 10.1, and what your responsibilities are as a developer.
Please note that the NSFileManager class (in Puma) now supports setting the
HFS type & creator code, so Cocoa apps do not need to call Carbon directly
to do this anymore.
Note too, that Apple *will* be co-ordinating and managing a file name
extension registry (much like what we do today for creator and type codes).
Stay tuned for more info.
Please read these guidelines in their entirety *and* try out the described
behaviours for yourself on a Puma 5G48 build or later. As of Puma 5G50,
these guidelines will be included in the Developer Release notes.
I trust you'll find this information valuable.
John Geleynse
User Experience Technology Manager
Apple Worldwide Developer Relations
===========================================
File Name Extension Guidelines
File Name Extension Hiding
File name extensions and file types are two ways to associate the same
information with a single file: What format the file is. Mac OS 9 stores
this information in a file's meta data as HFS file types. Most other
operating systems, including Windows and most UNIX systems, use file name
extensions to store format information for a file.
Mac OS X aims to provide maximum compatibility with other operating systems,
as well as files exchanged with other users over the Internet, while
preserving the user experience Macintosh users are familiar with. To
accomplish this, Mac OS X version 10.1 introduces per-file hiding of file
name extensions. This feature allows applications to store type information
in file name extensions (enabling easy exchange of files with users on other
platforms or over the Internet) while still presenting a simple, human
readable name to the user. The experience Mac OS X presents to the user is
simple: What you see is what you type. That is, the file name shown in the
Finder matches the file name you typed in the Save dialog or in the Finder.
If you type a file name with an extension, you see the extension. If you
type a file name with no extension, you see no extension.
Finder Handling of File Name Extensions
The Finder in Mac OS X 10.1 has been enhanced to respect the presence of a
file name extension hidden flag stored for each file. The Finder works in
conjunction with Launch Services to determine what extensions are known to
the system. Known extensions are those claimed by an application in any of
the "regular" application search paths, or claimed by an application the
user has previously launched that is installed in some other location. (For
information on search paths and how the Finder deals with applications, see
Inside Mac OS X: System Overview, specifically the chapters on the File
System and the Finder.)
Files created by Mac OS 9, downloaded from the Internet, or obtained from
some other source always have the hide extension flag unset initially,
regardless of whether or not they have an extension. Therefore, when a user
downloads a file "image.jpg" from the Internet, it does not magically rename
itself to "image" in the Mac OS X Finder. What the user sees stays
consistent. If the user later renames the file to "mygroovyimage", the .jpg
extension is maintained, but becomes hidden. Again, what the user typed
matches what is displayed. In no case will Mac OS X rename an existing file
without the user taking a specific action to rename that file, nor will
renaming a file ever result in accidental multiple extensions (like "
mygroovyimage.jpg.jpg").
Any file with the hide extension flag set and a known extension has that
extension hidden in the Finder. When users edit the name of such a file,
they edit only the user-visible portion. If they explicitly type in a known
file name extension for the file, either the Finder warns them that what
they're doing may change the type of the file (if they enter a different
file name extension), or the Finder changes the state of the hide extension
flag to show the extension (if they enter a new file name with the proper,
currently hidden extension for the file). In all cases, the Finder allows
users to make the changes if they wish. What users see in the Finder is what
they typed when renaming the file, whether or not they included an
extension.
The Finder also allows users to choose to always display file name
extensions, disabling the smart extension hiding behavior that is on by
default. If users want to keep the smart extension hiding on, but need to
know the exact on-disk file name for a given file, they can see it in that
file's Info window in the Finder. Users can also control whether a specific
file's extension is hidden using a checkbox in the Info window.
Interoperability
With the addition of file name extension hiding, it's possible for every
file on the system that has a specific format to also have an extension
indicating that format. Users don't need to be aware of the extension, and
will not accidentally remove it using the Finder. When a user copies the
file to a non-Mac OS system, the file name extension is present and gives
the operating system the information it needs to handle the file correctly.
On Mac OS X, applications that already write out file name extensions for
interoperability purposes now provide an enhanced user experience; these
file name extensions can be hidden on Mac OS X but automatically get
transferred with the file as it moves to a non-HFS file system. An example
of this is when a user uploads a web site containing html and movie files.
Since the movie files already have their proper file name extensions they
don't need to be renamed and links in associated web pages aren't broken as
a result.
Application Responsibilities
To preserve the "what you see is what you typed" user experience, while
supporting robust interoperability by using file name extensions to indicate
file format, applications have several responsibilities. Apple recommends
that applications adopt the following behavior:
* All document files should have an extension indicating the file's
format.
* When displaying file names in their user interface, applications should
use the display name for the file. Mac OS X version 10.1 includes an API to
get the display name for a file. See the "Support" section below for
details.
* When saving files, users should be able to control whether file name
extensions are hidden. For more details, see "Save Dialog Behavior," below.
* Applications should save newly created document files with a file name
extension, for easy exchange with other operating systems and other users
over the Internet. This file name extension can be hidden, as described in
"Save Dialog Behavior," below.
* When opening and saving a document file, applications should preserve
the value of the document file name extension hidden flag.
* When opening and saving a document file, applications should preserve
the existing file name extension unless the user creates a new document file
by choosing Save As.
* When opening and saving a document file without an extension,
applications should not append an extension or change the value of the hide
extension flag.
* When saving a document file without an extension as a new file in a
Save As operation, applications should add an extension just as they would
when creating a new document file.
Applications may set an HFS file type for documents they create if they
wish. The benefit is increased interoperability with Mac OS 9 applications.
Any existing HFS type of a file opened and saved by an application should be
preserved, unless the user does an explicit Save As operation that creates a
new file, or the application changes the type of the file as a result of the
editing. If the user performs a Save As operation, the application may
choose what file name extension and file type to use for the newly created
file. If the application changes the type of the file as a result of editing
it, the application should generally save it as a new file.
Applications may set an HFS creator for documents they create if they wish.
This creates a tight binding between the newly created document and the
application that created it. Users can always change which application is
used to open a specific document, or all documents with a specific type and
creator code, by using the Info window in the Finder. If an application
wants to change the creator code for a file it opens, the application should
bring up a Save dialog when the user saves the file. At this point it is
also appropriate to add an extension to indicate the type of the file.
Applications that are not a primary editor for documents of a given type
should not set a creator code for those documents. The main example of this
is an Internet browser that downloads files of many different types. In Mac
OS X, users can associate applications with files of a given type using file
name extensions. Browsers downloading files from the Internet should allow
the user to choose which application to use to view those files by simply
allowing the Finder to open them with the user's default application for
that file type.
Save Dialog Behavior
Applications should support ease of interoperation with other operating
systems and Internet services by saving files with file name extensions.
Your application should claim the file name extensions it saves by making
appropriate entries in its Info.plist. See the discussion of file types in
the "Installation and Integration" chapter of Inside Mac OS X: System
Overview for details.
To support user controlled per-file file name extension hiding, applications
need to explicitly enable the new behavior provided by Carbon and Cocoa in
their Save dialogs.
Applications that enable this new functionality will see the following new
behavior in their save dialogs. A hide extension checkbox appears to the
left of the Save and Cancel buttons in the expanded view of the Save dialog.
(This checkbox does not appear in the collapsed version of the Save dialog.)
The state of this checkbox controls whether the file name extension is
displayed both in the Finder and the application. The Save dialog remembers
the last state of the hide extension checkbox as set by the user and
preserves it for future save operations.
There are three scenarios to consider when the user is saving a file:
1. The user types a file name with no extension or with an extension not
known to the system (for example 3My Document.old2).
The hide extension checkbox is checked, and the file is saved with the file
name extension appended to the name the user entered. The hide extension
flag is set in the file system for the new file. The Finder displays the
document name as 3My Document.old2.
2. The user types a file name with the known, correct extension.
The hide extension checkbox is automatically deselected, and the file is
saved with the file name and extension as entered by the user. The hide
extension flag is set to "no" in the file system for the new file.
3. The user types a file name with a known, incorrect extension.
The Save dialog displays an alert warning the user that they can not save
the file with the incorrect extension, and indicates what the correct
extension is. The dialog gives the user the choice of saving the file with
the correct extension, saving the file with both extensions, or canceling
the operation.
For example, if a user tries to save a TextEdit document as "MyFile.jpg",
the alert reads, "You cannot save this document with the extension '.jpg' at
the end of the name. The required extension is '.rtf'. You can choose to use
both, so that your file name ends in '.jpg.rtf'." The buttons are Use .rtf,
Cancel, and Use both. ".rtf" is the correct extension for this document as
set by TextEdit, and Use .rtf is the default button. In no case will the
system hide an extension if doing so would make the file appear to have a
different, valid extension. Therefore, if the user choosed "Use both", the
Finder will display the full saved filename, "MyFile.jpg.rtf".
Support
Carbon and Cocoa both provide API to support the above described behavior.
Getting a File's Display Name
Carbon: Use LSCopyDisplayNameForRef or LSCopyDisplayNameForURL.
Cocoa: Use NSFileManager's displayNameAtPath: method.
Applications should always use the file's display name in their user
interface, as returned by the above functions. The display name can vary
depending on several factors, and using the proper API is the only way to
guarantee that the file name you display in your user interface matches the
file name displayed in the Finder.
Enabling File Name Extension Hiding in Save Dialogs
Carbon: Enable the kNavPreserveSaveFileExtension dialog option bit for the
Navigation Services save dialog, call NavCompleteSave after creating the new
file, and use LSCopyDisplayNameForRef or LSCopyDisplayNameForURL after
saving a file so you can set the file name displayed in the window's title
bar to the correct display name.
Cocoa: Use NSSavePanel's setCanSelectHiddenExtension: method to enable this
feature before displaying the save panel. NSDocument automatically sets the
hide extension flag appropriately for applications that use it. Applications
that do not use NSDocument should query the Save panel themselves and set
the flag using NSFileManager's createFileAtPath:contents:attributes: method.
* Copyright ) 2001 Apple Computer, Inc.
=========================================== - Well, I guess I'll be the first to comment on this.
Overall, these rules make sense. Especially the part about ensuring
that an extension would never be hidden if that would make the file
appear to be a different type. It looks like it will work, on one
condition:
That file extensions exist for compatibility with other platforms only,
and that Mac OS X does not use the filename extension in determining
what kind of file it is. Of course, right now it appears that this is
sadly not the case.
Even just setting type/creators on a per-user basis would be good
enough. Obviously, the HFS space reserved for types/creators couldn't
be used for per-user settings, but I really don't care where it is
actually put, as long as it is put somewhere.
Are type/creators set per-user in 10.1, or if not, do we have any hope
of a filetyping system that does not require the existence of filename
extensions in the future?
Personally, I would love to see the hierarchical system that some have
talked about here: image/jpeg/com.apple.Preview,
text/html/com.barebones.BBEdit
In the meantime, I guess I had better start looking at what changes to
my code this will require.
Richard Schreyer - Richard,>>>>>> Richard Schreyer (RS) wrote at Fri, 7 Sep 2001 13:03:59 -0700:RS> Well, I guess I'll be the first to comment on this.
Actually, I guessed it will be better to wait and _actually_ check the thing
before commenting on ;)))
RS> It looks like it will work, on one condition:
RS>
RS> That file extensions exist for compatibility with other platforms only,
RS> and that Mac OS X does not use the filename extension in determining
RS> what kind of file it is.
It looked to me it will work _quite nicely_ if OS X uses extensions to
determine file type. Why do you think otherwise?!?
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - On Fri, 7 Sep 2001, Richard Schreyer wrote:> Well, I guess I'll be the first to comment on this.
>
> Overall, these rules make sense. Especially the part about ensuring
> that an extension would never be hidden if that would make the file
> appear to be a different type. It looks like it will work, on one
> condition:
>
> That file extensions exist for compatibility with other platforms only,
> and that Mac OS X does not use the filename extension in determining
> what kind of file it is. Of course, right now it appears that this is
> sadly not the case.
Extensions are just one of the ways to determine a file type...in no way
is it meant to be the end-all be-all method. Currently, I see three
combos that we can have:
* Type & Creator Only
* Extensions Only
* Both
In the case of "Both", I'm assuming that type & creator will "win".
Then, you can also get into "magic cookie" data (i.e. peeking at the
contents of the file itself).
There's probably some technote (or there should be one soon) describing
just how a file type is determined...i.e. what data does the OS look at
first, second, etc.
In the case of file contents, when and how would that scheme be used. I
think this breaks down very quickly though. e.g. a text document named
foo whose contents start with %PDF, and a PDF document named bar which of
course starts with %PDF too. Fun huh?
Rick Sharp
Instant Interactive(tm) - On Friday, September 7, 2001, at 01:31 PM, rsharp wrote:> There's probably some technote (or there should be one soon) describing
> just how a file type is determined...i.e. what data does the OS look at
> first, second, etc.
The System Overview document already covers this pretty well. The order
is:
- if there's a creator, use the app with that creator
- else if there's an extension, use the app that claims that extension
- else if there's a file type, use the app that claims that file type
In case of ties (multiple apps that all claim the same file type or
extension), various attributes of the applications are used to determine
which wins: latest version, most recent modification date,
Apple-installed over third-party.
-eric - What will happen if a directory contains two files that differ only by
extension and extensions are hidden ? I don't recall the paper mentioning
that scenario. myFile.jpeg and myFile.tiff in the same directory. - On Friday, September 7, 2001, at 01:56 PM, Erik M. Buck wrote:> What will happen if a directory contains two files that differ only by
> extension and extensions are hidden ? I don't recall the paper
> mentioning
> that scenario. myFile.jpeg and myFile.tiff in the same directory.
All I can think of is that in such a case, every one of the files in
question automatically has it's 'hide extension' but turned off.
This should also happen in the case of Foo.app and foo.whatever. With
this new system, I guess people will be less surprised to see extensions
magically appearing, even on applications.
Another possibility is a warning dialog when you try to
rename/copy/move/save a file: 'this file will appear to have the same
name as this file/these other files', and an option to cancel, rename,
or rename and show all extensions (latter being the default).
Of course, if this should happen during a copy of multiple files, I
really hope to see 'yes to all' options, as I do for other errors during
copies.
Richard Schreyer - > What will happen if a directory contains two files that differ only by
> extension and extensions are hidden ? I don't recall the paper
> mentioning
> that scenario. myFile.jpeg and myFile.tiff in the same directory.
There are good reasons to disallow, and maybe even some reasons to allow
this; but in 10.1 this situation is not prevented by Finder, Save panel,
or Nav services. (This could change in a future update.)
In any case, because there could be preexisting conditions, this case
needs to be dealt with correctly (that is, programs should not get
confused because there are two files with the same display name). If
such a case does exist, there are often other clues to the file's
identity --- its icon for instance, which is visible in most cases; or
the detailed info in the column view's last column, etc...
Ali - > For example, if a user tries to save a TextEdit document as
> "MyFile.jpg",
> the alert reads, "You cannot save this document with the extension
> '.jpg' at
> the end of the name. The required extension is '.rtf'. You can choose
> to use
> both, so that your file name ends in '.jpg.rtf'." The buttons are Use
> .rtf,
> Cancel, and Use both. ".rtf" is the correct extension for this document
> as
> set by TextEdit, and Use .rtf is the default button. In no case will the
> system hide an extension if doing so would make the file appear to
> have a
> different, valid extension. Therefore, if the user choosed "Use both",
> the
> Finder will display the full saved filename, "MyFile.jpg.rtf".
And what if I want to save a SomeRandomScript.pl file from TextEdit? I
don't see any provision for this.
In general, this is my issue with filename extensions. To really make
them work in all situations, it requires so many rules and exceptions
that often you really can't guess what is going to happen...
Extensions should remain for compatibility purposes, and with a code (or
some equivalent), so I can name my file script.pl, and TextEdit, BBEdit,
and anything else knows it can open it.
Richard Schreyer - Since this is a user interface issue, and since the purpose of the
extension is to tell the user what type of file each is, I think icons
provide enough distinction. Whenever the Finder is forced to use a generic
document icon, that ought to tell it that it needs to ignore the
hide-extension bit and show the extension anyway.
Cheers,
Tony
On Friday, September 7, 2001, at 04:56 , Erik M. Buck wrote:> What will happen if a directory contains two files that differ only by
> extension and extensions are hidden ? I don't recall the paper mentioning
> that scenario. myFile.jpeg and myFile.tiff in the same directory.
> _______________________________________________
> cocoa-dev mailing list
> <cocoa-dev...>
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev - Richard,>>>>>> Richard Schreyer (RS) wrote at Fri, 7 Sep 2001 14:25:03 -0700:RS> And what if I want to save a SomeRandomScript.pl file from TextEdit? I
RS> don't see any provision for this.
You would not do that with RTF contents, would you?
I dunno how it is supported in 10.1 actually, but I guess
(a) this makes sense for applications which can open _any_ extension
(TextEdit/plaintext is one good example; there should be more such);
(b) if so, no extension will be forced down your throat.
Well, actually, I guess we *REALLY* should postpone this discussion to the
time we really have 10.1 and have checked it! Don't you think?
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - What about if an application creates a file in a widely used format,
but the files it creates are most likely only going to be used in
that application. Examples:
html files in GoLive
cp, cpp, c, h, m files in Project Builder, BBedit, CodeWarrior.
jpegs in Photoshop, ColorIt.
And what about the lengths of extensions? Can "known" extensions be
only a max of x letter or do they have a minimum. And what about the
case of files that end in .# (where # is any positive integer), will
those "extensions" be ignored if they are preceded by a known
extension?
Ack, at 9/7/01, John Geleynse said:> Applications that are not a primary editor for documents of a given type
> should not set a creator code for those documents. The main example of this
> is an Internet browser that downloads files of many different types. In Mac
> OS X, users can associate applications with files of a given type using file
> name extensions. Browsers downloading files from the Internet should allow
> the user to choose which application to use to view those files by simply
> allowing the Finder to open them with the user's default application for
> that file type.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People - On Friday, September 7, 2001, at 05:53 PM, Rosyna wrote:> What about if an application creates a file in a widely used format, but
> the files it creates are most likely only going to be used in that
> application. Examples:
>
> html files in GoLive
> cp, cpp, c, h, m files in Project Builder, BBedit, CodeWarrior.
> jpegs in Photoshop, ColorIt.
These are all examples of files I would be extremely *unlikely* to only
use within a specific application.
-john - > And what if I want to save a SomeRandomScript.pl file from TextEdit? I
> don't see any provision for this.
TextEdit's "deal with any extension" situation is really a special case,
and yes, such apps do have a few extra cases to deal with. For instance
TextEdit by default appends "txt" extension to new plain text documents,
unless you turn this off in TextEdit's preferences, or specify some
other extension while saving (in which case it puts up a panel to
confirm what extension you really want).
Ali - On Friday, September 7, 2001, at 06:46 PM, Ali Ozer wrote:> (in which case it puts up a panel to confirm what extension you really
> want).
Will there be any way to turn *that* off? I just tried it and it'd be
extremely annoying if I used TextEdit regularly. If I add an extension I
meant to add it, and appending '.txt' is only going to screw things up.
-john - Where are most people going to use a .m file outside of Project Builder?
Ack, at 9/7/01, Enigmarelle Development said:> On Friday, September 7, 2001, at 05:53 PM, Rosyna wrote:
>
>> What about if an application creates a file in a widely used
>> format, but the files it creates are most likely only going to be
>> used in that application. Examples:
>>
>> html files in GoLive
>> cp, cpp, c, h, m files in Project Builder, BBedit, CodeWarrior.
>> jpegs in Photoshop, ColorIt.
>
> These are all examples of files I would be extremely *unlikely* to
> only use within a specific application.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People - I just edited one in BBEdit the other night. I was in 10.0.4 and needed to
make changes to a source file I'd been working on in (a later release than
10.0.4). I didn't want to deal with ProjectBuilder stressing me about file
formats & data loss, so I just did it in BBEdit.
Granted it was an easy drag & drop, but I'm sure Bare Bones plans to
improve BBEdit's integration with OSX's developer tools, and there was
talk on this list awhile back about opening PB up to external editors.
-john
On Friday, September 7, 2001, at 07:02 PM, Rosyna wrote:> Where are most people going to use a .m file outside of Project Builder? - At 11:27 PM -0700 7/9/01, j o a r wrote:> Ironic, isn't it, that after having been used as one of the
> arguments of the HFS/UFS wars - the fact that two file names should
> or shouldn't differ only by case - we now have a situation where
> they might not even differ by that (at least from a user
> perspective)...
>
> I, for one, don't like this new direction from Apple - but I know
> that what I think doesn't matter so I will not bother to b**ch about
> it. It's a path of least resistance, it's not progress in any shape
> or form, but I digress...
I agree with you!
The only possible reason for file name extensions is to pander to the
pc market and its 8.3 legacy. It is a computer, not human interface
issue and should not be a consideration in modern user interfaces -
it has nothing to do with the Mac, OS X or the future.
(I'll calm down now and get on to something useful...)
Karl
--
----
Klaatu barada nikto - On Saturday, September 8, 2001, at 01:11 , Enigmarelle Development wrote:> there was talk on this list awhile back about opening PB up to external
> editors.
Wouldn't make sense, it's like opening up BBEdit to external perl editors.
Those other editors should just call pbxbuild for compiling. Maybe it's
already possible in BBEdit to do that, I don't know.
andy
--
"He was addicted to life. But we cured him" - ----- Original Message -----
- Talk about going from bad to worse. These "new" guidelines will only make
this issue more complicated, not less. The fact that it takes a 5 page
document to describe the behavior should give some indication of this.
If you want simple (from the user's stand point):
1. Applications *SHOULD ALWAYS* use Creator/Types, whether they developed
using Cocoa or Carbon. In other words - when the user creates a file with a
program, their Mac knows what program they created that file with and can
act appropriately.
2. Filenames are the users domain. They, and only they, determine if it has
a file extension and then only for readability. While a possible extension
may be used as an "alternative" method to determine it a file's type --
Creator/Type metadata remains the primary method for this.
3. The Finder (ie the File Manager) can provide the appropriate
transformations on creation (ie. from download, copy from another volume) or
on copy to non-HFS formatted volumes.
Sound familiar? It should - that's basically how Mac OS 9 works.
I find it ironic that Apple is pushing forward with filename extensions and
"flat" files when other OS companies (ie Microsoft) are offering disk
formats (NTFS) that add more (not less) metadata support, plus multi-forked
files. Of course there is also the issue with directory ID's/file ID's vs.
easily broken pathnames - but that will have to wait until Apple once again
pushes their stupid URL/pathname approach to identifying files.
Apple says they want to maintain compatibility with UFS, but 99.5% (or more)
of their users are running on HFS Plus volumes -- yet Apple isn't taking
advantage of the very cool features offered by that filing system. And they
don't seem to listen to their developers who are closer to their customer
than they are.
I wonder if Apple even knows who their customer is or if they just have some
wild notion of what they *WANT* their customer to be like and think that
somehow the customer can be pushed to "see the light" and change their ways.
Mark Munz
unmarked software - Am Samstag, 8. September 2001 um 02:05 schrieb Mark Munz:> Apple says they want to maintain compatibility with UFS, but
> 99.5% (or more)
> of their users are running on HFS Plus volumes
Maintaining UFS at the Filemanager level automatically includes
maintenance for most other (Network-)filesystems.
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/ - On Friday, September 7, 2001, at 04:15 PM, Karl Goiser wrote:>
> The only possible reason for file name extensions is to pander to the
> pc market and its 8.3 legacy.
...and the UNIX world, with its N.N(xN!) "legacy", and every other
filesystem in the world that doesn't happen to support the Mac's extra
64 bits of file metadata that bugger any attempt to transfer files to
any system but Macintosh.
Look, like it or not, the Mac isn't a standalone machine anymore. If
every other system out there could be persuaded to (say) take all files
with an XML preface that kept whatever metadata you like, then we
wouldn't have a problem.
-jcr
"The problem with trying to child-proof the world, is that it makes
people neglect the far more important task of world-proofing the
child." -- Hugh Daniel - On Friday, September 7, 2001, at 01:56 , Erik M. Buck wrote:> What will happen if a directory contains two files that differ only by
> extension and extensions are hidden ? I don't recall the paper
> mentioning
> that scenario. myFile.jpeg and myFile.tiff in the same directory.
Look at the two instances of "Finder" that already exists in
/System/Library/CoreServices for a hint of things to come...
I don't belive that you will be either warned nor prevented to have two
files with the same name in the same directory.
Ironic, isn't it, that after having been used as one of the arguments of
the HFS/UFS wars - the fact that two file names should or shouldn't
differ only by case - we now have a situation where they might not even
differ by that (at least from a user perspective)...
I, for one, don't like this new direction from Apple - but I know that
what I think doesn't matter so I will not bother to b**ch about it. It's
a path of least resistance, it's not progress in any shape or form, but
I digress...
j o a r - On Friday, September 7, 2001, at 05:05 PM, Mark Munz wrote:>
> 2. Filenames are the users domain. They, and only they, determine if it
> has
> a file extension and then only for readability. While a possible
> extension
> may be used as an "alternative" method to determine it a file's type --
> Creator/Type metadata remains the primary method for this.
No way. Not until the finder makes it just as easy to change type and
creator as it is for me to stick a ".tiff" on a file when I know what
it's supposed to be.
-jcr
[Objc retain]; - On Friday, September 7, 2001, at 02:13 PM, Ali Ozer wrote:>> What will happen if a directory contains two files that differ only by
>> extension and extensions are hidden ? I don't recall the paper
>> mentioning
>> that scenario. myFile.jpeg and myFile.tiff in the same directory.
>
> There are good reasons to disallow, and maybe even some reasons to allow
> this; but in 10.1 this situation is not prevented by Finder, Save panel,
> or Nav services. (This could change in a future update.)
Actually, for the particular case of an image file, I'd like the finder
to provide some kind of magic morphing alias, such that if I have
image.tiff in some directory, I can navigate to
./image/image.[gif|png|jpeg|rif|etc] , which would be created on demand.
Andy Stone's image drag wells in Create! are wonderful, and I'd like to
see that kind of thing done pervasively where filter services allow it.
-jcr
"The problem with trying to child-proof the world, is that it makes
people neglect the far more important task of world-proofing the
child." -- Hugh Daniel - On Saturday, September 8, 2001, at 03:01 AM, John C. Randolph wrote:>> There are good reasons to disallow, and maybe even some reasons to
>> allow
>> this; but in 10.1 this situation is not prevented by Finder, Save
>> panel,
>> or Nav services. (This could change in a future update.)
>
> Actually, for the particular case of an image file, I'd like the finder
> to provide some kind of magic morphing alias, such that if I have
> image.tiff in some directory, I can navigate to
> ./image/image.[gif|png|jpeg|rif|etc] , which would be created on demand.
Ideally this wouldn't be limited to just images.. but to ANYTHING
that could be converted from A to B.
Not that this is particularly straightforward in many cases
(including even in this simple case for example .jpeg to .gif
[dithering, image palette etc])
Remembering the possibilities of the old FilterServices, and the
Anderson Financial file format filters.. sigh.. - > On Friday, September 7, 2001, at 01:56 PM, Erik M. Buck wrote:Yes! All collisions should be handled this way. Revealing the ext in
>
>> What will happen if a directory contains two files that differ only by
>> extension and extensions are hidden ? I don't recall the paper
>> mentioning
>> that scenario. myFile.jpeg and myFile.tiff in the same directory.
>
> All I can think of is that in such a case, every one of the files in
> question automatically has it's 'hide extension' but turned off.
>
such a case is absolutely a superior solution, and is greatly preferred
before banning multiple file name roots all together (many unix packages
of different types have for example configure.in configure.cache and
configure. I sure want to see which one is which...)
/ david - On Saturday, September 8, 2001, at 12:58 AM, Scott Anguish wrote:> On Saturday, September 8, 2001, at 03:01 AM, John C. Randolph wrote:
>
>>> There are good reasons to disallow, and maybe even some reasons to
>>> allow
>>> this; but in 10.1 this situation is not prevented by Finder, Save
>>> panel,
>>> or Nav services. (This could change in a future update.)
>>
>> Actually, for the particular case of an image file, I'd like the
>> finder to provide some kind of magic morphing alias, such that if I
>> have image.tiff in some directory, I can navigate to
>> ./image/image.[gif|png|jpeg|rif|etc] , which would be created on
>> demand.
>
> Ideally this wouldn't be limited to just images.. but to ANYTHING
> that could be converted from A to B.
Well, yeah. I'm thinking it could appear in the rightmost column of the
browser in both the finder and the open/save sheets. Popup list of how
you could get the contents, right underneath the preview.> Not that this is particularly straightforward in many cases
> (including even in this simple case for example .jpeg to .gif
> [dithering, image palette etc])
In that case, you can of course warn the user about that, just like when
you warn about converting from rich to plain text.> Remembering the possibilities of the old FilterServices, and the
> Anderson Financial file format filters.. sigh..
Yep. When Mac OS reaches parity with NeXTSTEP, it's still a long way
from the ultimate user environment.
Something else that would be REALLY nice, is in the standard save sheet,
if you tried to save a file whose name conflicted with an existing file,
your options wouldn't just be to save or cancel, but you could also view
the existing file and/or compare the two in filemerge.
-jcr
"Scientology is evil; its techniques are evil; its practice is a serious
threat to the community, medically, morally, and socially; and its
adherents are sadly deluded and often mentally ill... --Justice
Anderson, Supreme Court of Victoria, Australia - My first reaction is (mainly) a thumbs-up. I don't like filename
extensions to be a necessity, it seems rather archaic for an OS to
need to use a file's name to figure out what kind of file it is.
However, I understand that we can't really avoid file extensions now
as they're all over the internet, and even if other OSes get rid of
their extensions, they'd be saving the metadata in a different way so
there would still be problems sending files over the internet. If we
must have file extensions, I think what was described is about the
best behaviour that 10.1 could have for them... in fact I think that
to the user it will seem just like it was in OS 9. The way the system
knows what sort of file it is is hidden unless you explicitly put an
extension on the name.
Then I read a few other posts, and I hope that there is something to
stop the creation of two files with the same name and different
hidden extensions. It's a complicated issue though. If the hidden
extensions are to be thought of in the same way as the OS 9 file
types (which is how I like to think of them, and how it seems they
will act, for the most part) then it would be impossible to have two
files in the same directory with different extensions. But that would
have to apply to files with visible extensions too, so that nothing
weird would happen if the user changes the preferences to always or
never (or is that not an option? I can't remember) show the file
extensions. That's not feasible because we don't want to have Blah.m
and Blah.h in different directories. I guess the best way would be,
as someone suggested, to have the extensions automatically unhidden
when there are two files with the same name in a directory, although
that contradicts the 'what you type is what you get' idea and could
confuse new users.
At 3:46 PM -0700 7/9/01, Ali Ozer wrote:> TextEdit's "deal with any extension" situation is really a special case,
> and yes, such apps do have a few extra cases to deal with. For instance
> TextEdit by default appends "txt" extension to new plain text documents,
> unless you turn this off in TextEdit's preferences, or specify some
> other extension while saving (in which case it puts up a panel to
> confirm what extension you really want).
I never liked having .txt on TextEdit files, and turned that option
off... only to find that the Finder doesn't know which app to open
the files I created in TextEdit with. I don't use TextEdit much now.
I know this is a off-topic, but why can't I drag and drop text in
TextEdit? I really like being able to do that.
Okay, another tangent which I thought of because of SimpleText
files... I'd really like to have the option of making OS X always ask
before opening Classic. It's really annoying to double click on a
file and then discover that it's going to open in a Classic
application, so I have to wait for Classic to start up - I prefer to
have Classic running as little as possible as it uses up a lot of
resources. That's especially annoying if the file could have been
opened in OS X. I know having it ask before opening Classic makes the
OS 9 integration less seamless, but that's why it would only be an
option.
--
Angela Brett <angela...> http://acronyms.co.nz/
"Great minds think different." - On Saturday, September 8, 2001, at 01:53 pm, Angela Brett wrote:> I never liked having .txt on TextEdit files, and turned that option
> off... only to find that the Finder doesn't know which app to open the
> files I created in TextEdit with. I don't use TextEdit much now. I know
> this is a off-topic, but why can't I drag and drop text in TextEdit? I
> really like being able to do that.
You can. You just need a slight delay before dragging, otherwise it
starts selecting. This is just how the Cocoa text system behaves (it's
different from the Carbon text services you're probably used to). This
is probably a bug, though... Is the Cocoa or the Carbon functionality
correct?
-- Finlay - Consider this. The proxy icon drag in Cocoa apps is immediate. The
Carbon proxy drag needs a delay, so the text dragging and proxy icon
dragging behaviors are exactly opposite between carbon and cocoa.
There is much inconsistency with text in carbon and cocoa throughout
the OS.
Ack, at 9/8/01, Finlay Dobbie said:> On Saturday, September 8, 2001, at 01:53 pm, Angela Brett wrote:
>
>> I never liked having .txt on TextEdit files, and turned that option
>> off... only to find that the Finder doesn't know which app to open
>> the files I created in TextEdit with. I don't use TextEdit much
>> now. I know this is a off-topic, but why can't I drag and drop text
>> in TextEdit? I really like being able to do that.
>
> You can. You just need a slight delay before dragging, otherwise it
> starts selecting. This is just how the Cocoa text system behaves
> (it's different from the Carbon text services you're probably used
> to). This is probably a bug, though... Is the Cocoa or the Carbon
> functionality correct?
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People - On Saturday, September 8, 2001, at 02:53 PM, Angela Brett wrote:> My first reaction is (mainly) a thumbs-up. I don't like filename
> extensions to be a necessity, it seems rather archaic for an OS to need
> to use a file's name to figure out what kind of file it is.
There is also the 'file' command which does a decent job on well known
file formats, but of course does not know about every file formats,
especially not proprietary ones... (man file for more info).
Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch - On Friday, September 7, 2001, at 04:40 , R. Tony Goold wrote:> Since this is a user interface issue, and since the purpose of the
> extension is to tell the user what type of file each is, I think icons
> provide enough distinction.
Contrary case 1:
When files have image-thumbnail icons with no indication of type.
Case 2:
When icons distinguish type by words. Example, Preview.app icons
for various image types, incorporating "GIF" or "JPEG" etc.
At small icon sizes, such as in Open/Save panels, the words
are indistinguishable apart from their length.> Whenever the Finder is forced to use a generic document icon, that ought
> to tell it that it needs to ignore the hide-extension bit and show the
> extension anyway.
There may not be an extension. - On Friday, September 7, 2001, at 04:53 , Rosyna wrote:> What about if an application creates a file in a widely used format, but
> the files it creates are most likely only going to be used in that
> application. Examples:
>
> html files in GoLive
> cp, cpp, c, h, m files in Project Builder, BBedit, CodeWarrior.
> jpegs in Photoshop, ColorIt.
What's the problem? It's possible to assign default applications for
a type without using Creator codes.>
> And what about the lengths of extensions? Can "known" extensions be only
> a max of x letter or do they have a minimum.
Why would there be?> And what about the case of files that end in .# (where # is any positive
> integer), will those "extensions" be ignored if they are preceded by a
> known extension?
Why? That would be useful for noting application versions in the extension. - On Friday, September 7, 2001, at 05:57 , Enigmarelle Development wrote:> On Friday, September 7, 2001, at 06:46 PM, Ali Ozer wrote:
>> (in which case it puts up a panel to confirm what extension you really
>> want).
>
> Will there be any way to turn *that* off? I just tried it and it'd be
> extremely annoying if I used TextEdit regularly. If I add an extension I
> meant to add it, and appending '.txt' is only going to screw things up.
You have the source code. Go crazy. Make it do what you want. - Finlay,>>>>>> Finlay Dobbie (FD) wrote at Sat, 8 Sep 2001 14:06:35 +0100:FD> You can. You just need a slight delay before dragging, otherwise it
FD> starts selecting. This is just how the Cocoa text system behaves (it's
FD> different from the Carbon text services you're probably used to). This
FD> is probably a bug, though... Is the Cocoa or the Carbon functionality
FD> correct?
Cocoa, naturally. If for no other reason, then since it was designed so by
Apple programmers during the join: OpenStep/NeXTStep never had text d&d.
Should there be no delay, it would prevent selecting text by dragging
starting inside previous selection, that's why. I would like to see a
system-wide default for setting the delay though: I would set it to minute or
more, whilst those who are used to the old Mac way could set it to zero.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - Jonathan,>>>>>> Jonathan Hendry (JH) wrote at Sat, 8 Sep 2001 10:38:52 -0500:JH> >Will there be any way to turn *that* off? I just tried it and it'd be
JH> >extremely annoying if I used TextEdit regularly. If I add an extension I
JH> >meant to add it, and appending '.txt' is only going to screw things up.
JH>
JH> You have the source code.
I guess not. That would be the NSDocument class quite probably, whose
sources I would just love to have, but don't. You know of some way to get'em?
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - > No way. Not until the finder makes it just as easy to change type and
> creator as it is for me to stick a ".tiff" on a file when I know what
> it's supposed to be.
>
> -jcr
It's just as easy to strip off the ".tiff" and then no longer be able to
know what type of file that document was.
It seems like what you want is the Finder to be able to let you change the
creator / type of a file. Then ask for that feature, and not the desire to
change the definition of what kind of file it is based on what the user
calls it (mypic.tiff vs. mypic.jpg -- if I rename one "mypic", which type is
it then?).
Why override the use of filename to include both a file's description in
human terms PLUS what type of file it is to the system.
Mark Munz - >>>>>>> Finlay Dobbie (FD) wrote at Sat, 8 Sep 2001 14:06:35 +0100:
> FD> You can. You just need a slight delay before dragging, otherwise it
> FD> starts selecting. This is just how the Cocoa text system behaves
> (it's
> FD> different from the Carbon text services you're probably used to).
> This
> FD> is probably a bug, though... Is the Cocoa or the Carbon
> functionality
> FD> correct?
>
> Cocoa, naturally. If for no other reason, then since it was designed so
> by
> Apple programmers during the join: OpenStep/NeXTStep never had text d&d.
>
> Should there be no delay, it would prevent selecting text by dragging
> starting inside previous selection, that's why. I would like to see a
> system-wide default for setting the delay though: I would set it to
> minute or
> more, whilst those who are used to the old Mac way could set it to zero.
Most everyone classifies the cocoa way as the bug. My guess, is that
former NeXT employees were set to implement Cocoa drag-and-drop, but
like you they did not like it, and therefore put a brief delay in. The
proxy-icon dragging is wonderful in cocoa IMHO, but text dragging sucks
compared to the classic/carbon way. I see that there are two possible
intentions one could have, when starting a drag. Some styles want to
create a new selection, while others want to drag the text. There was a
time, back when drag-and-drop was implemented in Mac OS, when mac people
had to relearn their style, and do a fast click before dragging if they
wanted to create a new selection inside selected text.
/ david - Am Samstag, 8. September 2001 um 18:14 schrieb Ondra Cada:> Cocoa, naturally. If for no other reason, then since it was designed so
> by
> Apple programmers during the join: OpenStep/NeXTStep never had text d&d.
>
> Should there be no delay, it would prevent selecting text by dragging
> starting inside previous selection, that's why.
Are you serious, man? 99% of the time when I make a text selection it is
to drag (or copy) it and not to create another one starting from the
middle of the old one just for fun. In the 1% of error the Carbon
behavior prevents me from *nothing*, I just click once to remove the
selection.
The Cocoa behavior is a real pain in the lower back. Text and proxy icon
drag (where 99% of the time I want to drag the window and not the proxy
icon). They got it the wrong way around.
Manfred - I'm not talking about default applications for a type. I am saying if
you make an HTML file in GoLive chances are you are ONLY going to
edit it in GoLive. If you make a .m file in BBEdit, chances are thats
where you are going to edit it (and in that case it doesn't matter as
PB automatically displays files in a project in PB.
Ack, at 9/8/01, Jonathan Hendry said:> On Friday, September 7, 2001, at 04:53 , Rosyna wrote:
>
>> What about if an application creates a file in a widely used
>> format, but the files it creates are most likely only going to be
>> used in that application. Examples:
>>
>> html files in GoLive
>> cp, cpp, c, h, m files in Project Builder, BBedit, CodeWarrior.
>> jpegs in Photoshop, ColorIt.
>
> What's the problem? It's possible to assign default applications for
> a type without using Creator codes.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People - I must say that I am rather surprised at the lack of interest (or should
I say justifiable rage) on a rather important feature of user-interface
design. It is this lack of interest that is allowing Apple to do *very*
foolish things in the name of compatibility. (No pun intended.) To
begin with, I strongly suggest that all who haven't (including any Apple
Higher-ups) read:
http://arstechnica.com/reviews/01q3/metadata/metadata-1.html. Pay
particular attention to pages 8 onward. This is quite possibly the
best, most coherent and logical request for the elimination of
extensions I have ever read.
Now, eliminating file extensions would probably not be a wise thing to
do right now, especially if Apple wants to keep itself positioned to
have an OS which is the kind of go anywhere, do anything miracle
God-send that IT folks dream about. However, that does *not* mean that
they should adopt the lowest-common denominator for all their features
in order to retain compatibility with every possible system out there.
The goal (a lofty one which I think they had in mind when they embarked
upon OS X but which was gradually lost in the details) is to provide the
richest possible experience for the OS X user while allowing him/her to
interface, use or run, any program, any package, or any interface they
wish. Taken to it's logical conclusion, each Mac is indeed an island in
a sea of other platforms and ways of doing things. This does not mean
that the Mac should be in any way hostile to the other computing
platforms, but rather it should always retain its Macintosh qualities
and when faced with outsider's ways of doing things, the appropriate
translations should be in place. Think about it, presidents and leaders
of countries do not learn the language of every foreign diplomat or
leader which they encounter. They have someone translate. Apple needs
to bear this in mind. They have a rather unprecedented chance to
correct things and do things on the Mac OS that would reflect the
competence and class that they possess. Microsoft does not generally
*fix* things which are wrong with Windows. The underpinnings are a
hobbled mess and rather than make the break, they simply allow things to
be easily broken. How long did it take them to get plug and play even
sort of working? Apple did the correct thing to completely abandon the
OS 9 code base and move ahead to only later give a (very well-written)
method of backwards compatibility. The same should be true of metadata
on the Macintosh. Backwards compatibility can almost always be built in
to the new foundation. The chance to create a new foundation and have
it stick does not come along very often.
Given this, I would like to state that I *fully* support *all* of John
Siracusa's recommendations for metadata. (No, I am not blindly
following the man, it's simply that what he's saying is 90% common sense
and 10% personal preference with which I happen to agree.) I would,
however, like to add my own suggestions and gripes in light of that
horrible document mailed to us entitled: Mac OS X 10.1 File Name
Extension Guidelines.
First, as noted by Siracusa, extensions are *not* necessary on an HFS+
volume. Therefore, ALL NEWLY CREATED FILES SHOULD NOT HAVE AN
EXTENSION! Incoming files, though, should keep the names the same to
ensure that UNIX scripts, etc. are not broken (just like in Mac OS 9).
Now, that means that the Type/Creator codes *must* be set on all new
files. As it stands, the guidelines state that a developer may or may
not set them according to preference. This is ridiculously stupid.
Keep them. It takes about one or two lines of code and it provides a
*much* richer experience. Those who have not had extensive experience
with OS 9 should try the simple joy creating two HTML files. One from
your web browser of the source from the page www.apple.com and the other
from within BBEdit from your own HTML code. Now, when you go to double
click on one of them, each one opens in the CORRECT F#%KING
APPLICATION! Create two HTML files in Mac OS X with two programs that
"didn't feel like setting the type/creator codes" and you get a very
annoying and completely avoidable situation.
Well, now you have all your own files which are devoid of extensions,
can be renamed at will and are bound to the correct application as well
as the files you've downloaded which do have extensions but which *also*
have type/creator codes. Now, you want to send a file to a friend.
This is no problem at all since Apple could easily provide an API to add
an extension to a name just as they have given you a completely
unnecessary one for sanitizing the name to pull the wool over the user's
eyes. Now, there's still a small caveat. When you give those files to
another platform, the names are changed. What if you depend on those
files having the same name on the other platform? Well, you could
prevent them from being changed by asking the user before changing the
names of files about to be sent over a network or you could do something
a bit more tricky. If you know you'll need to access those same files
on the other platform (maybe you're writing a UNIX shell script), you
could quite easily give those files an extension which would then stay
with them, or, if you just plain need a cross-platform solution and have
no idea the history of certain files, simply always specify them with
their path names. That's right, if you created an HTML file on a Mac in
some cross-platform Java application, the application could name it
foo.html. (See Note) The ".html" would be (on the Mac OS) stripped off
so it would become an HTML file called "foo" and when you needed it
again, you would ask for a file named "foo.html". That is, when file
type is specified in the name and no file exactly matches that name, the
filesystem will look for a file of the type specified by the extension
that has the same name sans the extension.
Ok. So, we have are bases covered for when a Macintosh decides to send
or receive files from outside sources. Now, what if outside sources are
requesting files on your machine or you've loaned your hard drive to a
friend and he's reading it with a PC. Let's say your friend needs to
read those cool HTML files you created earlier. He starts looking for
them and finds them but his brain-dead PC program doesn't see that
magical .html on the end of the file and thus won't open them. What to
do? Well, let's see, it's still on an HFS+ volume which means that the
metadata is still there . . . what if the driver was written so as to
provide the .html extension *in the name it returns*? This would solve
everything. Since drivers are absolutely machine/platform dependent, it
shouldn't be too hard to simply append the necessary type data when on a
platform that expects it in the name!
There. Now we have a filesystem which is forward-looking enough to
provide users with the concept of "A file whose name is: and whose type
is:" while not necessarily tying one to the other but still providing
full compatibility with other systems *and* which meets Apple's idiotic
guidelines for specifying an extension. (The extension would be
implicit in some method like: -[NSFileManager createFile:filename
inDirectory:dirID ofType:sometype].) Older programs, especially command
line ones, wouldn't find anything changed. They could still create
files named foo.jpg and foo.html and these extensions would show up.
However, all the more modern applications would use the above
NSFileManager method to create a file which accurately reflects its
contents without mucking up the name and thus returning control to the
user as it should always be.
Please, please, please, someone at Apple take these suggestions
seriously and don't be afraid of doing a little more to keep the
competitive edge.
Brendan Younger
Note: This is not to imply that a user would be unable to specify an
extension if they wanted to. The user should certainly be able to
rename an image file to foo.txt and have the extension stick as well as
the image type. When I said that the application would create a file
foo.html I meant something along the lines of a Save As... dialog in
which the user typed "foo" and the application added the .html. The
system (even though it would be a bit of a hack) could divine that the
user wanted a file named foo. This also covers the application from the
chance that someone renamed the file to simply foo. Even though this
happened, the application could still find the file since the system
would have seen the .html when it was created and put the appropriate
type code in.
P.S. I have referred only to type/creator codes as means of specifying
file type in this letter. I would much rather have a MIME-like encoding
scheme such as the one Mr. Siracusa recommends, so if you feel the same,
feel free to replace every instance of type/creator code with "MIME-like
encoding scheme." It doesn't change anything. - Here's my suggestions, which I sent to Apple:
1) Add support for type/creator codes to Cocoa, and automatically insert
them into the proper methods. For example, the NSDictionary method
writeToFile: could automatically give a type code of DICT unless the
programmer specifies another one.
2) De-emphasize the importance of file name extensions; they're an
option for an application, but not a recommendation.
3) Most importantly: provide an API to map type/creator codes to
filename extensions, and use that API in applications such as Mail or
Fetch that would potentially transfer files to a machine that relies on
filename extensions.
Pretty much everyone seems to agree that filename extensions are for
compatibility purposes only, and that native type/creator codes are a
much better solution to the same problem. Therefore, it seems
reasonable to me that filename extensions should be enforced only when
compatibility is important, such as sending files to other machines,
instead of throughout the entire filesystem.
Just my $.02.
-Peter - At 8:16 PM +0200 9/8/01, Manfred Schubert wrote:> Am Samstag, 8. September 2001 um 18:14 schrieb Ondra Cada:
>
>> Cocoa, naturally. If for no other reason, then since it was designed so by
>> Apple programmers during the join: OpenStep/NeXTStep never had text d&d.
>>
>> Should there be no delay, it would prevent selecting text by dragging
>> starting inside previous selection, that's why.
>
> Are you serious, man? 99% of the time when I make a text selection it is to drag (or copy) it and not to create another one starting from the middle of the old one just for fun. In the 1% of error the Carbon behavior prevents me from *nothing*, I just click once to remove the selection.
> The Cocoa behavior is a real pain in the lower back. Text and proxy icon drag (where 99% of the time I want to drag the window and not the proxy icon). They got it the wrong way around.
>
Not only does one click remove the selection, if it's implemented correctly one click also moves the text cursor where you clicked.
BBEdit and SimpleText implemnt drag+drop text in the most ideal manner. - > 3) Most importantly: provide an API to map type/creator codes to filename extensions, and use that API in applications such as Mail or Fetch that would potentially transfer files to a machine that relies on filename extensions.
>
We already have this, check out Internet Config. - > 3) Most importantly: provide an API to map type/creator codes to
> filename extensions, and use that API in applications such as Mail or
> Fetch that would potentially transfer files to a machine that relies on
> filename extensions.
>
The information to map type/creator codes to extensions does not always
exist, and may be ambiguous. There in no single place where such a mapping
could occur anyway since every application may be dealing with a non-HFS
file system.
The most common way to access files on a non-HFS file system is via the
finder. The second most common way would be via open and save dialogs. I
get the impression that MacOS 9 users never mount network drives, use NFS,
use transparent ftp, have their home account on a server, etc. - If you use a stand alone non-networked Mac then the changes Apple plans will
not effect you at all. They said that the addition and visibility of
extensions would be optional. Just don't do it.
If your home account in on a network server and/or all of your applications
are on a network server then you don't have any choice not to use extensions
and the new system will make life easier. - On Saturday, September 8, 2001, at 11:22 , Ondra Cada wrote:> Jonathan,
>
>>>>>>> Jonathan Hendry (JH) wrote at Sat, 8 Sep 2001 10:38:52 -0500:
> JH> >Will there be any way to turn *that* off? I just tried it and it'd be
> JH> >extremely annoying if I used TextEdit regularly. If I add an
> extension I
> JH> >meant to add it, and appending '.txt' is only going to screw things
> up.
> JH>
> JH> You have the source code.
>
> I guess not. That would be the NSDocument class quite probably, whose
> sources I would just love to have, but don't. You know of some way to get'
> em?
In 10.0.4, at least, TextEdit is not NSDocument-based. It has its
own Document class. - On Saturday, September 8, 2001, at 05:32 , Peter Ammon wrote:>
> Pretty much everyone seems to agree that filename extensions are for
> compatibility purposes only, and that native type/creator codes are a
> much better solution to the same problem. Therefore, it seems reasonable
> to me that filename extensions should be enforced only when compatibility
> is important, such as sending files to other machines, instead of
> throughout the entire filesystem.
This is not viable if Apple ever wants Mac OS X to live happily
on heterogenous corporate networks. (If OS X doesn't keep the
managers of those networks happy, OS X won't be on the networks.)
Having to send files through a conversion airlock on the way in
or out is an anachronistic throwback to the days of ZTerm and
BBSes, and has no place in an operating system that makes
'sending files' transparent: the /Network folder.
In the typical NeXTSTEP installation, users' home directories
were mounted via NFS. Other directories, such as shared applications
and documents, were also mounted via NFS. I would not be surprised
if Apple suggests this as a typical setup if they ever get back
into large corporations like banks. (It's quite nice to be able
to walk to another building a few blocks away and log into your
same account and environment as at your desk.)
In such cases, the files are on your computer in RAM only. There's
no way of knowing what OS the fileserver is running. It could be
a Mac running OS X with HFS+ disks. It could be a Linux box running
NFS. It could be a big high-performance Auspex server. As such,
there is no 'airlock' process where the OS can know that it's
transferring a file to another OS and needs to do the conversion.
That is, there may be no process of "Now I'm copying from the
other OS to Mac OS X. Now I'm working on my local copy. Now
I'm copying from OS X to the other OS and I do the translations." - On Saturday, September 8, 2001, at 06:32 PM, Peter Ammon wrote:> 2) De-emphasize the importance of file name extensions; they're an
> option for an application, but not a recommendation.
>
> 3) Most importantly: provide an API to map type/creator codes to
> filename extensions, and use that API in applications such as Mail or
> Fetch that would potentially transfer files to a machine that relies on
> filename extensions.
Fetch, Mail are just two examples.. then lets look at the raft of
NON UI stuff
cp
ncftp/ftp/ftpd
apache
mv
scp, ssh
perl
virtually ALL of the raft of unix and open source utilities would
be subjected to this.
at that very point, you're back to OS 9 as far as
compatibility/portability goes. - On Sunday, September 9, 2001, at 12:40 AM, Scott Anguish wrote:> On Saturday, September 8, 2001, at 06:32 PM, Peter Ammon wrote:
>
>> 2) De-emphasize the importance of file name extensions; they're an
>> option for an application, but not a recommendation.
>>
>> 3) Most importantly: provide an API to map type/creator codes to
>> filename extensions, and use that API in applications such as Mail or
>> Fetch that would potentially transfer files to a machine that relies on
>> filename extensions.
>
>
> Fetch, Mail are just two examples.. then lets look at the raft of
> NON UI stuff
>
> cp
> ncftp/ftp/ftpd
> apache
> mv
> scp, ssh
> perl
>
> virtually ALL of the raft of unix and open source utilities would
> be subjected to this.
>
> at that very point, you're back to OS 9 as far as
> compatibility/portability goes.
>
If you know how to use those the command line utilities, you can
probably deal with filename extensions on your own.
-Peter - On Saturday, September 8, 2001, at 07:49 PM, Erik M. Buck wrote:> If you use a stand alone non-networked Mac then the changes Apple plans
> will
> not effect you at all. They said that the addition and visibility of
> extensions would be optional. Just don't do it.
It does look good on paper, I admit.> If your home account in on a network server and/or all of your
> applications
> are on a network server then you don't have any choice not to use
> extensions
> and the new system will make life easier.
I suppose all we can do is wait and see how it works. If, indeed, it
works transparently, then that's fantastic. But right now, it seems to
me like a step backwards towards an obsoleted system that everyone else
is trying to get away from.
That said, Apple's solution is quite a bit nicer than Windows' all or
nothing approach to filesystem extension visibility.
-Peter - I am not sure everyone read the guidelines. (Look below for the
paragraphs in question.)
To sum up, the extensions will not magically disappear, they have to
be "Forced" to disappear through some user action. Indeed, renamed a
file that has its extension hidden (lets say a nib) to "SoSexy.nib"
does not make it SoSexy.nib.nib. It just unchecks the hide extension
box.
Also, if you change the name of the hidden file to SoSexy.gas (where
gas is an unknown extension), the file is renamed to SoSexy.gas.nib.
I do see one immediate causality of this behavior, it is not very
difficult for a novie user to change the file name via the get info
window.
---------------------
Files created by Mac OS 9, downloaded from the Internet, or obtained from
some other source always have the hide extension flag unset initially,
regardless of whether or not they have an extension. Therefore, when a user
downloads a file "image.jpg" from the Internet, it does not magically rename
itself to "image" in the Mac OS X Finder. What the user sees stays
consistent. If the user later renames the file to "mygroovyimage", the .jpg
extension is maintained, but becomes hidden. Again, what the user typed
matches what is displayed. In no case will Mac OS X rename an existing file
without the user taking a specific action to rename that file, nor will
renaming a file ever result in accidental multiple extensions (like "
mygroovyimage.jpg.jpg").
Any file with the hide extension flag set and a known extension has that
extension hidden in the Finder. When users edit the name of such a file,
they edit only the user-visible portion. If they explicitly type in a known
file name extension for the file, either the Finder warns them that what
they're doing may change the type of the file (if they enter a different
file name extension), or the Finder changes the state of the hide extension
flag to show the extension (if they enter a new file name with the proper,
currently hidden extension for the file). In all cases, the Finder allows
users to make the changes if they wish. What users see in the Finder is what
they typed when renaming the file, whether or not they included an
extension.
The Finder also allows users to choose to always display file name
extensions, disabling the smart extension hiding behavior that is on by
default. If users want to keep the smart extension hiding on, but need to
know the exact on-disk file name for a given file, they can see it in that
file's Info window in the Finder. Users can also control whether a specific
file's extension is hidden using a checkbox in the Info window.
----------------------
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People - >>>> Will there be any way to turn *that* off? I just tried it and it'd be
>>>> extremely annoying if I used TextEdit regularly. If I add an
>>> extension I
>>>> meant to add it, and appending '.txt' is only going to screw things
>>> up.
>> You have the source code.
> I guess not. That would be the NSDocument class quite probably, whose
> sources I would just love to have, but don't. You know of some way to
> get'em?
TextEdit is not NSDocument based.
However, in order to address the original question --- in the
preferences panel you can turn off auto-appending of "txt" for good, in
which case you will get no any alerts with regards to extensions on
plain text files.
Ali - On Sat, Sep 08, 2001 at 05:25:37PM -0400, Brendan Younger wrote:
:
: I must say that I am rather surprised at the lack of interest (or should
: I say justifiable rage) on a rather important feature of user-interface
: design. It is this lack of interest that is allowing Apple to do *very*
: foolish things in the name of compatibility. (No pun intended.) To
: begin with, I strongly suggest that all who haven't (including any Apple
: Higher-ups) read:
: http://arstechnica.com/reviews/01q3/metadata/metadata-1.html.
I told the author and other folks on Apple's human interface list that
metadata is cute. But if it's not portable, it doesn't exist.
--
Eugene Lee
<eugene...> - On Sunday, September 9, 2001, at 07:11 , Peter Ammon wrote:> On Sunday, September 9, 2001, at 12:40 AM, Scott Anguish wrote:
>
>> cp
>> ncftp/ftp/ftpd
>> apache
>> mv
>> scp, ssh
>> perl
>>
>
> If you know how to use those the command line utilities, you can probably
> deal with filename extensions on your own.
<click> Enable Web Sharing <click>
<click> Enable FTP Access <click>
Those folks really know how to use those command line utilities!
andy
--
Discussion forthcoming. - Ali,>>>>>> Ali Ozer (AO) wrote at Sat, 8 Sep 2001 23:00:33 -0700:AO> >I guess not. That would be the NSDocument class quite probably, whose
AO> >sources I would just love to have, but don't. You know of some way to
AO> >get'em?
AO>
AO> TextEdit is not NSDocument based.
Well, shame on me -- I haven't checked ;) Since it looks like a _VERY_ kind
of application which should use the document system, and since its sources
are available as an example, I guessed it would use it if for no other
reason, then so as newbie programmers see that and do it analogically ;)
Actually, the inertia of all its predecessors up to Edit.app known, is there
any *other* reason why TextEdit should not use the document system?
And more important question, would the document system support the case "any
extension, any type allowed" properly (ie. the same way TextEdit does)?
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - > I'm not talking about default applications for a type. I am saying if you
> make an HTML file in GoLive chances are you are ONLY going to edit it in
> GoLive. If you make a .m file in BBEdit, chances are thats where you are
> going to edit it (and in that case it doesn't matter as PB automatically
> displays files in a project in PB.
I disagree, but I tend to work in a more document-centric way (which is
why OpenDoc interests me, even though I never actually used it). If I
create an HTML file in GoLive, I'm probably going to edit it in everything
from BBEdit Lite to TextEdit to Mail before I'm finished.
I tend to drag files on to application icons in the Dock instead of just
double-clicking them to support this behaviour of mine.
-- Rob
The above message is a figment of your imagination. So is this. - > Having to send files through a conversion airlock on the way in
> or out is an anachronistic throwback to the days of ZTerm and
> BBSes, and has no place in an operating system that makes
> 'sending files' transparent: the /Network folder.
Wait, isn't putting the definition of what type of document I'm dealing with
a throwback to the early years when disk space was expensive and in short
supply, when saving 4 bytes was crucial, when we used .txt to define a text
file and such. Apparently we haven't come very far.> In such cases, the files are on your computer in RAM only. There's
> no way of knowing what OS the fileserver is running. It could be
> a Mac running OS X with HFS+ disks. It could be a Linux box running
> NFS. It could be a big high-performance Auspex server. As such,
> there is no 'airlock' process where the OS can know that it's
> transferring a file to another OS and needs to do the conversion.
Actually, this is untrue. The OS knows what volumes are connected and their
format. The OS is the one reading and writing from the network drive. It
knows what format it is writing to, even if is based on the protocol used.
Truthfully, unless someone stands up and fights against it - we'll have
computers 30 years from now that are 100,000 times faster but still require
us to use .txt to indicate the file is a text document.
Apple has previously support mechanisms that allowed metadata for files to
exist on foreign systems including FAT volumes. Perhaps it was not the most
elegant, but it worked fairly well.
If we continue going with the lowest common denominator for all decisions in
the name of compatibility, what is there that distinguishes Mac OS X?
Virtually nothing, certainly not enough to make it worthwhile to pay any
premium.
Why doesn't NFS support more metadata? If we want to advance the computing
world, let's bring people up to a more advanced system rather than dumb down
an OS in the name of compatibility. Let's stop looking to the past and look
to the future to make things better. Isn't that how we got a GUI-based OS in
the first place?
Mark Munz - On Sunday, September 9, 2001, at 10:13 AM, Mark Munz wrote:> Wait, isn't putting the definition of what type of document I'm dealing
> with
> a throwback to the early years when disk space was expensive and in
> short
> supply, when saving 4 bytes was crucial, when we used .txt to define a
> text
> file and such. Apparently we haven't come very far.
Actually, with file name extensions, I can create an application that
uses .hypertext as an extension under Mac OS X today. With current HFS+
implementation, we're limited to 4 character type codes (HTXT). Which
one is more limiting?
And you're right. We haven't come very far.>> In such cases, the files are on your computer in RAM only. There's
>> no way of knowing what OS the fileserver is running. It could be
>> a Mac running OS X with HFS+ disks. It could be a Linux box running
>> NFS. It could be a big high-performance Auspex server. As such,
>> there is no 'airlock' process where the OS can know that it's
>> transferring a file to another OS and needs to do the conversion.
>
> Actually, this is untrue. The OS knows what volumes are connected and
> their
> format. The OS is the one reading and writing from the network drive. It
> knows what format it is writing to, even if is based on the protocol
> used.
But where do you put this translation layer in so that it doesn't cause
confusion? That perl script is looking for MyGraphic.jpg, but your
Carbon app thinks it's looking for MyGraphic. What if a Carbon app calls
a POSIX routine and passes it a file name? What about users that use
both the GUI and the CLI?> Truthfully, unless someone stands up and fights against it - we'll have
> computers 30 years from now that are 100,000 times faster but still
> require
> us to use .txt to indicate the file is a text document.
True. But the fight has to first be about the way we store data in
filesystems, then about type/creator. Without a major change in the way
use use filesystems, there's no point in debating type/creator.
Type/creator right now is just a hack that limits Mac OS (while
providing some nice features to a small number of people). Right now, we
have a 4 character limit file extension hidden away from the user called
a type. Then we have this creator code that just wreaks havoc on those
of us connected to shared file systems... like most of the computers on
corporate networks and comprise most of the computer market.
Just try sharing the same files on Mac OS X Server between MS-Windows,
Mac OS X, and UNIX clients. Of course, keep in mind that the Mac
currently has roughly 5% marketshare.> If we continue going with the lowest common denominator for all
> decisions in
> the name of compatibility, what is there that distinguishes Mac OS X?
Ah, but it's a matter of choosing which battles to fight. Which battles
for which Apple has the resources and the technology to implement
without sacrificing too much of the potential market. Certainly Quartz
isn't lowest common denominator. Types/creator as implemented in the
current system isn't worth it. It's not that much better than file
extensions that we should sacrifice Mac OS X's place in the corporate
computing landscape.
Now, an object soup database instead of a filesystem might be worth it
to sacrifice interoperability. Of course, we're not going there anytime
soon.> Why doesn't NFS support more metadata? If we want to advance the
> computing
> world, let's bring people up to a more advanced system rather than dumb
> down
> an OS in the name of compatibility. Let's stop looking to the past and
> look
> to the future to make things better.
You look at this as dumbing down Mac OS X. I see it as fixing Mac OS X.
I think type/creator as currently implemented is broken - it's fine if
you don't want to interact with anyone else, but it sucks otherwise. But
we're not building an platform for 1985. It's not dumbing down Mac OS
X, but rather liberating it. We can then seriously consider integrating
newer filesystem technologies, like xfs, jfs, ext3, afs, coda, etc.
..Bill Chin
M Dimension Technology - On Sunday, September 9, 2001, at 12:17 PM, Bill Chin wrote:> On Sunday, September 9, 2001, at 10:13 AM, Mark Munz wrote:
>
>> Wait, isn't putting the definition of what type of document I'm
>> dealing with
>> a throwback to the early years when disk space was expensive and in
>> short
>> supply, when saving 4 bytes was crucial, when we used .txt to define a
>> text
>> file and such. Apparently we haven't come very far.
>
> Actually, with file name extensions, I can create an application that
> uses .hypertext as an extension under Mac OS X today. With current HFS+
> implementation, we're limited to 4 character type codes (HTXT). Which
> one is more limiting?
>
> And you're right. We haven't come very far.
The fact that it is a four "character" code does not in *any* way limit
it. It's implemented as a long int and can thus have up to 4294967295
possible values. That is far more than will ever be needed. Also, the
fact that it is completely hidden from the user and only its
manifestation is presented is a point for it over file extensions. (No
one actually cares whether it's hTXT or HTXT or HTEX, a program that
wants to know it's type just looks for the appropriate code. No
aesthetic judgement is necessary.) In addition, the fact is that
type/creator codes carry twice the information and thus have the number
of options provided by extensions squared. The naive idea that all .rtf
files should be opened in the same application should not be tolerated
when there is a very workable alternative.
Brendan Younger - >> AO> TextEdit is not NSDocument based.
> Well, shame on me -- I haven't checked ;) Since it looks like a _VERY_
> kind
> of application which should use the document system, and since its
> sources
> are available as an example, I guessed it would use it if for no other
> reason, then so as newbie programmers see that and do it analogically ;)
Actually shame on us --- TextEdit should be NSDocument based indeed, but
it just didn't make it in. In the meantime, in case someone needs it,
it serves as an example of how to get all the tedious stuff done that
NSDocument would normally do for you. (Exchanging files, putting stuff
in recents menus, dealing with hidden extensions...)> And more important question, would the document system support the case
> "any
> extension, any type allowed" properly (ie. the same way TextEdit does)?
I believe so.
Ali - per the article...
"As you have no doubt guessed, I am one of the Mac users that thinks no
Mac application should ever force the user to save a file with a file
name extension. If the file type information stored in the 32-bit type
code is sufficient for my Mac to determine a file's type, why should I
be forced to pollute my file names with a fragile, redundant copy of
that same information? Doing so eliminates one of biggest user
experience advantages of using a Mac."
I agree with the author that storing metadata and interpreting it (re:
application binding) are different issues. What seems to bother people
is not what is stored, but where it is stored and how it is used. The
author acknowledges that file type is non-essential. That is, you can
still read and write the data without it. That said, file type is more
convenience than anything. It allows the OS a convenient way to help
users find and load programs and files. I find file extensions to be a
*very* convenient place to store this information. I can control it, I
can change, I can see instantly what type of file it is. Does it really
matter that much where the information is stored? I think that avoiding
file extensions (as suggested in the quote above) is a big user
experience DISadvantage of using a Mac.
Incidentally, I prefer to control my own application binding. I don't
really care what application was used to create a file on someone else's
computer. For example, I want all .txt files to open in TextEdit,
period, unless I choose otherwise. Also, I want to see all document
extensions, all the time. I don't need to to see .app or other bundle
extensions, since I have no need to edit them.
Basically, the issue comes down to interoperability with the rest of the
computing world. Perhaps a better solution to the problem is to create a
robust mechanism for different platforms to exchange metadata (maybe all
files should be XML?). Using MIME types might be fine to describe a
file's type, but that doesn't change the fact that platforms exchange
little more than file name and size information when transferring files.
XML would allow all the metadata you want, but bears a cost in
performance (the OS would have to look inside the file for the metadata).
The bottom line is this. Apple made a good "business" decision to
support file extensions. It makes the Mac more acceptable in a
heterogeneous and increasing networked world. The Mac community should
embrace it, if for no other reason than to sell more Macs.
Michael
On Saturday, September 8, 2001, at 04:25 PM, Brendan Younger wrote:> I must say that I am rather surprised at the lack of interest (or
> should I say justifiable rage) on a rather important feature of
> user-interface design. It is this lack of interest that is allowing
> Apple to do *very* foolish things in the name of compatibility. (No
> pun intended.) To begin with, I strongly suggest that all who haven't
> (including any Apple Higher-ups) read:
> http://arstechnica.com/reviews/01q3/metadata/metadata-1.html. - On Sunday, September 9, 2001, at 03:43 AM, Eugene Lee wrote:> On Sat, Sep 08, 2001 at 05:25:37PM -0400, Brendan Younger wrote:
> :
> : I must say that I am rather surprised at the lack of interest (or
> should
> : I say justifiable rage) on a rather important feature of
> user-interface
> : design. It is this lack of interest that is allowing Apple to do
> *very*
> : foolish things in the name of compatibility. (No pun intended.) To
> : begin with, I strongly suggest that all who haven't (including any
> Apple
> : Higher-ups) read:
> : http://arstechnica.com/reviews/01q3/metadata/metadata-1.html.
>
> I told the author and other folks on Apple's human interface list that
> metadata is cute. But if it's not portable, it doesn't exist.
I think the issue is more of legacy systems vs. new/improved systems.
99.9% of all my user design decisions are based on "What would my wife
do?" (or WWMWD). This sounds flippant, but you have to understand that
she is not a tech-head. She could care less if the file had ".pdf" on
the end or ".portabledocumentformat" (although the latter she would, no
doubt, complain it took up too much screen space). She just want's the
document to open when she needs it. Metadata smedata, if it don't work
like she expects it is crap.
You would be surprised at the amount of crap out there. <grin>
So if she gets a document labeled .html or .mp3 she doesn't want to
figure out what it is supposed to go to, she wants it to just work. This
is what I call USER in the UI. And I think this is what Apple is
attempting to do. I DON'T think they are trying to say "hey, we're
putting a lock on file extensions and tough nuggies if you don't like
it". They are trying to make file sharing EASIER.
The question I have to ask is, do we in fact lose functionality? If the
answer is no, then I have to argue that there is a lot being made that
all signifies nothing. If in fact we DO lose functionality, then I have
grave concerns.
When I move her over to OS X if she starts complaining that things
"don't work like I expect them to work", then Apple will have made a
grave error.
Cheers,
Lloyd
-----
Canna Software Development
"while (!dead) [self beat_horse];" anon - On Sunday, September 9, 2001, at 09:13 , Mark Munz wrote:>> Having to send files through a conversion airlock on the way in
>> or out is an anachronistic throwback to the days of ZTerm and
>> BBSes, and has no place in an operating system that makes
>> 'sending files' transparent: the /Network folder.
>
> Wait, isn't putting the definition of what type of document I'm dealing
> with
> a throwback to the early years when disk space was expensive and in short
> supply, when saving 4 bytes was crucial, when we used .txt to define a
> text
> file and such. Apparently we haven't come very far.
Ah, but now we can use extensions like .MDDesktopConfig, or .ooutline,
which beat the heck out of .txt or 4-byte codes.
Besides, the type is, undeniably, useful information. I find it reasonable
to put it where it's readily available.>
>> In such cases, the files are on your computer in RAM only. There's
>> no way of knowing what OS the fileserver is running. It could be
>> a Mac running OS X with HFS+ disks. It could be a Linux box running
>> NFS. It could be a big high-performance Auspex server. As such,
>> there is no 'airlock' process where the OS can know that it's
>> transferring a file to another OS and needs to do the conversion.
>
> Actually, this is untrue. The OS knows what volumes are connected and
> their
> format. The OS is the one reading and writing from the network drive. It
> knows what format it is writing to, even if is based on the protocol used.
Not necessarily true at all.>
> Truthfully, unless someone stands up and fights against it - we'll have
> computers 30 years from now that are 100,000 times faster but still
> require
> us to use .txt to indicate the file is a text document.
Well, frankly, that's not a bad thing, because the information is
mostly there for _human_ consumption, because it _is useful information_.>
> Apple has previously support mechanisms that allowed metadata for files to
> exist on foreign systems including FAT volumes. Perhaps it was not the
> most
> elegant, but it worked fairly well.
Airlocks.>
> If we continue going with the lowest common denominator for all decisions
> in
> the name of compatibility, what is there that distinguishes Mac OS X?
> Virtually nothing, certainly not enough to make it worthwhile to pay any
> premium.
A nice slippery-slope argument, but not exactly valid. If all
that distinguishes Mac OS is its filesystem metadata, then
Apple is surely doomed.
If OS X willfully refuses to play well with other systems, it
won't be invited to play. - On Sunday, September 9, 2001, at 10:49 AM, Brendan Younger wrote:> On Sunday, September 9, 2001, at 12:17 PM, Bill Chin wrote:
>
>> On Sunday, September 9, 2001, at 10:13 AM, Mark Munz wrote:
>>
>>> Wait, isn't putting the definition of what type of document I'm
>>> dealing with
>>> a throwback to the early years when disk space was expensive and in
>>> short
>>> supply, when saving 4 bytes was crucial, when we used .txt to define
>>> a text
>>> file and such. Apparently we haven't come very far.
>>
>> Actually, with file name extensions, I can create an application that
>> uses .hypertext as an extension under Mac OS X today. With current
>> HFS+ implementation, we're limited to 4 character type codes (HTXT).
>> Which one is more limiting?
>>
>> And you're right. We haven't come very far.
>
> The fact that it is a four "character" code does not in *any* way limit
> it.
Of course it does. It's supposed to be a menemonic (for the programmer
at least), and the fact that I *could* use "67&h" for my type and "!@g1"
for my creator code doesn't help when I have a conflict with someone
else's use of a nice, memorable four-letter type like "TEXT".
-jcr
"The problem with trying to child-proof the world, is that it makes
people neglect the far more important task of world-proofing the
child." -- Hugh Daniel - At 2:29 PM -0500 9/9/01, Jonathan Hendry wrote:
...> Besides, the type is, undeniably, useful information. I find it reasonable
> to put it where it's readily available.
...>> Truthfully, unless someone stands up and fights against it - we'll have
>> computers 30 years from now that are 100,000 times faster but still require
>> us to use .txt to indicate the file is a text document.
>
> Well, frankly, that's not a bad thing, because the information is
> mostly there for _human_ consumption, because it _is useful information_.
But I can use _exactly_ the same arguments to support embedding
creation date, last modified date, or even file size in the file name!
Come on you guys! I bet that at least some of you have computer
science degrees (this is a programming forum, after all). Didn't you
study normalised forms? First normal form (1NF): "Each attribute
represents an atomic value (nondecomposible attributes)." [Object
Oriented Design, Grady Booch, 1991, p372].
And this is quite apart from the absurd _human_ issues of embedding
application lookup data in a user readable field. For example, if I
change a file from abc.jpg to abc.txt, what will happen? How do I
even know what application will attempt (and fail) to open this file?> If OS X willfully refuses to play well with other systems, it
> won't be invited to play.
Since when was schoolyard peer pressure ever an argument for anything
beyond the length of your shorts?
Karl
--
----
Klaatu barada nikto - > Date: Sun, 9 Sep 2001 13:47:04 -0700
> Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
> Cc: Bill Chin <bchin...> , <cocoa-dev...>
> To: Brendan Younger <bcy4...>
> From: "John C. Randolph" <jcr...>
>
> On Sunday, September 9, 2001, at 10:49 AM, Brendan Younger wrote:
>
>> On Sunday, September 9, 2001, at 12:17 PM, Bill Chin wrote:
>>
>>> On Sunday, September 9, 2001, at 10:13 AM, Mark Munz wrote:
>>>
>>>> Wait, isn't putting the definition of what type of document I'm
>>>> dealing with
>>>> a throwback to the early years when disk space was expensive and in
>>>> short
>>>> supply, when saving 4 bytes was crucial, when we used .txt to define
>>>> a text
>>>> file and such. Apparently we haven't come very far.
>>>
>>> Actually, with file name extensions, I can create an application that
>>> uses .hypertext as an extension under Mac OS X today. With current
>>> HFS+ implementation, we're limited to 4 character type codes (HTXT).
>>> Which one is more limiting?
>>>
>>> And you're right. We haven't come very far.
>>
>> The fact that it is a four "character" code does not in *any* way limit
>> it.
>
> Of course it does. It's supposed to be a menemonic
no, it's not (as far as I know). Four character codes are used in
Mac APIs for a great variety things besides file types and these APIs
go to great lengths (using "#define, enum statements and other
language mechanisms) to supply (i.e. "expose" as part of the API)
semantically meaningful symbols that represent four letter codes
which are often obscure. For intance, in the CarbonEvents.h, a
number of enum constants of the form kEventParam* are defined which
represent four letter codes. For many of these codes, seeing the
code used raw in a program would make for very obscure source because
there's often very little semantic info that can be packed into four
letters. The defined enum constants, on the other hand, are very
semantically rich. Also, In all the sample code I've seen in
documentation for Mac APIs, four letter codes are given semantically
rich representations which are in turn used in every instance where
the codes are needed. I've even seen this trick applied to file type
four letter codes in sample code for document manipulating
applications.> (for the programmer at least), and the fact that I *could* use
> "67&h" for my type and "!@g1"
> for my creator code doesn't help when I have a conflict with someone
> else's use of a nice, memorable four-letter type like "TEXT".
Neal. - On Sunday, September 9, 2001, at 01:49 PM, Brendan Younger wrote:>
> On Sunday, September 9, 2001, at 12:17 PM, Bill Chin wrote:
>
>> On Sunday, September 9, 2001, at 10:13 AM, Mark Munz wrote:
>>
>>> Wait, isn't putting the definition of what type of document I'm
>>> dealing with
>>> a throwback to the early years when disk space was expensive and in
>>> short
>>> supply, when saving 4 bytes was crucial, when we used .txt to define
>>> a text
>>> file and such. Apparently we haven't come very far.
>>
>> Actually, with file name extensions, I can create an application that
>> uses .hypertext as an extension under Mac OS X today. With current
>> HFS+ implementation, we're limited to 4 character type codes (HTXT).
>> Which one is more limiting?
>>
> The fact that it is a four "character" code does not in *any* way limit
> it. It's implemented as a long int and can thus have up to 4294967295
> possible values. That is far more than will ever be needed.
Hmmm. Mark Munz was talking about saving disk space, "when saving 4
bytes was crucial" and that somehow file extensions was related to that.
My point is that file extensions, as implemented today, have a larger
potential namespace than the 4 character type codes, so disk space isn't
the issue. Of course, a 32 bit unsigned int does have a limit - you
stated it.> Also, the fact that it is completely hidden from the user and only
> its manifestation is presented is a point for it over file extensions.
> (No one actually cares whether it's hTXT or HTXT or HTEX, a program
> that wants to know it's type just looks for the appropriate code. No
> aesthetic judgement is necessary.)
Ah, yeah. Of course, when you actually have to change it, you have to
remember the right number out of 4294967295 possible values, or worse,
picking the right one out of a list that scrolls forever. This
effectively makes the number of really useful values much lower. Unless
you want to be the developer that ships an application where users have
to change the type of a document to "@!(>" for the system to recognize
it properly.
..Bill Chin
M Dimension Technology - > Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
> Cc: <cocoa-dev...>
> To: Brendan Younger <bcy4...>
> From: Bill Chin <bchin...>
>
> On Sunday, September 9, 2001, at 01:49 PM, Brendan Younger wrote:
>
>>
>> On Sunday, September 9, 2001, at 12:17 PM, Bill Chin wrote:
>>
>>> On Sunday, September 9, 2001, at 10:13 AM, Mark Munz wrote:
>>>
>>>> Wait, isn't putting the definition of what type of document I'm
>>>> dealing with
>>>> a throwback to the early years when disk space was expensive and in
>>>> short
>>>> supply, when saving 4 bytes was crucial, when we used .txt to define
>>>> a text
>>>> file and such. Apparently we haven't come very far.
>>>
>>> Actually, with file name extensions, I can create an application that
>>> uses .hypertext as an extension under Mac OS X today. With current
>>> HFS+ implementation, we're limited to 4 character type codes (HTXT).
>>> Which one is more limiting?
>>>
>> The fact that it is a four "character" code does not in *any* way limit
>> it. It's implemented as a long int and can thus have up to 4294967295
>> possible values. That is far more than will ever be needed.
>
> Hmmm. Mark Munz was talking about saving disk space, "when saving 4
> bytes was crucial" and that somehow file extensions was related to that.
> My point is that file extensions, as implemented today, have a larger
> potential namespace than the 4 character type codes, so disk space isn't
> the issue. Of course, a 32 bit unsigned int does have a limit - you
> stated it.
>
>> Also, the fact that it is completely hidden from the user and only
>> its manifestation is presented is a point for it over file extensions.
>> (No one actually cares whether it's hTXT or HTXT or HTEX, a program
>> that wants to know it's type just looks for the appropriate code. No
>> aesthetic judgement is necessary.)
>
> Ah, yeah. Of course, when you actually have to change it, you have to
> remember the right number out of 4294967295 possible values, or worse,
> picking the right one out of a list that scrolls forever. This
> effectively makes the number of really useful values much lower. Unless
> you want to be the developer that ships an application where users have
> to change the type of a document to "@!(> " for the system to recognize
> it properly.
In the Mac OS user experience, the average user never has to change
the code, or even see it, so they never have to remember it. In any
situation where they are offered an option to change the type of a
file by some application or utility, the Mac standard is that the
user is only offered human-readable options (which application
associates with file type codes behind the scenes where the user
never sees it.)
Neal. - On Sunday, September 9, 2001, at 09:21 PM, Neal A. Crocker wrote:>> Date: Sun, 9 Sep 2001 13:47:04 -0700
>> Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
>> Cc: Bill Chin <bchin...>, <cocoa-dev...>
>> To: Brendan Younger <bcy4...>
>> From: "John C. Randolph" <jcr...>
>>
>> On Sunday, September 9, 2001, at 10:49 AM, Brendan Younger wrote:
>>
>>> The fact that it is a four "character" code does not in *any* way
>> limit
>>> it.
>>
>> Of course it does. It's supposed to be a menemonic
>
> no, it's not (as far as I know).
Yes it is. (Keep in mind, I started coding for the Mac in 1984, and the
first edition of Inside Mac was quite clear that you should pick your
type and creator codes to make it obvious to a human being what they
indicated. "PICT" and "MPNT" for a picture file made by MacPaint were
given as examples.)> Four character codes are used in Mac APIs for a great variety things
> besides file types and these APIs go to great lengths (using "#define,
> enum statements and other language mechanisms) to supply (i.e. "expose"
> as part of the API) semantically meaningful symbols that represent four
> letter codes which are often obscure.
Those are not the type and creator codes.
-jcr
"The Digital Millenium Copyright Act is the latest legislative proof of
the Peter Principle." - On Monday, September 10, 2001, at 12:10 AM, Neal A. Crocker wrote:
[re: type and creator codes]> In the Mac OS user experience, the average user never has to change the
> code, or even see it, so they never have to remember it.
In two words: Dream On. I lost count of the times that this was proven
false by the end of 1984!
-jcr
For every complex problem there is an answer that is clear, simple, and
wrong. -- H L Mencken - On Monday, September 10, 2001, at 09:38 , John C. Randolph wrote:> On Monday, September 10, 2001, at 12:10 AM, Neal A. Crocker wrote:
> [re: type and creator codes]
>
>> In the Mac OS user experience, the average user never has to change the
>> code, or even see it, so they never have to remember it.
>
> In two words: Dream On. I lost count of the times that this was proven
> false by the end of 1984!
That's because the Finder didn't support changing them. It's now possible
in Mac OS X.
andy
--
Description forthcoming. - On Monday, September 10, 2001, at 02:38 AM, John C. Randolph wrote:> On Monday, September 10, 2001, at 12:10 AM, Neal A. Crocker wrote:
> [re: type and creator codes]
>
>> In the Mac OS user experience, the average user never has to change
>> the code, or even see it, so they never have to remember it.
>
> In two words: Dream On. I lost count of the times that this was
> proven false by the end of 1984!
Applying the simple "WWMWD" (What Would My Wife Do), she has NEVER
changed a code since she has used a Mac. She is about as average a user
as you can get (nor would she know what they were if I said "hey, what
ar type and creator codes?").
This is the problem with developers: they get their heads in a box.
Sometimes it helps to ask a non-developer "hey, what do you think of
this interface" or "hey, is this obvious". When they say "you have your
head up your A**", then perhaps you need to rethink it <grin>. Okay, MY
non-developer is a little harsh sometimes, but she DOES have valid
points.
I'll have to ask my brothers, they do art (i.e Photoshop, etc.) and see
what they say about type and creator codes. My suspicion is that they
have no clue...
Cheers,
Lloyd
--------
Canna Software Development
"No llamas were caught teaching Picasso or involved in the creation of
this e-mail." - On Monday, September 10, 2001, at 05:13 PM, j o a r wrote:> We have to live with it, since we're a minority, but we don't have to
> be contend with it - and should strive to find something better, not
> only for the Macintosh community, but for every computer user. Reading
> this thread makes me wonder if you belive that communication between
> camps are impossible? There is a difference between business and war
> after all...
Perhaps the only difference is:
a) mailing lists
b) nobody dies (cough, cough)
Cheers,
Lloyd
-----
Canna Software Development
"while (!dead) [self beat_horse];" anon - > Actually, with file name extensions, I can create an application that uses .hypertext as an extension under Mac OS X today. With current HFS+ implementation, we're limited to 4 character type codes (HTXT). Which one is more limiting?
Because the 4 char code isn't supposed to be visible (that's what the Kind is for!) you're limited to 4 billion types.
Damn, and I needed 5 billion. - > But I can use _exactly_ the same arguments to support embedding creation date, last modified date, or even file size in the file name!
>
That's EXACTLY what DOS and UNIX people do! UNIX filesystems don't have creation date, so you end up with files like 010910fm.doc - Paul,
I should not join this debate again... should not... SHOULD NOT... well...>>>>>> Paul Bayley (PB) wrote at Mon, 10 Sep 2001 13:03:54 -0700:PB> >Actually, with file name extensions, I can create an application that
PB> >uses .hypertext as an extension under Mac OS X today. With current HFS+
PB> >implementation, we're limited to 4 character type codes (HTXT). Which
PB> >one is more limiting?
PB>
PB> Because the 4 char code isn't supposed to be visible (that's what the
PB> Kind is for!) you're limited to 4 billion types.
Actually, speaking of _limitations_, type codes as currently implemented in
OSX are provably the thing which is less flexible. The number of codes is
quite unimportant; the difference is that extensions can express hiearachical
typing (and, albeit in a limited way, actually do). Type codes can't.
A particular example might be .tar.gz. It is more than just .gz; it brings
not just the information "this can be decoded by gzip" as any other .gz file,
but *also* it informs "it can be decoded by gnutar -z".
Another example is the subtyping of backup files (like .rtf and .rtf~, or
.nib and .nib~, or, actually, .whatever and .whatever~).
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - On Sunday, September 9, 2001, at 12:29 , Jonathan Hendry wrote:> Ah, but now we can use extensions like .MDDesktopConfig, or .ooutline,
> which beat the heck out of .txt or 4-byte codes.
> Besides, the type is, undeniably, useful information. I find it
> reasonable
> to put it where it's readily available.
But the type is readily available already. In list view of the Finder
you have the type column - ie. "Adobe Photoshop 6.0 document", and in
icon view you have the icon...
The difference is that in a system based on rich meta data instead of
file name extensions, the system can display so much more, and more
correct, information in the type column then would be practically
possible in an extensions based system.
On Sunday, September 9, 2001, at 09:17 , Bill Chin wrote:>> Wait, isn't putting the definition of what type of document I'm
>> dealing with
>> a throwback to the early years when disk space was expensive and in
>> short
>> supply, when saving 4 bytes was crucial, when we used .txt to define a
>> text
>> file and such. Apparently we haven't come very far.
> Actually, with file name extensions, I can create an application that
> uses .hypertext as an extension under Mac OS X today. With current HFS+
> implementation, we're limited to 4 character type codes (HTXT). Which
> one is more limiting?
> And you're right. We haven't come very far.
But you are completely missing the point here. The four character
type/creator (T/C) code is - as the people on this list who likes math
have already proven - plenty enough to encode all our document types for
ages and ages to come. The point is that this code isn't intended for
human consumption, mnemonics aside. What makes T/C so much superior is
the power of _abstraction_!
If you were creating a table of users in a database, would you use
peoples names as the key to the table? No, you would use a separate ID
because it gives you so much more freedom and power later on.
Because of the abstraction available in the T/C system we can display
the type of documents like "Microsoft Word 2001 document". If we were
using file name extensions alone, we would only know that it was a
"Microsoft Word document" - see the difference? How many versions of the
".doc", ".psd", ".gif", et.c. formats are in reality out there? Since
they are all typed using the same extension, the extension gets next to
useless - not for Microsoft of course since this ensures that the only
foolproof way to know that you can open a ".doc" document is to own the
very latest version of Word...
A system with no abstraction between the data that developers use and
end users see is stupid beyond comprehension.
We have to live with it, since we're a minority, but we don't have to be
contend with it - and should strive to find something better, not only
for the Macintosh community, but for every computer user. Reading this
thread makes me wonder if you belive that communication between camps
are impossible? There is a difference between business and war after
all...
j o a r - On Tuesday, September 11, 2001, at 02:14 AM, j o a r wrote:> On Monday, September 10, 2001, at 02:21 , Ondra Cada wrote:
>
>> A particular example might be .tar.gz. It is more than just .gz; it
>> brings
>> not just the information "this can be decoded by gzip" as any other
>> .gz file,
>> but *also* it informs "it can be decoded by gnutar -z".
>
> Why not be even more explicit while we're at it:
>
> MyDocument.html.txt.tar.gz
>
> Woho, types through file name extensions! The type is longer then the
> file name! Don't forget to tell your mom that she can use long file
> names, up to 255 characters, _provided_ that she uses the right file
> type. Otherwise she'll need to remember to truncate the file name by
> the length of the file name extension - got that mom?
>
> On the other hand, if we* _accept_ that it's OK to use file system meta
> data, we could easily add any number of extra tags - besides or instead
> of T/C - for hierarchial types or whatever we think is reasonable. Why
> not have a "backed up" flag as well? Or perhaps shoot for a general
> purpose extensible xml field for whatever we might think of later?
>
> *) hopefully "we" could be some standards organization with members
> from the rest of the industry.
I prefer this embedding of meta-data over trying to explain to my wife
what MyDocument.html.txt.tar.gz is (or how to use it!).
Just my 2 cents...
Cheers,
Lloyd
--------
Canna Software Development
"No llamas used metadata or resorted to outlandishly long filenames in
the creation of this e-mail." - First, the following is purely my opinion. I don't speak for Apple, or
anyone else for that matter. I'll try to avoid sticking IMHO's
everywhere to avoid clutter, but insert them freely as you wish.
This will ramble a bit, but what the Hell...
Every time this discussion of filename extensions versus
type/creator/etc. comes up, I feel like I'm watching people flame each
other over who's 15-20 year old solution sucks less, and no one tries to
actually propose anything better, which is probably why the discussion
never moves forward.
Honestly, I do think both "solutions" suck, and for different reasons.
Filename extensions suck because they shouldn't be necessary at all, and
type/creator suck for similar reasons, but additionally because of
multi-user issues. I go into more specifics in a bit.
First let's talk about file types only. The fundamental flaw with both
of the current schemes is that they are just plain wrong. A file's
type is ultimately determined by it's contents. A JPEG file is a JPEG
file regardless of what extension you put on it, or what kind of
meta-data you try to attach to it. Any system in which an application
is present that can load JPEG files can't do it (or refuses to do it)
just because it's named incorrectly or has the wrong meta-data attached
is flawed.
For probably the vast majority of file formats out there, you could
probably write some code to determine what kind of file it was with a
lot of accuracy, and you could certainly do it 100% for any new kinds of
file formats. Things like Targa files, which don't have any useful
identifiers in them, are problematic but oh well.
Given this fact, why not propose a system whereby the OS is actually
able to interrogate files as to what they are in order to assist with
decisions about what applications can actually handle the file?
What I'm thinking of is that application bundles could have an
additional CFPlugIn included that could be loaded by the Finder (or
whatever). These plugins would communicate with their loader via a
filesystem-like interface that would let them sniff at the bits of the
file, and would also be able to provide information back to the Finder
about what they think the file is (perhaps via MIME types), as well as
whether or not their parent application can load them or not, and what
kind of confidence level they have in their identification.
Now, someone is going to immediately pipe up and say "but that would be
too slow!". Maybe, maybe not. The main case where performance would
probably be the most critical is when figuring out what icon to use for
a file or in a file dialog that's trying to filter out files, but
perhaps something creative could be done here (suggestions are welcome).
I'm double-clicking the file anyway, it's not going to matter if the OS
did some extra pre-reads on the file since the opening app will probably
read the same data anyway, and then the data would already be in the
filesystem cache.
My take an this is that I have a machine would orders of magnitude
better performance than anything from the 1980-1985 timeframe that I'm
willing to spend some of that performance for a better user experience.
A modern Mac can probably read a significant portion of a file in less
time than it takes a circa-1980's PC to spin up a floppy drive.
The other issue at hand is answering the question of "which application
should a file be opened with, all other things being equal?". This is a
tough one, but whatever the solution is, it really needs to be
multi-user. My choice would be to simply have a few layers of choice
here. The first level would be a global setting that says all JPEG
files should be open in one particular app unless I override it. It
might even be nice to be able to change this behaviour for different
locations in a filesystem. The Finder-like entity could also track on
a per-file basis what the user's preferred application is, but it
doesn't need to do this along with the file itself if there is some way
to uniquely identify the file even if it moves. The reason for not
keeping it with the file is that the information may get lost in the
transfer anyway, and it's not always going to be useful if transferred
to a different machine, anyway. The other reason is that you may not
have write-access to the file or even the filesystem the file is stored
on.
Anyway, that's my $0.02 on the matter. I just want a system that
doesn't get as easily confused as the current schemes do. I don't want
to need some stupid third party app to fix type/creator codes when they
go wrong, and I don't want to have to rename files to make things work
right, either. This kind of stuff should Just Work(TM), and there's no
excuse IMHO for it not to.
P.S... One additional data point: My home directory here at home is
mounted via NFS to a NetBSD machine over 100mbit ethernet, and has 419
files in it. After a clean reboot and log in, doing "time file *> /dev/null" took 0.190 seconds of user time, 0.100s of system time and3.88 seconds total. Presumably that was doing a lot more work than
you'd normally need for a directory scan, which in the case of Finder
could be a lot lazier.
-Ken
Kenneth Dyke, <kcd...> (personal), <kdyke...> (work)
Sr. Mad Scientist, MacOS X OpenGL Group, Apple Computer, Inc.
C++ is to C as Lung Cancer is to Lung - On Monday, September 10, 2001, at 10:07 PM, Kenneth C. Dyke wrote:
[a very thought-provoking discussion of file metadata]
Back in the days of NeXTSTEP, I often said that the single biggest wart
in NeXT's design was that there still were programs and files, as
opposed to objects. Within each app we have objects, and they act in
various ways, but at the top level of the system we're still essentially
working procedurally.
In Perl, there are only three kinds of variables: scalars, linear
arrays, and associative arrays (dictionaries). Each of these presents
different data depending on context.
On this list and elsewhere, I've described the idea of an image which
could be a jpeg if you looked at it that way, or a .gif if you looked at
it another way. Suppose it could also be an infinite-length quicktime
movie, or an array of RGB values, all again depending on how we look at
it.
What I'd like to see the Mac (or it's successor's) user experience move
towards, is one where users really *don't* have to know or care about
the metadata (which is what type and creator codes were trying, but
*failed* to achieve.)
What if we didn't need TextEdit.app, because simply loading an NSText
object into memory would suffice? (Every object its own app, using or
not using the framework code as appropriate?)
Does Apple have a blue-sky R&D department anymore? Yes, I know about
Crandall's work on crypto and wavelets and so forth, but is there a
project to invent the system which is as much of a leap beyond NeXTSTEP
as NeXTSTEP was beyond DOS?
-jcr
Support your right to protest a criminal nut-cult.
http://freehenson.da.ru/ - On Monday, September 10, 2001, at 02:21 , Ondra Cada wrote:> A particular example might be .tar.gz. It is more than just .gz; it
> brings
> not just the information "this can be decoded by gzip" as any other .gz
> file,
> but *also* it informs "it can be decoded by gnutar -z".
Why not be even more explicit while we're at it:
MyDocument.html.txt.tar.gz
Woho, types through file name extensions! The type is longer then the
file name! Don't forget to tell your mom that she can use long file
names, up to 255 characters, _provided_ that she uses the right file
type. Otherwise she'll need to remember to truncate the file name by the
length of the file name extension - got that mom?
On the other hand, if we* _accept_ that it's OK to use file system meta
data, we could easily add any number of extra tags - besides or instead
of T/C - for hierarchial types or whatever we think is reasonable. Why
not have a "backed up" flag as well? Or perhaps shoot for a general
purpose extensible xml field for whatever we might think of later?
*) hopefully "we" could be some standards organization with members from
the rest of the industry.> Another example is the subtyping of backup files (like .rtf and .rtf~,
> or
> .nib and .nib~, or, actually, .whatever and .whatever~).
What's wrong with:
MyDocument
MyDocument backup file
The backup file isn't really of a different _type_, now is it?
BTW. What do you say we take this thread to macosx-talk instead Ondra?
Parts of it is there already.
Regards,
j o a r - John,>>>>>> John C. Randolph (JCR) wrote at Mon, 10 Sep 2001 23:26:26 -0700:JCR> Within each app we have objects, and they act in
JCR> various ways, but at the top level of the system we're still essentially
JCR> working procedurally.
...
JCR> What if we didn't need TextEdit.app, because simply loading an NSText
JCR> object into memory would suffice? (Every object its own app, using or
JCR> not using the framework code as appropriate?)
Don't want to sound like a spoilsport, but I guess when such a design is
finished, it would became obvious that they just reinvented SmallTalk ;)
Incidentally, correct me please if I am wrong, but unless there was some
re-definition of terms lately, I guess we *are* working procedurally in ObjC
with objects. So far as I know, "procedural" programming is an antonyme to
"declarative" programming (like in Prolog, or, rather, like what Prolog was
designed for but did not quite fulfilled ;)), and has nothing to do with
objects or lack of them at all.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - Kenneth,>>>>>> Kenneth C. Dyke (KCD) wrote at Mon, 10 Sep 2001 22:07:42 -0700:KCD> ...A file's
KCD> type is ultimately determined by it's contents....
Well, yes and no. In majority of cases, definitely yes. Though, there are
not that spare cases when the type (whatever way expressed) _adds_ an
important information.
There is an application which uses a simple dictionaries, which are stored
as plain ASCII files. No content analysis can distinguish it from a normal
plaintext.
Now, of course it is important that the fact that _is_ a text should be
known, and those files can be easily and without problems opened in any text
editor (TextEdit, BBEdit, vi, emacs, you name it...).
OTOH, the information that those are _primarily_ files of SomeDictionaryApp
is quite important as well, and (as opposite to the default app binding) it
is independent of user.
Or take a HTML file; it might contain a documentation of NSView, or a help
page for Finder, or a plain formatted document. In a resonably designed
system those three (and possibly many other) would be distinct types, able to
be bound to three different applications by (user-defined) default. Again,
this kind of distinction can't be done by content analysis.
The result is that you need _some_ way of attaching type information to
files. The more flexible the better; hiearachical types would be better than
non-hierarchical ones, and sets would be better than scalars.
Content analysis, of course, can be used as _part_ of this scheme, but
cannot replace it completely (without serious shortcomings).
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - j,>>>>>> j o a r (joar) wrote at Tue, 11 Sep 2001 00:14:41 -0700:joar> >A particular example might be .tar.gz. It is more than just .gz; it
joar> >brings
joar> >not just the information "this can be decoded by gzip" as any other
joar> >.gz file,
joar> >but *also* it informs "it can be decoded by gnutar -z".
joar>
joar> Why not be even more explicit while we're at it:
joar>
joar> MyDocument.html.txt.tar.gz
joar>
joar> Woho, types through file name extensions! The type is longer then the
joar> file name!....
You are trying to change the debate topic, and I won't bite. I _WON'T_
discuss whether it is Good or Bad, Acceptable by Mum or Wife, or Flattering
the Ants. I am just reasoning that extensions are more flexible than types
(as currently implemented in OSX). That's a fact. Whether it is a reason
strong enough to use them at all, and/or to present them to user or not, I
_WON'T_ discuss, since it would turn to an uneeded and good-for-nothing
flamewar again. _THAT_ was done already a thousand times without any outcome.
joar> BTW. What do you say we take this thread to macosx-talk instead Ondra?
joar> Parts of it is there already.
Yep. That's one of reasons I've unsubscribed macosx-talk.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - On Tue, Sep 11, 2001 at 09:52:22AM +0200, Ondra Cada wrote:
: >>>>>> John C. Randolph (JCR) wrote at Mon, 10 Sep 2001 23:26:26 -0700:
:
: JCR> Within each app we have objects, and they act in
: JCR> various ways, but at the top level of the system we're still essentially
: JCR> working procedurally.
: ...
: JCR> What if we didn't need TextEdit.app, because simply loading an NSText
: JCR> object into memory would suffice? (Every object its own app, using or
: JCR> not using the framework code as appropriate?)
:
: Don't want to sound like a spoilsport, but I guess when such a design is
: finished, it would became obvious that they just reinvented SmallTalk ;)
That and a tequila mix of OpenDoc. :-)
--
Eugene Lee
<eugene...> - On Tuesday, September 11, 2001, at 09:52 , Ondra Cada wrote:> Well, yes and no. In majority of cases, definitely yes. Though, there are
> not that spare cases when the type (whatever way expressed) _adds_ an
> important information.
>
> There is an application which uses a simple dictionaries, which are stored
> as plain ASCII files. No content analysis can distinguish it from a normal
> plaintext.
>
> Now, of course it is important that the fact that _is_ a text should be
> known, and those files can be easily and without problems opened in any
> text
> editor (TextEdit, BBEdit, vi, emacs, you name it...).
>
> OTOH, the information that those are _primarily_ files of
> SomeDictionaryApp
> is quite important as well, and (as opposite to the default app binding)
> it
> is independent of user.
Maybe you didn't notice it, but you just advertised the concept of
creators :-)
file told me that my xml files are ASCII text, so there is definitely a
need for more than content-based type information.
Try "file ~/Library/Preferences/*". One Carbon app's preferences are even
detected as "8086 relocatable (Microsoft)".> Content analysis, of course, can be used as _part_ of this scheme, but
> cannot replace it completely (without serious shortcomings).
What you (Ondra & Kenneth) basically described is: Do it like it's done in
Mac OS X, but replace file extensions with content-based mapping. I
actually agree with you :-)
I think I've read that Mac OS X already does content-based mapping as a
last resort (see that USENIX article by Wilfredo Sanchez).
andy
--
Discussion forthcoming. - > Given this fact, why not propose a system whereby the OS is actually
> able to interrogate files as to what they are in order to assist with
> decisions about what applications can actually handle the file?
We have that, to some extent, QuickTime's ::GetGraphicsImporterForFile().> What I'm thinking of is that application bundles could have an
> additional CFPlugIn included that could be loaded by the Finder (or
> whatever). These plugins would communicate with their loader...
*nods sagely* QuickTime calls them "GraphicsImporter components".> Now, someone is going to immediately pipe up and say "but that would be
> too slow!". Maybe, maybe not.
Well, actually, yes. Compared to nice fast metadata, anyway.
--
Alex Curylo -- <alex...> -- http://alexc.webjump.com/
They say to let your conscience be your guide.
Mine's more of a creative consultant. - Andreas,>>>>>> Andreas Monitzer (AM) wrote at Tue, 11 Sep 2001 14:16:45 +0200:AM> >Well, yes and no. In majority of cases, definitely yes. Though, there
AM> >are not that spare cases when the type (whatever way expressed) _adds_
AM> >an important information.
AM> >
AM> >There is an application which uses a simple dictionaries, which are
AM> >stored as plain ASCII files. No content analysis can distinguish it from
AM> >a normal plaintext.
AM> >
AM> >Now, of course it is important that the fact that _is_ a text should be
AM> >known, and those files can be easily and without problems opened in any
AM> >text
AM> >editor (TextEdit, BBEdit, vi, emacs, you name it...).
AM> >
AM> >OTOH, the information that those are _primarily_ files of
AM> >SomeDictionaryApp
AM> >is quite important as well, and (as opposite to the default app binding)
AM> >it is independent of user.
AM>
AM> Maybe you didn't notice it, but you just advertised the concept of
AM> creators :-)
Not only I did not noticed it; i _do know_ that it's an utter nonsense.
I am sorry you still haven't understand the difference between types,
creators, and app/document bindings, but I just don't want to explain them
for the umpteenth time. I would recommend you to study the archives.
Hint1: there can be more apps which interpret the docs as dictionaries (say,
SomeDictionaryApp, SomeDictionaryAppCmpanion, and
SomeDictionaryAppCompetition), not just one.
Hint2: user might want to select some text editor as the default app binding
for these files, be they primarily dictionaries or not.
Result: we are speaking of _types_ here. They should be made more flexible
(by adding the contents analysis perhaps, by allowing typesets, by supporting
hierarchy...). MacOS creator code OTOH is a legacy PITA which should vanish
ASAP (to be replaced by some more flexible way of default app binding).
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - On 9/10/01 10:07 PM, "Kenneth C. Dyke" <kcd...> wrote:> Every time this discussion of filename extensions versus
> type/creator/etc. comes up, I feel like I'm watching people flame each
> other over who's 15-20 year old solution sucks less, and no one tries to
> actually propose anything better, which is probably why the discussion
> never moves forward.
I think the format of this discussion obscures real progress and good ideas
because someone I always coming in or out and it's hard to get everyone on
the same page. I'm convinced there are good ideas and actually an emerging
consensus.
My problem is that Apple is not leading. By essentially punting and telling
developers "use creators if you want" they have managed to create a user
experience worse than either Next or Classic. What the user will see is
that some files can be rebound in the "Show Info" box and others can't be.
Some can be rebound by changing their extension and others can't be. This
will be very confusing/frustrating.
My hope at this point is that Apple will be a good follower. The situation
is screwed up enough that 3rd party tools and user scripts will be
developed to deal with it. If Apple can simply watch how their users cope
and incorporate that functionality into future versions of the OS I will be
pleasantly surprised.
--
Tact is the ability to describe others as they see themselves. -Abraham
Lincoln, 16th president of the U.S (1809-1865) - On Tuesday, September 11, 2001, at 02:52 AM, Ondra Cada wrote:> John,
>
>>>>>>> John C. Randolph (JCR) wrote at Mon, 10 Sep 2001 23:26:26 -0700:
> JCR> Within each app we have objects, and they act in
> JCR> various ways, but at the top level of the system we're still
> essentially
> JCR> working procedurally.
> ...
> JCR> What if we didn't need TextEdit.app, because simply loading an
> NSText
> JCR> object into memory would suffice? (Every object its own app, using
> or
> JCR> not using the framework code as appropriate?)
>
> Don't want to sound like a spoilsport, but I guess when such a design is
> finished, it would became obvious that they just reinvented SmallTalk ;)
I thought that was the job of the next generation - to re-invent what
the previous generation already invented <grin>.
I like the object idea, but it boils down to how you use it. In other
words there are hammers and there are nails and both serve a vital
purpose. Neither role can be reversed. To argue that they both should be
considered equally works in the abstract, but not in the concrete (or
the wood). Granted the sniffer concept I like (albeit I fear there are
too many exceptions to the rule at this point).
I dunno, have we reached the point of no return, or can the genie be
stuffed back into the bottle? Do I ALWAYS what a JPEG to be opened by
the same application (if I have Photoshop and PixelMaster and the both
create JPEGS will they be opened by their respective programs or am I
stuck with one or the other?).
Rock or hard place?
Cheers,
Lloyd
--------
Canna Software Development
"Llamas generally avoid mailing lists, primarily because it strains
their eyes." - > Incidentally, correct me please if I am wrong, but unless there was some
> re-definition of terms lately, I guess we *are* working procedurally in ObjC
> with objects. So far as I know, "procedural" programming is an antonyme to
> "declarative" programming (like in Prolog, or, rather, like what Prolog was
> designed for but did not quite fulfilled ;)), and has nothing to do with
> objects or lack of them at all.
> ---
> Ondra Cada
OK, since I'm too lazy to look it up, what _is_ the opposite of OOP?
Functional? Please don't say something like non-OOP... ;) But you can tell
me to RTFM if you can find me a good M. Or does OOP not have an opposite
except declarative, being actually a special kind of procedural? Maybe I'll
learn at school: I started my OOP class today--slooow start. We're doing
Smalltalk along with the C++ tho, so that's good.
bg - > From: Andreas Monitzer <am...>
> Date: Tue, 11 Sep 2001 14:16:45 +0200
> To: <ocs...>
> Cc: (Cocoa-Dev) <cocoa-dev...>
> Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
>
> I think I've read that Mac OS X already does content-based mapping as a
> last resort (see that USENIX article by Wilfredo Sanchez).
>
> andy
> --
> Discussion forthcoming.
So why is my system littered with files typed as generic "document"? I hate
that, partly because it's non-descriptive, but mostly because it means that
double clicking it won't open it. Usually I know what type it is from name
and/or location, but the Finder/OS is too dumb to know that my clicking it
means I want to open it and that _some_ app should damn well try 'cause I
said so!
bg - Brent,>>>>>> Brent Gulanowski (BG) wrote at Tue, 11 Sep 2001 19:04:11 -0400:BG> OK, since I'm too lazy to look it up, what _is_ the opposite of OOP?
Sorry, dunno.
BG> Functional? Please don't say something like non-OOP... ;) But you can
BG> tell me to RTFM if you can find me a good M.
I'd like to find some myself... I don't have a good dictionary aimed to
informatics; my generic Webster does not help here naturally. Perhaps
something could be found on Web.
BG> Or does OOP not have an
BG> opposite except declarative, being actually a special kind of procedural?
AFAIK this is _partially_ right.
So far as I understand those terms properly, then OOP vs. non-OOP (sorry) is
actually orthogonal to procedural vs. declarative distinction: although the
only (more or less) declarative language I know of is Prolog which is not OO,
I can imagine another Prolog-like system, which would use its own
abstraction of objects.
OTOH, the OOP which we all know and use, be it the static compile-time thing
of Ada or the dynamic late-binding thing of Smalltalk, happens to be a
procedural programming as well as OOP.
Quite simply, whenever we are saying the computer _what it should do_, we
are using procedural programming, regardless inheritance and its companions
can be applied or not. Whenever, though, we are saying the computer _what
result we want to get_ (letting it to find a way to compute it itself), we
are using declarative programming -- again, regardless inheritance and
companions can be applied or not.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - On Wednesday, September 12, 2001, at 10:31 AM, Ondra Cada wrote:> BG> Or does OOP not have an
> BG> opposite except declarative, being actually a special kind of
> procedural?
>
> AFAIK this is _partially_ right.
>
> So far as I understand those terms properly, then OOP vs. non-OOP
> (sorry) is
> actually orthogonal to procedural vs. declarative distinction: although
> the
> only (more or less) declarative language I know of is Prolog which is
> not OO,
> I can imagine another Prolog-like system, which would use its own
> abstraction of objects.
Indeed, there are several declarative (functional or logical), object
oriented languages. OCAML and O'Haskell come to mind.
(For something that is very close to Prolog, but a pure logical
programming language, have a look at Mercury. It used to compile on Mac
OS X.)
I prefer the term "imperative" over procedural.
Regards,
John Hornkvist
--
ToastedMarshmallow, the perfect Cocoa companion
http://www.toastedmarshmallow.com - On Wed, 12 Sep 2001 10:31:42 +0200 Ondra Cada <ocs...>
wrote:> BG> OK, since I'm too lazy to look it up, what _is_ the
> BG> opposite of OOP?
>
> [...]
>
> BG> Or does OOP not have an
> BG> opposite except declarative, being actually a special
> kind of procedural?
>
> AFAIK this is _partially_ right.
I believe that what makes OOP languages different from
others is the message: sending a message, using
polymorphism, is different from a procedure call.> So far as I understand those terms properly, then OOP vs.
> non-OOP (sorry) is actually orthogonal to
> procedural vs. declarative distinction: although the
> only (more or less) declarative language I know of is
> Prolog which is not OO, I can imagine another Prolog-like
> system, which would use its own abstraction of objects.
Yes, see for instance COOL (the Clips Object Oriented
Language) which is an OO extension of the CLIPS expert
system shell. Of course, more or less pure functional
languages also had their OO extensions, CLOS for instance.
Conversely, conventional OO languages only encapsulate
attributes and methods, while it could be argued that they
should or could also encapsulate declarative rules.
Marco Scheurer
Sen:te, Lausanne, Switzerland http://wwww.sente.ch - Marco,>>>>>> Marco Scheurer (MS) wrote at Wed, 12 Sep 2001 12:49:03 +0200:MS> I believe that what makes OOP languages different from
MS> others is the message: sending a message, using
MS> polymorphism, is different from a procedure call.
I would agree -- it is my widely known opinion that eg. C++ is not an OO
language ;)
The majority though seems to "think differently" (sorry, could not resist ;))).
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc - Don't want this to become a huge rant.
Exactly why extensions are no good. When you run IE (everytime) it
switches .html extension to be opened with IE. if it had a creator
code, IE could not do this. Same goes for .txt files. Genius AIM
programmers decided all .txt files should open in AIM.
And BOTH creator code and extensions can be overridden by the finder in OS X.
Ack, at 9/13/01, Piers Uso Walter said:> You're only talking about yourself. What about others who may want
> to open these files?
>
> The most obvious problem of the current creator code based
> application binding policy is that it almost never does what you
> want when you work on somebody else's files, e.g. file that you
> receive via email or files in a different user account that you want
> to open.
>
> I don't want any text files to open up in SimpleText or BBEdit, just
> because they may have been created with those tools (I'd prefer to
> use TextEdit).
>
> I don't want PDF files to open up in my Acrobat Reader, just because
> they may have been distilled by Acrobat (I'd prefer to use Preview).
>
> And most certainly I do not want any HTML file to launch my Internet
> Explorer, just because its creator type says so (I'd prefer to use
> OmniWeb).
>
> All of this happens to me *daily*, though, which is so annoying that
> I can't even begin to describe it. This ill-conceived behavior
> prevents me from using a simple double-click to open files, forcing
> me to always drag the files to the application that I want to use,
> which again forces me to keep all of these apps in the dock, for the
> slight chance that I may have to drag a file to them. This really is
> the opposite of intuitive and user-friendly.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People - > On Monday, September 10, 2001, at 03:10 AM, Neal A. Crocker wrote:
>
>> In the Mac OS user experience, the average user never has to change
>> the code, or even see it, so they never have to remember it.
>
> I absolutely cannot confirm this.
>
> Many of the more technically inclined Mac users I know have
> downloaded and used FileTyper sooner or later because they were sick
> and tired of other people's documents not opening in their own
> preferred application.
>
> The less technically inclined users of course ususally do not
> understand FileTyper and the whole concept of type and creator code,
> so the more technically inclined users often tend to create auto
> typers for them (onto which they can drag and drop files to change
> type and creator code).
>
> With kind regards
>
> Piers Uso Walter <Piers.Walter...>
> ilink Kommunikationssysteme GmbH
It would seem to me that we are talking about different things.
Certainly many Mac users feel the *effects* of type and creator codes
and find useful utilities for changing them, but I would argue that
such utilities never actually need to *show* the four bytes composing
the type or creator code to the user (and, thus the user never needs
to see them). With regards to creator codes, there is a one-to-one
relationship between applications and creator codes (with the
exception of irregular applications like applescript droplets and
applets). It would seem to me that any well designed creator-code
changing utility could present such changes in terms of changing the
*owning application* or *default application* without ever show the
actual four (possibly unprintable) bytes that compose creator codes.
With regards to type codes, I'm fairly sure that the mechanisms used
by Finder (specific resources in OS < 9 ("kind" ?, or maybe "BNDL"?)
and info.plist files in OS X) can be used by type changing utilities
to show users human readable "kind" strings (like those show in
Finder folder list views) as optional settings for the files. Other
resources may exist, such as Internet Config, the provide type
changing utilities the information they need to present human
readable options for types to the user. It seems that the actual
four bytes of the type code could be hidden from all but the most
advanced users of type changing utilities.
Neal. - > 2001-09-08 Mark Munz wrote:
> It seems like what you want is the Finder to be able to let
> you change the creator / type of a file. Then ask for that
> feature, and not the desire to change the definition of what
> kind of file it is based on what the user calls it (mypic.tiff
> vs. mypic.jpg -- if I rename one "mypic", which type is
> it then?).
There are at least 3 characteristics/options: file type,
file creator, preferred application to be launched on double-click
As noted, already, it is often reasonable to drop a file
of some type on an app whose "will accept" settings may not
be aware of that particular type.
It is mildly annoying for a file's type to affect the
file's name, though... only mildly.
John G. Otto, Eagle Scout, Knight, Cybernetic Praxeologist
Existence, Consciousness, Identity, Life, Liberty, Property, Privacy, Justice
