On Feb 2, 2015, at 15:21 , Graham Cox <graham....@bigpond.com> wrote:
>
> The app supports 4 document types. It imports all 4 UTIs corresponding to
> these types, but it exports only two.
This doesn’t sound right to me. My understanding is that a UTI string is one of
three things:
1. A standard UTI, as defined by Apple. The most common of these have symbolic
names, the rest you have to supply a string with the documented contents.
2. An app-specific UTI, as defined by your app. “Defined” means that your app
owns and knows the format of the data in a file that has this UTI. Such a UTI
is *exported* by your app, in the Exported UTIs section of the plist. It may be
used by just this app, or by other apps as well.
3. A non-standard UTI, as defined by some other app or standard. Such a UTI is
*imported* by your app if it want to recognize it, in the Imported UTIs section
of the plist. You include it to ensure that Launch Services knows about the
UTI, even if the defining application isn’t on your Mac.
So, if your app has 4 document types with UTIs, then there should only be 4 UTI
declarations total, regardless of whether they’re exported or imported. OTOH,
I’ve never seen any evidence that Launch Services cares if a definition is in
both places.
> My Save dialog is not showing the format pop-up
> Alternatively, adding that type as an exported UTI and keeping its role as
> "editor", I expected to see the format pop-up, but I don't. Why? Don't know.
I can’t tell from the documentation whether there should be a different
NSDocument subclass for each “natural” document type. The introductory
discussion seems to say so:
https://developer.apple.com/library/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/Designing/Designing.html
<https://developer.apple.com/library/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/Designing/Designing.html>
like this:
> A Data Model Corresponds to a Document Type
>
> … Each document object is a custom subclass of NSDocument designed
> specifically to handle a particular type of data model. Document-based apps
> are able to handle one or more types of documents, each with its own type of
> data model and corresponding NSDocument subclass. Apps use an information
> property list file, which is stored in the app’s bundle and named, by
> default, <appName>-Info.plist, to specify information that can be used at
> runtime. Document-based apps use this property list to specify the document
> types the app can edit or view.
The rest of the document seems to contradict this by repeatedly referring to
multiple types per subclass, but it *could* mean that the others are all
import/export types. It’s possible the pop-up only appears if there’s more than
one subclass.
> I do not have a NSExportableTypes entry - in fact I don't think I've heard of
> that before, I thought it was figured out from the UTIs and/or the document
> types (who knows, it's a rabbit warren of interconnected dependencies with no
> clear canonical source of information that I can see).
Exactly. I never remember this either. It’s for types you can save to, but not
open as an editor.
> I could try one step up at the URL level, which may be enough, without having
> to go as high as the document controller level.
I’d go to the highest level — specifically the top level that has “fileType” as
an explicit parameter. Otherwise you risk inconsistency between use of the
original fileType and your substituted fileType *after* you return from
whatever method you override.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
