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:
    >
    >> 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.
    >
    Yes! All collisions should be handled this way. Revealing the ext in
    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 and
    3.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
previous month september 2001 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today