UTI's and document packages

  • Hi,

    I know how to create document packages the pre-Leopard way. For
    Leopard however, I believe the preferred way to define your app's
    Info.plist would be to use UTI's, which for the app at hand also makes
    much more sense than manually enumerating all the file formats enjoys
    being fed. However, if you include the LSItemContentTypes key, with
    its associated array of identifiers, in the plist, then the
    LSTypeIsPackage key is ignored and the finder won't treat the document
    folders as a document package. I tried setting the value of
    UTTypeConformsTo in UTExportedTypeDeclarations to public.composite-
    content hoping that that would result in the desired behaviour, but no
    such luck.

    Is there any way to define the info plist's document types using the
    new recommended UTI based way, and still have your document packages
    correctly displayed by the finder and related services?

    -António

    -----------------------------------------------------------
    What you have inside you expresses itself through both your
    choice of words and the level of energy you assign to them.
    The more healed, whole and connected you feel inside,
    the more healing your words will be.

    --Rita Goswami
    -----------------------------------------------------------
  • On 26 Nov 2007, at 10:21, Antonio Nunes wrote:

    > Is there any way to define the info plist's document types using the
    > new recommended UTI based way, and still have your document packages
    > correctly displayed by the finder and related services?

    Ok, after some more rambling through the docs I'm happy to be able to
    answer my own question:

    There is a UTI type identifier living by the name of
    "com.apple.package". After adding that under the "UTTypeConformsTo"
    heading the document directories are treated as packages.

    This is what I have now, and it appears to work:

    <key>UTExportedTypeDeclarations</key>
    <array>
      <dict>
      <key>UTTypeConformsTo</key>
      <array>
        <string>public.item</string>
        <string>public.composite-content</string>
        <string>com.apple.package</string>
      </array>

    For I'm a jolly good fellow 3x, etc,
    António

    ----------------------------------------------------
    There is a world of difference between
    searching for happiness and choosing
    to be happy.
    ----------------------------------------------------
  • On 11/26/07 10:21 AM, Antonio Nunes said:

    > Is there any way to define the info plist's document types using the
    > new recommended UTI based way, and still have your document packages
    > correctly displayed by the finder and related services?

    Glad you have found your own answer, but one thing you should
    additionally do is set the 'bundle bit' of your documents.  This way,
    the Finder will not show them as folders, even if your application is
    not present (say if you send a document to someone that doesn't have
    your app).

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • On Nov 26, 2007, at 11:52 AM, Sean McBride wrote:

    > On 11/26/07 10:21 AM, Antonio Nunes said:
    >
    >> Is there any way to define the info plist's document types using the
    >> new recommended UTI based way, and still have your document packages
    >> correctly displayed by the finder and related services?
    >
    > Glad you have found your own answer, but one thing you should
    > additionally do is set the 'bundle bit' of your documents.  This way,
    > the Finder will not show them as folders, even if your application is
    > not present (say if you send a document to someone that doesn't have
    > your app).

    Sorry if this sounds dense, but shouldn't all this happen
    automagically when one provides a UTI for a document type and enables
    the "package" option in the "Properties" tab of Xcode's Info pane?

    sherm--

    Web Hosting by West Virginians, for West Virginians: http://wv-www.net
    Cocoa programming in Perl: http://camelbones.sourceforge.net
  • On 26 Nov 2007, at 17:14, Sherm Pendley wrote:

    > Sorry if this sounds dense, but shouldn't all this happen
    > automagically when one provides a UTI for a document type and
    > enables the "package" option in the "Properties" tab of Xcode's Info
    > pane?

    Apparently not, although that would seem natural to me too. But I had
    a look at files saved by my app and the bundle bit is not set. I'll
    have to look into that too then.

    -António

    -----------------------------------------
    Forgiveness is not an occasional act;
    it is a permanent attitude.

    --Martin Luther King, Jr
    -----------------------------------------
  • On 26 Nov 2007, at 16:52, Sean McBride wrote:
    >
    > Glad you have found your own answer, but one thing you should
    > additionally do is set the 'bundle bit' of your documents.  This way,
    > the Finder will not show them as folders, even if your application is
    > not present (say if you send a document to someone that doesn't have
    > your app).

    Thanks Sean. I'll look into that.

    -António

    -----------------------------------------------------------
    What you have inside you expresses itself through both your
    choice of words and the level of energy you assign to them.
    The more healed, whole and connected you feel inside,
    the more healing your words will be.

    --Rita Goswami
    -----------------------------------------------------------
  • On 26 Nov 2007, at 19:21, Antonio Nunes wrote:

    >> Glad you have found your own answer, but one thing you should
    >> additionally do is set the 'bundle bit' of your documents.  This way,
    >> the Finder will not show them as folders, even if your application is
    >> not present (say if you send a document to someone that doesn't have
    >> your app).
    >
    > Thanks Sean. I'll look into that.

    So, after looking for solutions I found some older code, but it used
    deprecated functions, so I had to adapt it. This is what I came up
    with for setting or clearing the bundle bit at a given path:

    OSErr ANSetBundleBitAtPath(NSString *path, BOOL flag)
    {
    FSRef fsRef;
    OSErr osErr;
    osErr=FSPathMakeRef((UInt8 *)[path UTF8String], &fsRef, NULL);
    if (!osErr) {
      FSCatalogInfo info;
      osErr=FSGetCatalogInfo(&fsRef,
                                 kFSCatInfoFinderInfo,
                                 &info,
                                 NULL,
                                 NULL,
                                 NULL);
      if (!osErr) {
      FileInfo *fInfo = (FileInfo *)info.finderInfo;
      if (flag) {
        fInfo->finderFlags |= kHasBundle;
      } else {
        fInfo->finderFlags &= ~kHasBundle;
      }

      osErr = FSSetCatalogInfo(&fsRef, kFSCatInfoFinderInfo, &info);
      }
    }
    return osErr;
    }

    1. I'm not sure UTF8String for the path is the correct encoding.
    2. The path could of course be either a folder or a file, but it
    shouldn't matter whether the code coerces it to FileInfo or FolderInfo
    in this case.
    3. I take it there is no Apple provided Cocoa API for this purpose.
    (At least, I couldn't find any.)
    4. Is there otherwise anything wrong with this code, or anything I
    should be aware of?

    -António

    ----------------------------------------------------
    It isn't so important to do great things,
    as to do what you do with great love.
    ----------------------------------------------------
  • On 27 Nov 2007, at 09:36, Antonio Nunes wrote:

    > 1. I'm not sure UTF8String for the path is the correct encoding.

    -UTF8String and -cString are *never* right for paths.  You should be
    using
    -fileSystemRepresentation.

    > 2. The path could of course be either a folder or a file, but it
    > shouldn't matter whether the code coerces it to FileInfo or
    > FolderInfo in this case.

    Since you're talking about setting the bundle bit, it must be a
    FolderInfo, surely?  In fact, it would be a good thing to check for a
    folder and error out if you don't get one.

    > 3. I take it there is no Apple provided Cocoa API for this purpose.
    > (At least, I couldn't find any.)
    > 4. Is there otherwise anything wrong with this code, or anything I
    > should be aware of?

    I don't know that the finderInfo structure is byte-swapped when it's
    retrieved, even via FSGetCatalogInfo().  As a result, you might need
    to check whether you're on an Intel machine or not.

    AFAIK the only other option you have besides these functions is the
    getattrlist()/setattrlist() functions.  But FSGet/SetCatalogInfo() has
    the advantage that the Carbon layer includes emulation code to provide
    support for filesystems other than HFS and HFS+.  Since the emulation
    is based on the AppleDouble format, it's very likely that you can
    successfully set the bundle bit on a folder on e.g. a FAT filesystem
    using those APIs (I haven't tried it myself).

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 11/27/07 9:36 AM, Antonio Nunes said:

    > 4. Is there otherwise anything wrong with this code, or anything I
    > should be aware of?

    You can also just use the MoreFilesX sample code (practically a library,
    really), and call:

      FSChangeFinderFlags (&theFsRef, true, kHasBundle);

    That protects you from caring about the details.

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • On 27 Nov 2007, at 10:58, Alastair Houghton wrote:

    > -UTF8String and -cString are *never* right for paths.  You should be
    > using
    > -fileSystemRepresentation.

    Thanks, I adjusted that.

    >
    >> 2. The path could of course be either a folder or a file, but it
    >> shouldn't matter whether the code coerces it to FileInfo or
    >> FolderInfo in this case.
    >
    > Since you're talking about setting the bundle bit, it must be a
    > FolderInfo, surely?  In fact, it would be a good thing to check for
    > a folder and error out if you don't get one.

    Why yes, I suppose setting the bundle bit on a flat file doesn't make
    much sense ... conceptually, at least on Mac OS X. But I do not think
    in practice anything is wrong with the implementation. This would seem
    to be supported by the FSChangeFinderFlags function from MoreFilesX
    that Sean McBride was kind enough to point out.

    >> 3. I take it there is no Apple provided Cocoa API for this purpose.
    >> (At least, I couldn't find any.)
    >> 4. Is there otherwise anything wrong with this code, or anything I
    >> should be aware of?
    >
    > I don't know that the finderInfo structure is byte-swapped when it's
    > retrieved, even via FSGetCatalogInfo().  As a result, you might need
    > to check whether you're on an Intel machine or not.

    FSChangeFinderFlags doesn't do it, so I suppose it's ok. On the other
    hand since the code stems from 2005, maybe it is out of date. Anyone
    care to comment on this with any authority? (My gut tells me it's not
    a concern.)

    António

    -----------------------------------------
    Forgiveness is not an occasional act;
    it is a permanent attitude.

    --Martin Luther King, Jr
    -----------------------------------------
  • On 27 Nov 2007, at 15:41, Sean McBride wrote:

    > You can also just use the MoreFilesX sample code (practically a
    > library,
    > really), and call:
    >
    > FSChangeFinderFlags (&theFsRef, true, kHasBundle);
    >
    > That protects you from caring about the details.

    Thanks, that is a really useful set of code. I see you pointed to this
    recently in another thread, but it escaped me in my search for the
    Holy Grail of Bundle Bit Bouncing.

    Onwards we march (or plough, as the occasion may be).

    António

    -----------------------------------------
    Forgiveness is not an occasional act;
    it is a permanent attitude.

    --Martin Luther King, Jr
    -----------------------------------------
previous month november 2007 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