Snow Leopard Snubs Document Creator Codes 214
adamengst writes "In this TidBITS article, Matt Neuburg explores how Mac OS X 10.6 Snow Leopard changes how the operating system handles preferred application bindings, dropping support for the creator codes that have been part of the Mac OS from the early days. He also explains how to work around the problem, if you want, for instance, text documents created with BBEdit to open in BBEdit even when TextEdit is the default handler for text files."
Problem? (Score:5, Insightful)
He also explains how to work around the problem
It's not a problem, it's a fix. This is the way it should work.
Suppose I put a Word document on a computer where OO.o is installed instead of Office. The document says "open me in MS Word". The OS says, "Word isn't installed". What happens? What originally should have happened: The OS looks at the document, says "Word document, open this with OO.o", and everything works great. The extra information was a stupid extra step. "Word document" is all the OS needs in order to figure out how to open it.
Re:Problem? (Score:4, Interesting)
Example of use:
I have a lot of AVIs, and a handful of them only play in Quicktime, or only play in VLC. I changed the creator code on those files so they open in specific player.
Re: (Score:2)
That is (if RTFA to be believed) is unchanged in SL.
Re: (Score:2, Insightful)
You mean you set the "Open with..." in the Get Info window? That still works, the article says so.
The real problem is that everyone needs five media players on their computers just for handling bad videos, but they all have the same extension. Quicktime, VLC, mplayer, niceplayer, etc, etc, etc. It's a shame that the "vague short extension" mechanism of identifying files has won, especially now we have container files with variant contents.
Re:Problem? (Score:5, Insightful)
The extra information was a stupid extra step. "Word document" is all the OS needs in order to figure out how to open it.
Well actually OSX still lets you set the proper application to open on a per-document basis, and it's kind of handy. AFAIK, what happens if you put a Word document on a computer that doesn't have word, but has OO.o, OSX will read the part that says, "open me in Word" and say, "Well I don't have Word but I have OO.o, so I'll open you in that instead." So there's no problem.
However, let's say you have both OpenOffice and Word installed on the same machine, and 9 times out of 10 you want to open your Word documents in OpenOffice, but you have that 1 document out of 10 that doesn't display properly in OpenOffice and you want to preserve the current layout. What's actually kind of nice IMO is that you can say, "I want my default to be to open all Word documents in OpenOffice, but I can set this one individual file to open in Word." And then the OS will open each document in the correct viewer when you double-click on it, automatically. It works great.
So what's being talked about here is that it has typically been set in the past so that, regardless of your default application, documents were set to open in whatever application you saved/created them in. So it's like lets say OpenOffice is my default application but I create a new document in Word. The old behavior is that document would automatically be set to open in Word when you double-click on it instead of OpenOffice, even though OpenOffice is your default application. It makes a certain amount of sense to do it that way, since you may have done layout work in Word that won't render properly in OpenOffice.
However, I personally want to set a default application for each file-type, and then only have them use a different application if I manually set them to do so.
Re: (Score:2, Insightful)
The problem is for those of us that didn't know that creator codes exist.
We would set .avi files to all open in VLC, and be confused when some opened in quicktime.
This is a bugfix.
Re: (Score:3, Insightful)
Re:Problem? (Score:5, Insightful)
No, they were opening in QuickTime just because they were originally saved by QuickTime.
No one ever did Get Info.
It sounds like this previous behavior seems odd to you (since you misunderstood what happened), which supports the perspective that for most users, the behavior was odd and the change amounts to a bug fix.
Re: (Score:2)
No, they were opening in QuickTime just because they were originally saved by QuickTime.
No one ever did Get Info.
It sounds like this previous behavior seems odd to you (since you misunderstood what happened), which supports the perspective that for most users, the behavior was odd and the change amounts to a bug fix.
Since when does QuickTime save AVI files?
Re:Problem? (Score:5, Informative)
So let me get this straight.
Fail. The GP was saying that he'd set all AVI files to open in VLC. In spite of that, some would open in QuickTime anyway because that's what the creator code indicated, which confused the GP greatly because he didn't know that such a mechanism existed.
Re: (Score:2, Insightful)
Re:Problem? (Score:5, Funny)
Whoawhoawhoa, slow down, buddy...... right-click? You're scaring me with your crazy-talk!
Re: (Score:2)
In other words, you like this change, as it uses the following in order: an explicit file specific default, an explicit file type default, or an implicit file type default.
The old way was in order: Explicit file-specific default, explicit file type default, the application that made the file, an implicit file-type default.
(Yes, according the the Apple documentation the creator code never overrode an explicitly set default application for a file type, but would override the implicitly chosen default applicat
Even better. (Score:2)
Re: (Score:3, Informative)
The only meta-data attached to a file sent by e-mail is the extension and the mime-type. If your default .doc opener is OO.o, it should work fine.
You'll only see this problem when you get files in storage formats that support file meta-data. Some compression formats support it, and removable storage may or may not.
Re: (Score:2)
Re: (Score:3, Informative)
What if you didn't have OO.o OR Office installed?
Type/creator codes were m
Re: (Score:2)
What if you didn't have OO.o OR Office installed?
Open it with whatever the default app is for Word documents. You still don't need to know what it was created by.
Type/creator codes were meant to replace "ugly" extensions
Extensions are oft-maligned, but underrated in my opinion. They're part of the filename, they're easily seen (if you have them turned on, which you of course should – hiding the extensions by default is a stupid, stupid move IMHO), and they're easily changed if necessary (granted, most users will never need to change one).
Creators are used to identify a creator, so double-clicking would open the same app that opened it (back in the days when compatibility was horrible, the general thinking is you want to open something in the app that created it). The type ID was a fallback in case you can't find the creator, you can try a type lookup, in case it was something another program could handle.
That's why PhotoShop has .psd, GIMP has .xcf, etc. Compatible formats
Re: (Score:3, Insightful)
Apparently, that's also why Word, Wordstar, WordPerfect, DisplayWrite and Framemaker all have used the .doc extension for their proprietary file formats.
File Association Hijacking (Score:5, Informative)
He also explains how to work around the problem
It's not a problem, it's a fix. This is the way it should work.
Suppose I put a Word document on a computer where OO.o is installed instead of Office. The document says "open me in MS Word". The OS says, "Word isn't installed". What happens? What originally should have happened: The OS looks at the document, says "Word document, open this with OO.o", and everything works great. The extra information was a stupid extra step. "Word document" is all the OS needs in order to figure out how to open it.
That's always the way it worked. If you had a Word file (Type=W8BN, Creator=MSWD) on a system without Word (MSWD) installed, the system would identify any other applications capable of opening W8BN files, and open it using that app.
The extra information only came into play when there was more than one application capable of opening W8BN files. It prevented the common Windows practice of "hijacking" another application's file extensions.
Re: (Score:3, Insightful)
It prevented the common Windows practice of "hijacking" another application's file extensions.
That's a feature, not a bug. If I install a new app, I want it to open such-and-such file types. The only problem is apps that silently re-associate themselves with all their file types when they open, and anyone who writes such an application should be flogged and rubbed with salt IMHO.
Having your file types stolen by another application should be responded to with a warning popup specifying the file type(s), the apps with which they're now associated, and giving the following options: (1) Reassociate the types. (2) Don't reassociate, and stop checking these file types. Yes, popups are annoying as hell, but if two apps are fighting over the file type you'll only see the warning twice: once from each app. Consider it part of the installation process.
God, what a mess. You're seriously advocating this behavior? Do you work for RealNetworks?
When I install an app, if and when I want it to open such-and-such file types, I will make that change myself.
Re: (Score:2)
When I install an app, if and when I want it to open such-and-such file types, I will make that change myself.
Never said I don't agree with that. In fact, I do. Give me a list of the file types and let me choose which ones to associate, if any. Do it during installation so I don't have to later.
The scenario I described is what superseded app X should do when it discovers that I installed app Y and changed some files that it thought belonged to it. You really shouldn't even get the warning more than once: If it was a legit change, I only see one warning, and tell it "ignore". If it was not legit (i.e. they were "sto
Re: (Score:2)
That might sound simple enough when refering to a doc file, or a compressed package. However, if my default document editor os OO, but someone sends me a file from office 2007 containing macros, OO is going to have issues with that. I'd like to know not only is it a .doc, but also that its a Word 2007 .doc file, so if it doesn't open in OO, or looks odd when it does, I can quickly identify the actual application used to make it and try opening it that app (if I have it or a compatible reader) instead.
This
Re: (Score:2)
Snow leopards Text Editor app has support for ODT. Which is great but since text editor doesn't have all the feaTures of Open Office editing the file becomes harder. The "mac way" while not universally supported is farbetter than just extensions alone. Where if you have multiple apps for the file type fails the ease of use.
Bugfix (Score:2)
When was the bug reported & why did it take so long to fix?
Re: (Score:2)
It isn't a stupid extra step. If the creator app isn't installed then it's wise to use whatever available app can handle the document. On the linked page someone made the important observation that this will completely break the proper behavior when using multiple graphic design apps that use their special flavor of eps with metadata as their document format. Without using a creator code you can't launch the right app for a document.
Re: (Score:2)
It didn't work fine before, but plenty of other people illustrated that fact and I don't have any additional personal experience to attest to it, so I'll let them speak for themselves.
Re: (Score:2)
LOL. And RTFA illustrated that it worked perfectly fine before. And now is broken. Very few commenter here managed to bring an example which was actually broken. Rest are simply "what if"s.
Sole example of old behavior being broken I have read above: QuickTime was used to create .AVI, VLC is associated with .AVI, yet the created file would be open by QuickTime due to creator code.
Example from RTFA is similar but goes backwards: files created with PhotoShop are being by default open with Preview. Chang
Re: (Score:2)
Sole example of old behavior being broken I have read above: QuickTime was used to create .AVI, VLC is associated with .AVI, yet the created file would be open by QuickTime due to creator code.
You missed the comments which mentioned similar behaviour where Photoshop was launching to open JPEGs and PNGs.
Example from RTFA is similar but goes backwards: files created with PhotoShop are being by default open with Preview. Changing .PSD association to PS makes it open all files with PS, not only the ones you work with.
Photoshop documents should open with Photoshop. If you only want to preview it, that should be a right-click menu choice, not a file-by-file setting that overrides the "Open in Photoshop" default action.
Re: (Score:2)
Photoshop documents should open with Photoshop. If you only want to preview it, that should be a right-click menu choice, not a file-by-file setting that overrides the "Open in Photoshop" default action.
It is quite often used as a plain image file format. There are many applications which can read it (Mac OS X's vanilla Preview can, any decent image editor) and many applications which can write it (same list).
So this was a quite normal work flow: all PSDs you create yourself would be open by PS, rest - by default Preview.
Re: (Score:2)
I'd argue that the amount of time lost by having to right-click and choose "Preview" (which should be the 2nd choice, the first being "Open") is worth it for the added benefit of always knowing what the file will open with. Double-click to open with PS (or other default editor), right-click and Preview to preview. (If you usually work the other way around, you could of course set it the other way around... default "Open" could be Preview, and "Edit" could be PS.)
Otherwise, it's impossible to know how the fi
quicktime (Score:5, Informative)
The editing features are now limited to trimming for example, the export possibilities rudimentary.
Fortunately, one can still reinstall Quicktime 7 additionally in Snow Leopard, but one can not change the default application binding for Quicktime. This is a serious problem.
For me, Quicktime pro is half the reason to use a Mac. Changes like this from Leopard to Snow leopard always make me nervous and I'm glad to have Linux catching up. Even apple might screw things up in future, possibly due to pressure of the movie and music industry.
One can for example suspect that the lack of cut and paste ability or export of sound only etc is due to such industry pressure. The average user can no more cut out advertisements for example. I do not see any technical reason why the new limitations are in place if quicktime pro is ditched. An other reason for the current limitations could be that a new QT pro is in the making. I hope this is the case. Still, one should be able to change the default application binding to an old version of quicktime!
Re: (Score:2)
I'm sure Apple would rather sell you a (more expensive) version of Final Cut or somesuch instead, anyway. I was disappointed to find out they took the Pro features out of Quicktime X, and had to make do with iMovie in a limited timespan.
Re: (Score:2)
Re: (Score:2)
Re:quicktime (Score:2, Funny)
Re: (Score:3, Insightful)
Re:quicktime (Score:5, Informative)
According to the Ars write-up, the features are missing because Quicktime was completely rewritten to be a more modern codebase. Among other things, this was required to be able to get it to run on the iPhone. Unfortunately, this also means that some features are still missing. Apple has told developers that they intend on bring Quicktime X back to the level of Pro soon.
Also, some of the awesome features of Quicktime Pro were so embedded in the system that they caused a real problem for movie viewing. Most media formats stream data in a way that quicktime doesn't like - it wasn't to know when the beginning and end are so it can do all of its fancy frame-by-frame selections. So if you read in a divx avi file with an mp3 soundtrack, it had to load the entire file, generate its editing information, and convert it to a .mov in the background to even play it. Hopefully they can find a way to do the best of both worlds in the new version once it finally gets up to snuff.
Re: (Score:2)
...if you read in a divx avi file with an mp3 soundtrack, it had to load the entire file, generate its editing information, and convert it to a .mov in the background to even play it. Hopefully they can find a way to do the best of both worlds in the new version once it finally gets up to snuff.
Actually, the issue around that is that the original QT code always generated all that information, because there was no concept of a 'playback-only' stack there. In QuickTime X there *is* that concept, so this information gathering can be skipped completely. At present, QTKit enforces this, so to get the cleaner and more advanced QTX playback rendering engine you can initialize a QTMovie for 'playback only' purpose, at which point the movie will be initialized using the QTX stack. If you want editing, it'l
Re: (Score:2)
Hopefully they can find a way to do the best of both worlds in the new version once it finally gets up to snuff.
Personally I don't want to watch up to snuff movies, thank you very much!
An error in TFA (Score:2)
(In early 2005 Apple introduced another way of specifying a file's type: the uniform type identifier, or UTI. It's invisible metadata, like a type code, but it's longer, it carries more information, and it can be part of a hierarchy. For example, a text file would typically be a "public.plain-text", which is a subclass of "public.text". File extensions are still with us, though.)
A UTI is not another piece of metadata attached to the file, it's just a unified abstract representation of a file type. The system knows that a file with the extension ".txt", a file with the MIME type "text/plain" and a file with the type code "TEXT" are all of type "public.plain-text", without adding any further metadata to the file itself.
Re: (Score:2, Offtopic)
Not the UNIX way (Score:5, Insightful)
File name extensions are definitely not the UNIX way. They are the CP/M way, copied later by DOS, then by Windows, then by UNIX graphical environments such as KDE, GNOME, and Mac OS X -- but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename.
It's very, very unfortunate that Mac OS X is now reverting to the primitive CP/M way. It causes a loss of essential functionality that Mac power users have always depended on: to know that a document will always be opened in the application with which you've created it.
For me, there is less and less reason to use a Mac as Apple keeps progressively emulating Microsoft. This is yet another nail in the coffin.
Re: (Score:2)
a document will always be opened in the application with which you've created it
It will, if you save it in the appropriate format. If you use a generic format like JPEG, it should open in a generic JPEG viewer (e.g. Preview) by default.
Re:Not the UNIX way (Score:5, Insightful)
While you are right that file extensions are not the UNIX way, from TFA and the other comments, it seems OSX uses Uniform Type Identifiers (a variant on MIME types) to identify files, rather than by their extension or creator code. I would assume extensions are still used When All Else Fails (for example, when reading files from FAT32 with no metadata attached)
Re: (Score:2)
In theory, OSX uses MIME types. In practice, it often doesn't. If I have Preview set up as my default PDF viewer, and I take an ordinary PDF file and change its extension from ".pdf" to ".doc", it might try to open in Word. Or in Acrobat Reader. Or Illustrator. Lord only knows.
The argument for creator and type indicators for files would be a lot stronger if OS X had a coherent type system that actually worked. In practice it's got at least two overlapping systems.
I'll be happy to have *one* that works
Re: (Score:2)
It's very, very unfortunate that Mac OS X is now reverting to the primitive CP/M way. It causes a loss of essential functionality that Mac power users have always depended on: to know that a document will always be opened in the application with which you've created it.
Suppose I don't want the file to open in the application I created it in? I know of several applications that I only want to open a document in when I want to edit the document, the rest of the time I prefer opening the document in alternative applications.
Re: (Score:2)
I know, I know! You could have a sort of hidden menu, attached to that file, with options like "Open" and "Edit" and "Open With..."
Re: (Score:2)
I know, and I know, and yes, I'm just suggesting that maybe this clever trick was a better idea than hiding some option in the file properties where most users won't ever find it.
and it's much more reliable than Window's usually brain-dead guesses about which applications can open a given file type, so, unlike Windows, you don't have to resort to "Other..." and then hunting for the program half the time
FWIW, Windows only does that the first time. It remembers your selection and includes it in the Other list for files of that type in the future.
Re: (Score:3, Insightful)
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename
Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.
However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?
Re: (Score:2)
That is correct, but there is a standard way of determining the type of a file without tracking it: the 'file' command (which uses metadata stored in /etc/file/magic). For most applications this would be perfectly practical.
Correction (Score:2)
Re: (Score:2)
The problem with 'file' is that it's system-dependent. If I create a new file type ("application/x-intlharvester"), there's no way I can transfer that across a random *nix system without losing the type info ... unless I also use a file extension.
So while extensions are not really the Unix way, Unix doesn't give you any other way either.
Re: (Score:2)
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename
Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.
However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?
Depends on what "standard unix" means...
There are other approaches to dealing with file types on Unix, of course. These days there's things like xattrs which could be used to store the file type, or (if one is willing to waste the time) there's always file magic...
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, bu
Re: (Score:2)
I suppose xattrs are part of some specficiation, however the server software ecosystem doesn't seem to use them; you generally can't "round-trip" a file from a unix system and preserve the metadata.
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
Hmm. Some *nix things like *.c and *.o files go way back, however this might still reflect a DOS influence.
There certainly are times that having a visible file type is useful, and times when the old Mac "secret metadata" approach is a pain in the butt. I don't think it's a clear win either way even ignoring Windo
File type identification on Unix (Score:2)
I suppose xattrs are part of some specficiation, however the server software ecosystem doesn't seem to use them; you generally can't "round-trip" a file from a unix system and preserve the metadata.
Quite true. One of several reasons I don't think this change will come to Linux until it comes to Windows first, or something... But, still, I do hope we'll get there sooner than that.
I think xattrs are actually part of POSIX, but obviously at present they're not something one can rely on being present on any given server or filesystem... I suppose related features like ACLs could help drive more widespread adoption of xattrs (though in the kernel the two features are enabled separately, I believe...) -
Re: (Score:2)
A cross-over solution was needed. Keep the functionality. If you created the doc in an app, you shouold expect it to open in that app if you still have it insdtalled. Same if someone sends you a word doc, you'd expect word to open automatically if you have it installed. However, we needed a solution for not-installed or default appications as well. If someone sent me an XLS document, but I don;t have office installed, i got an error, not a set of options... Users need it both ways.
Let me set a defualt
Re: (Score:2)
File name extensions are definitely not the UNIX way. They are the CP/M way, copied later by DOS, then by Windows, then by UNIX graphical environments such as KDE, GNOME, and Mac OS X
(Actually, CP/M picked them up from various DEC OSes, such as TOPS-10, so they're older than that.)
And KDE, and possibly GNOME, also use file-style mechanisms to identify files based on their content; when my main desktop was FreeBSD+KDE, my PDFs, for example, had no file extension (so that the file names didn't have an ugly ".pdf" at the end), but I could double-click on them to open them. When I moved to OS X, I had to put the ".pdf" back (at least I can tell the Finder not to bother me by showing it).
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename.
T
Re: (Score:3, Insightful)
Matlab and octave use .m files for scripting. Objective C class files also use .m. It's annoying when xcode opens up matlab files, but an editor suitable for working with matlab files is suboptimal for Objective C files. Yes, I know emacs supports objective C, but xcode is easier to work with.
Change for the Better (Score:2)
I'm in favor of this. I always hated when I had .png files created in fireworks that I wanted to view, and OS X tried to open fireworks up again instead of the default preview.
What's the point of making a default application if half the files will ignore it?
Re: (Score:3, Insightful)
What's the point of making a default application if half the files will ignore it?
The idea was application developers had the power to make files they made open in that application by default and if you didn't like it you could file a bug with the application provider. Now, application providers don't seem to have a way to do this, which many people are unhappy about as they relied on that ability of applications.
The "right" solution is for Apple to have provided a way for applications to claim files and given the user the option to honor or not honor that choice (regardless of the defau
Re: (Score:2)
This wont affect me, but one problem the new implementation has is that it encourages applications to save in their own proprietary format or with a proprietary file extension.
Re: (Score:2)
Note, I don't really care much on this one as it doesn't really impact my workflow, but I'm generally against changes that remove user choice altogether. Flexibility is good.
But it's not really that clear. It's reasonable to argue that this way gives the user more choice, not less. It will no longer allow application developers to be able to override the user's settings. While your idea of giving the option to honor or not honor the applications claims is a middle ground and allows both, I would think it would add another layer of complexity without getting much in return. If you say, "should OS X allow the App to ignore my settings" you're sort of giving them the choice to giv
It actually works just fine (Score:3, Insightful)
I think the complaint is that apps in 10.6 are not flagging their own documents to open with themselves. It should be easy to patch this in for any app that is currently being supported, but I suspect most won't care, because it's just not a huge deal.
Re: (Score:3, Informative)
I think the complaint is that apps in 10.6 are not flagging their own documents to open with themselves.
That is not the complaint in the article. The complaint is that Apple removed the old way applications flagged documents to open in themselves and does not seem to have provided any way for applications to do that using the new method. Rather, applications can tag documents, but the user must still go through and select the files by hand or using a non-obvious script to open in the application after each file is created. It could be that the article writer is mistaken and there is such a method, but no one
Resources have been gone since OS X (Score:2)
Although it is not the change to *nix that forced extensions upon us, it certainly was a major factor, along with the desire to interact with MS Windows. In any case it is nothing sudden or disturbing,
Resource fork making a comeback (Score:3, Interesting)
See here
http://dl.getdropbox.com/u/118359/ars/snow-leopard-indexed.html [getdropbox.com]
Is this just half an article? (Score:2)
I double checked creator codes on wikipedia [wikipedia.org]. They apparently also serve as a general file-type just like a filename extension. Except the file-type metadata is actually stored where it's supposed to be...with the other metadata.
So anyone know if this is just conceding to filename extensions, or if Apple is just dropping support for specific apps from claiming a _specific_ files no matter the OS wide filetype settings?
Re: Apple Urinary Tract Infections (UTIs) (Score:2)
I double checked creator codes on wikipedia [wikipedia.org]. They apparently also serve as a general file-type just like a filename extension. Except the file-type metadata is actually stored where it's supposed to be...with the other metadata.
So anyone know if this is just conceding to filename extensions, or if Apple is just dropping support for specific apps from claiming a _specific_ files no matter the OS wide filetype settings?
As others have mentioned, Apple has a new metadata-based method for encoding file type ("Uniform Type Identifiers")... The new scheme allows for IDs to be much larger (arbitrary size, as opposed to the four-byte Creator IDs) - and because they're based on domain names (a system which is already centrally-managed) there's no need for Apple to centrally manage the set of possible type IDs to prevent conflict.
Re: (Score:2)
Just Like Windows (Score:3, Funny)
Re:We Know Best (Score:5, Insightful)
On the other hand, you could argue that Apple is protecting users from developers who say, "We know what's best for you. We're making it just work. Now just sit back and drink your kool aid."
If I want my text documents to open in BBEdit, I'll set them to open in BBEdit thankyouverymuch. I set my default for them to open in something else, and that's the way I want it.
Re: (Score:3, Insightful)
On the other hand, you could argue that Apple is protecting users from developers who say, "We know what's best for you. We're making it just work. Now just sit back and drink your kool aid."
If I want my text documents to open in BBEdit, I'll set them to open in BBEdit thankyouverymuch. I set my default for them to open in something else, and that's the way I want it.
QFT. Overriding my choice as the end user for default application open selection is a no-no.
Re:We Know Best (Score:4, Informative)
It's the developer, not the end user, that applies the creator code that's being ignored (I can't remember the last time I manually changed a creator code--it was long before OS X, anyway). The end user can always do a "Get Info" to change the default app for any individual document.
That said, I agree that it's a pain to have to do that for every specific document you want opened with a particular app; I just saw a nit that needed picking.
Re: (Score:2)
That said, I agree that it's a pain to have to do that for every specific document you want opened with a particular app; I just saw a nit that needed picking.
This is what I was speaking about in particular.
TBH, I can't say it's ever been an issue for me, but still.
Re: (Score:3, Informative)
Re: (Score:2)
My problem is that I cannot seem to set defaults for files without an extension. Some perl scripts for example that look like commands, leave off the .pl extension. My mac wants to execute them instead of opening them in a text editor.
Re: (Score:3, Informative)
Re: (Score:2)
Clear the execute bit and it won't try to execute them.
Correct. We wouldn't want to know anything about Unix file permissions or nothing.
Re: (Score:2)
The easiest solution is to use the command-line to run the text editor with the script's path as the argument.
Re: (Score:2)
"foo.pl" is a perl library. "foo.pm" is a perl module. "foo" is a perl script.
Re:We Know Best (Score:5, Insightful)
Just to explain this, for me where I really think this is an issue is not text as much as graphics. I work with graphics and often enough, the application that created the graphics is Photoshop. However, I never want to actually open the file in Photoshop unless I actually want to edit it. Why open a JPEG in photoshop when it's going to take a full minute to load?
So I've set Preview to be the default application for viewing graphics, but still, any graphics I make in photoshop are set to open in Photoshop. If Snow Leopard is going to ignore that it was made in Photoshop and open it in Preview instead, as I've set the OS to do, that seems like a "bug fix" to me.
Re: (Score:2)
So I've set Preview to be the default application for viewing graphics, but still, any graphics I make in photoshop are set to open in Photoshop. If Snow Leopard is going to ignore that it was made in Photoshop and open it in Preview instead, as I've set the OS to do, that seems like a "bug fix" to me.
Amen! I have always found this behavior annoying for exactly the reason you specify, and this new behavior seems like CORRECT behavior. Just because I edit an image in Photoshop doesn't mean I want to always open that image in Photoshop from then on out - yet that was what happened. And not all applications would reset that anyway - so it seemed to me this was more of an "Adobe being Adobe" thing than a fundamental issue with the OS (Apple's apps did seem to always honor whatever settings I'd made in terms
Re: (Score:2)
Well, it all makes sense now! It's a conspiracy to sell more hardware!
PSD is the native file format in Photoshop. JPEG is a standard output format. Photoshop or any other application like GIMP is overreaching ownership on an operating system when it is not the only application that can natively render JPEG files; hence if I want Preview.app to render them or Safari or Pixelsight, et.al then the .plist association file for that format should be configured and stored in my account's preferences.
Re: (Score:2)
I think I read from the article that there's a way to set it for all existing files, although I think it's a total PITA method. More acronyms.
Maybe someone will (sadly), have to create an apple app/script that will do this every reboot, or something?
Re: (Score:2)
I think I read from the article that there's a way to set it for all existing files, although I think it's a total PITA method.
Sure, but I don't want to continually set the proper application for a given file-type. I want to set one default, and have the OS respect that decision unless I manually set a different application for a particular document. I think that's the proper behavior.
Re:We Know Best (Score:4, Insightful)
If, for instance, you prefer one graphics program for editing
Sort of a niche thing; but sounds like the people who relied on that class of configurations are out of luck.
Re: (Score:2, Informative)
If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you are now screwed. You can either set .jpgs to open in one, or the other...
Well not exactly. You can still have your default jpeg viewer be Preview, and still have only particular jpegs open in Photoshop. That's easy enough to accomplish. The difference is just that jpegs saved in Photoshop are not automatically associated with Photoshop regardless of the default that the user has set.
And it's not that I fail to recognize how it might be useful to have jpegs created in photoshop always open in Photoshop, automatically. It's just that I don't think it's a very sensible way to
Re: (Score:2)
If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you are now screwed. You can either set .jpgs to open in one, or the other...
Well not exactly. You can still have your default jpeg viewer be Preview, and still have only particular jpegs open in Photoshop. That's easy enough to accomplish. The difference is just that jpegs saved in Photoshop are not automatically associated with Photoshop regardless of the default that the user has set.
And it's not that I fail to recognize how it might be useful to have jpegs created in photoshop always open in Photoshop, automatically. It's just that I don't think it's a very sensible way to handle things. If I really want to use Photoshop most of the time, I can set that as my default jpeg viewer. If I have particular files that I'm opening all the time and want to open them in Photoshop, I can set that manually on a per-file basis. However, when I set a default viewing application for a particular file-type, it's nice for that decision to be honored by the OS.
Another scenario is that files associated in Photoshop sent to you on your machine without Photoshop have to open in something compatible to view them, no? It makes sense to bind native application formats to that specific application and standard formats to be bound by order of precedence you set. This debate is decades old.
Re: (Score:2)
Another scenario is that files associated in Photoshop sent to you on your machine without Photoshop have to open in something compatible to view them, no?
I think in those circumstances, OSX is smart enough to figure it out. Like if I created a JPEG with Photoshop and associated the file with Photoshop, and then I sent it to you and you didn't have Photoshop, it would just use whatever your default JPEG viewer was.
Re: (Score:2)
If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you can now right click, or drag the icon onto the dock.
Fixed that for you.
I do quite a bit of coding and graphic design, and view this as a very good thing.
There are limited use cases in which the old scheme made more sense. However, I find myself right clicking .JPGs to open in Preview more often than the other way around.
Re: (Score:2)
Care to explain what you mean here? Sounds like Apple is simply going the way of UNIX/Microsoft (I *think* UNIX used file extensions or part of the file itself). So how is Apple off base here?
Or were you just trying to make a snarky first post?
Re: (Score:2)
They are going out of their way to break things for users that might have actually used this feature in the last 25 years.
This is a great example of "consistency over time" being more important than trivial details between different apps.
That said, a decent file manager makes the point moot. If you don't want to use the default file handler, you can setup others and use them as you see fit.
Re: (Score:2)
I overall agree with you except that:
They are going out of their way to break things for users that might have actually used this feature in the last 25 years.
If you haven't noticed the feature in Mac OS X before it might mean only one thing: it is so well implemented that you hadn't even knew you were using it.
All what have happened in SLeopard is a clean up and making default different system, one similar to e.g. KDE.
Though most important aspect - as I'm concerned - is retained: one can still assign a different application to open the particular file.
Re: (Score:2)
Man, there are a lot of uninformed people posting to this article. Apple has used Uniform Type Identifiers [wikipedia.org] since 10.4 Tiger. Creator codes have been deprecated for years.
Truth to people can be a real bitch I suppose. They could always live like it was 1997.
Re:RIP (Score:4, Insightful)
Time to put them to rest for good? Why? What on earth for? I am puzzled by your joy.
Creator codes have been deprecated since 10.4 (Score:2, Informative)
Apparently, everyone has forgotten that UTIs have been in use since Tiger. [arstechnica.com]
By the way, Slashdot, nice job not posting a link to Arstechnica's epic 23-page Snow Leopard review [arstechnica.com] from last week. It's not like they put out the most detailed reviews in the industry or anything.
Re: (Score:3, Informative)
But UTI is in no way a replacement for a creator code.
The most useful aspect to me was that one can tell that the particular file has to be opened by different application.
E.g. for most of smallish stuff I'm using QuickTime Player. But most of my movie collection is marked as to be opened by MPlayer. Files types are the same - but different applications are used to open different files.
Or bigger (to organization of my personal information) example are plain text files. On my Mac OS X MacVim is use
Re:Creator codes have been deprecated since 10.4 (Score:4, Informative)
Oh... I digress. The RTFA explicitly says that Finder's "Get Info" window still allows to change application to be used to open the file. IOW, I'm on safe side as it is how I usually do it anyway.
P.S.
Evidence provided through an anonymous tip suggests that removal of the influence of creator codes in Snow Leopard was deliberately imposed by management on engineering. Since engineering's hands are tied, bug reports to them are likely to be met with the usual "works as intended" brush-off.
If Apple did it right, then I'm pretty sure one can programmatically change the per-file association. Or probably even with the AppleScript.
After RTFA it seems to me the issue was greatly exaggerated.
Re: (Score:2)
The guy who wrote the article clearly has no idea what he's talking about and probably has never seen how this is done in Unix: it uses 'magic'. :)
So that means that compiler front ends on UN*X systems run file or equivalent code on source files to figure out what language they're in, rather that treating .c files as C, .cpp/.cxx/etc. files as C++, .f files as FORTRAN, etc? :-)
In addition, whilst I think the major UN*X+X11 desktops might determine file types by doing file-style processing on the file, the OS X desktop, for better or worse, doesn't.