Inside Snow Leopard's UTI: Apple fixes the Creator Code

2

Comments

  • Reply 21 of 42
    Quote:
    Originally Posted by success View Post


    When I do this I click the button once in the getinfo window and from that point on all those file types will open with my preferred app. In failing that I right-click on the file -> open with [select 'always open with appname'] and I'm done. Sometimes the correct file type icon still doesn't show up but it doesn't affect the opening process. A reboot always fixes the icon issue. This is with SL.



    What's the problem?



    The discussion above is actually about something more sophisticated than what you are thinking. The mac users were used to creating say an RTF in iwork, another RTF in word and another in textedit and having the file remember which app created it so when they open it or send it to another user, the user's system will automatically open it in the application it was created on. this is far more complex than say opening all RTFs with textedit.
  • Reply 22 of 42
    successsuccess Posts: 1,040member
    Quote:
    Originally Posted by samanjj View Post


    The discussion above is actually about something more sophisticated than what you are thinking. The mac users were used to creating say an RTF in iwork, another RTF in word and another in textedit and having the file remember which app created it so when they open it or send it to another user, the user's system will automatically open it in the application it was created on. this is far more complex than say opening all RTFs with textedit.



    No it's not. If the app opens with the correct app on your machine it will do so on another. If they don't have that same app then it's a mute point.



    Before you send the app to someone else you will know what app it opens with. If it's incorrect you do what I do above. You can also choose to have it open with a non default app.



    What's so difficult about this solution?
  • Reply 23 of 42
    Quote:
    Originally Posted by Ununnilium View Post


    Can anyone describe how it's possible to assign the UTI for individual files (other than changing the file extension, or the 32-bit type)? If there's no way to do this, then it seems like the idea of Apple "fixing" creator codes is incorrect.



    There is no official way of changing the type/creator code either, you needed third-party software for this.
  • Reply 24 of 42
    Quote:
    Originally Posted by sdfisher View Post


    UTIs replace file type codes, and do so well. However, unless the data being generated is in a proprietary format that only a single application will support, they do not replace creator codes.



    If the file type is specific enough, eg, an Acorn-Photoshop-jpeg, the file will open in Acorn if Acorn is present, if Acorn is not present but PS is, in PS, and if none are present in the default app for jpegs. Can you tell me what more you could achieve with Creator Codes?



    EDIT: Reading more comments, there seems to be some credence to the view that UTIs are a one-way street only, in that you can declare a proprietary extension (like .markdown or .acorn) and applications themselves to conform to eg, acorn.photoshop.jpeg.image.... but you cannot declare a file with an extension of .jpeg to have a UTI of acorn.photoshop.jpeg.image....

    The article suggest otherwise but I am wondering whether this is one of those in-theory-yes-in-practice-no situations.
  • Reply 25 of 42
    Quote:
    Originally Posted by noirdesir View Post


    The article suggest otherwise but I am wondering whether this is one of those in-theory-yes-in-practice-no situations.



    No, it's a no-always-no situation. The author of the article had a particular article he wanted to write, and the facts don't matter to that.
  • Reply 26 of 42
    Quote:
    Originally Posted by physguy View Post


    Both of these don't quite hit the nail on the head.



    ...and then you don't address my point at all. How do I, as an application, save a document with a common file extension and a specific UTI, changing the UTI but not the extension for different documents to fit the needs of the user?
  • Reply 27 of 42
    Quote:
    Originally Posted by sdfisher View Post


    No, it's a no-always-no situation. The author of the article had a particular article he wanted to write, and the facts don't matter to that.



    You don't understand what I mean with theory.

    In theory, the UTIs could be used as file metadata, as an extended form of the type metadata. This would fit into the idea of UTIs. And that is what I mean with theory: fitting into the idea.
  • Reply 28 of 42
    Quote:
    Originally Posted by sdfisher View Post


    No, it's a no-always-no situation. The author of the article had a particular article he wanted to write, and the facts don't matter to that.



    I don't get what people think is missing from the UTI implementation. If you set the file's metatdata kMDItemContentType to a specific 'application', e.g. com.adobe.pdf, it can be associate with adobe reader (or other like preview) as the user desires while public.pdf is associated with other applications (or not). If you create your on pdf and put the UTI com.myspecialpdf.pdf in the metatdata it will always be opened with your specialpdf app. Or, the user can say I don't like specialpdf and associate that UTI with Preview or Adobe Reader, or whatever.



    What is missing?
  • Reply 29 of 42
    Quote:
    Originally Posted by noirdesir View Post


    You don't understand what I mean with theory.

    In theory, the UTIs could be used as file metadata, as an extended form of the type metadata. This would fit into the idea of UTIs. And that is what I mean with theory: fitting into the idea.



    Actually, I did understand. Apple's missing an important piece of the puzzle that prevents it from working.



    Unless you meant "if Apple provided the right tools."
  • Reply 30 of 42
    Quote:
    Originally Posted by physguy View Post


    I don't get what people think is missing from the UTI implementation. If you set the file's metatdata kMDItemContentType to a specific 'application', e.g. com.adobe.pdf, it can be associate with adobe reader (or other like preview) as the user desires while public.pdf is associated with other applications (or not). If you create your on pdf and put the UTI com.myspecialpdf.pdf in the metatdata it will always be opened with your specialpdf app. Or, the user can say I don't like specialpdf and associate that UTI with Preview or Adobe Reader, or whatever.



    What is missing?



    kMDItemContentType is a read only property set by Spotlight.
  • Reply 31 of 42
    Quote:
    Originally Posted by sdfisher View Post


    ...and then you don't address my point at all. How do I, as an application, save a document with a common file extension and a specific UTI, changing the UTI but not the extension for different documents to fit the needs of the user?



    ignore<I did address your point. You set the kMDItemContentType in the files metadata to your UTI 'com.myspecialpdf.pdf' and set the file extension to .pdf and away you go. Are you asking how the end-user changes the UTI of a given file? If so, why would they want to do that? If an end user wants to assign a given UTI to a given application see the preference pane shown above. If and end user want to set a specific file to open with a specific app then use the Finder's built in controls.>



    I though the kMDItemContentType could also be set by the program at file creation time.
  • Reply 32 of 42
    Quote:
    Originally Posted by physguy View Post


    ignore<I did address your point. You set the kMDItemContentType in the files metadata to your UTI 'com.myspecialpdf.pdf' and set the file extension to .pdf and away you go. Are you asking how the end-user changes the UTI of a given file? If so, why would they want to do that? If an end user wants to assign a given UTI to a given application see the preference pane shown above. If and end user want to set a specific file to open with a specific app then use the Finder's built in controls.>



    I though the kMDItemContentType could also be set by the program at file creation time.



    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 33 of 42
    Quote:
    Originally Posted by noirdesir View Post


    There is no official way of changing the type/creator code either, you needed third-party software for this.



    Untrue.



    SetFile -c "R*ch" -t "TEXT" ~/Desktop/somefile



    Will give somefile BBEdit's creator code and a text file type. (SetFile is still present in Snow Leopard, ironically enough, though of course it can set other attributes, such as visibility, which are still supported.)
  • Reply 34 of 42
    Quote:
    Originally Posted by michaelb View Post


    Untrue.



    SetFile -c "R*ch" -t "TEXT" ~/Desktop/somefile



    Will give somefile BBEdit's creator code and a text file type. (SetFile is still present in Snow Leopard, ironically enough, though of course it can set other attributes, such as visibility, which are still supported.)



    What I meant is that there is no Apple-provided GUI for this, which means that Apple thinks you should not really need to change it.
  • Reply 35 of 42
    Thanks for the article and all the responses.

    I hope there is a work around for this or Apple fixes it. I have a hundreds of .eps files from clients & myself that were created with different applications, e.g., photoshop, illustrator, freehand, quark. Up until 10.6, in the Finder I could easily tell which application created it. Now, forget it. They all show up as belonging to the ONE application that I indicate. This is a step back.

    I am not a programmer (console is voodoo to me) just a designer who has been using the mac platform since 1988...
  • Reply 36 of 42
    Quote:
    Originally Posted by sutes View Post


    UTIs do not replace Creator Codes.



    UTIs are types. Creator Codes specify the application that created the document; it's not a type.



    Very true. The article makes it sound like UTIs mechanism is supposed to replace both file type and application association but in reality UTIs - and this is by design - do not even try to solve the document-application association problem, which old creator code did very nicely.



    Snow Leopard does not respect the creator code and does not provide a suitable replacement - what genius came up with that idea?
  • Reply 38 of 42
    Quote:

    The Pasteboard's use of UTI was introduced above. It shouldn't be surprising that iPhone 3.0 also uses UTI in its new copy and paste support. If you were wondering why Apple "took so long" to bring that feature to the iPhone, it's because the platform opted for a long term, robust solution rather than a quick and dirty kluge impacted by security issues.



    iPhone OS is descended from desktop OS X so surely UTI support would have already been built in?
  • Reply 39 of 42
    Arstechnica posted a Siracusa's article that frames the whole UTIs/type/creator issue very well:

    http://arstechnica.com/staff/fatbits...ta-madness.ars
  • Reply 40 of 42
    This may be a n00b comment? but at what point in the developer builds of SL were creator codes boxed? Weren't their fates known well before the GM?
Sign In or Register to comment.