Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '10.6: Use Automator to ease document-app assignments' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.6: Use Automator to ease document-app assignments
Authored by: robg on Sep 23, '09 12:21:41PM

The problem isn't just BBEdit. The problem is, at least in my testing, that a majority of the apps aren't using UTIs, so nearly every app will exhibit this problem.

Yes, it's not directly Apple's fault, but it's clearly Apple that turned off creator codes in 10.6. To a user, the fault will appear to Apple's.

-rob.



[ Reply to This | # ]
Are UTIs read-only?
Authored by: hamarkus on Sep 23, '09 01:00:54PM

And thus not useable for the purpose suggested here. From a post at Appleinsider:
Apple's docs on kMDItemContentType:

kMDItemContentType: The UTI pedigree of a file. A CFString.

For example, a jpeg image file will have a value of public.jpeg/public.image/public.data. The value of this attribute is set by the MDImporter. Changes to this value are lost when the file attributes are next imported.

So it can be written to, but the value will be discarded by Spotlight. Not quite read only, but effectively so.



[ Reply to This | # ]
Re: 10.6: Use Automator to ease document-app assignments
Authored by: Uncle Asad on Sep 23, '09 03:55:57PM

The AppleInsider article is just plain wrong when it comes to this specific part.

UTIs "replace" file types and filename extensions, and, unless you happen to be dealing with a file that only one application knows how to edit (com.robservatory.robg-app.robg-custom-file-format), are completely ineffective for application bindings. If your application writes files in a common format, like public.rtf, that doesn't help you at all. It says you *can* open the file, but so can dozens of other apps, and you can't claim default ownership of the file without rendering the file unopenable (practically speaking) by other applications. To use the method AppleInsider suggests, you'd have to say that your RTF files have the UTI of com.robservatory.robg-app.rtf *and* change the filename extension to something like ".robgrtf" in order to prevent Mac OS X and other applications from overriding your UTI declarations with the standard "public.rtf" one.

Yes, that's right; UTIs aren't associated with a file at all, not like a type code was filesystem metadata that moved with the file, or the way a filename extension is part of the file's name. No, UTIs are a higher level mapping system set up by the OS, a way to map filename extensions and file types into a common system. UTIs are defined in an application's plist (or by Apple in the OS) in reference to either file types or filename extensions; that is, I say my app can open files of type 'RTF ' and extension "rtf" and that any files that match these criteria have the UTI of public.rtf. Again, the UTI is not associated with the file itself the way, nor is it a way of mapping ownership of the file to an application. All it does is say that "RTF " and ".rtf" are both the same type of file, "public.rtf".

Sure, you can override the default application binding (of whatever app Apple decides has precedence for "public.rtf") by using Open With in the Finder (and on a permanent basis via the Open With in the Get Info window, which is what this Automator action simulates), but you're not using UTIs; you're adding separate filesystem metadata stored in com.apple.ResourceFork.



[ Reply to This | # ]
Re: 10.6: Use Automator to ease document-app assignments
Authored by: hamarkus on Sep 24, '09 06:08:00AM

"you're adding separate filesystem metadata stored in com.apple.ResourceFork"
Can an application write into this location (when saving a file)?



[ Reply to This | # ]
Re: 10.6: Use Automator to ease document-app assignments
Authored by: Uncle Asad on Sep 24, '09 01:47:17PM
According to Peter Hosey (on the development teams of Adium and Growl), there's no public API for writing the override resource. In theory an app could reverse-engineer the function and use it to write the resource, but that could stop working (and maybe even break the app) at any time.

[ Reply to This | # ]