Re: Imported UTI taking precedence over Exported UTI
Re: Imported UTI taking precedence over Exported UTI
- Subject: Re: Imported UTI taking precedence over Exported UTI
- From: Matthew LeRoy <email@hidden>
- Date: Fri, 01 Jul 2016 20:58:12 +0000
- Thread-topic: Imported UTI taking precedence over Exported UTI
On 7/1/16, 4:26 PM, "Quincey Morris" <email@hidden> wrote:
>
>On Jul 1, 2016, at 13:03 , Matthew LeRoy <email@hidden> wrote:
>
>
> Just to clarify, there’s only one file extension in question here.
>
>
>
>
>Ah, apologies if I misread the original explanation.
>
>
>
> Our app declares an exported UTI for our file format, while the competitor’s app declares an imported UTI for our file format with the same file extension but with a slightly different UTI
>
>
>
>I think you’re Doing It Wrong™ — or, really, the other (importing) app is. File extensions are a free-for-all, and they’re NOT definitive for the UTI. It’s the other way round.
>
>
>So there’s no question of import/export “precedence” here, because the UTIs are different, and the congruence of the extensions is irrelevant. LS will pick one UTI from the extension based on its own whims, and one of the apps is out of luck.
Ahh, I see. An important distinction that hadn’t quite clicked for me, but makes sense now that you mention it and does explain the behavior we’re seeing.
>
>If the 3rd party app is using a different UTI, it needs to be fixed to use the same UTI as your definitive exported UTI, regardless of extension.
>
>
>I haven’t thought this through carefully, but you might be able to work around the problem by importing the 3rd-party (“wrong”) UTI in your bundle, as well as exporting the correct one. If the role in your bundle is “editor”, the LS may prefer
> your app when both are installed.
>
So as I mentioned briefly before, there doesn’t seem to be any way to prevent another app from ‘hijacking' your file extension and (partially) breaking your app’s ability to open its own files — correct? You can override typeForContentsOfURL:error: to always return *your* UTI for files with that extension, but that only affects the case where you’ve opened the file via right-click -> Open With. It *doesn’t* solve the Open panel issue — where you’ve requested an Open panel for a set of types and passed all of the UTIs your application can open — because the Open panel just queries LS directly for the type of each file it lists, and if LS has chosen a different UTI for your file extension, then those files are going to be grayed out/unselectable. Suppose I modify my app to pass both the “correct” and “incorrect” UTIs to runModalOpenPanel:forTypes:; what’s to prevent the other app (or another app entirely) from declaring a new UTI with the same file extension and having LS choose that UTI instead? Now my Open panel is broken again, until I add that new UTI to the list of types passed to the Open panel. Rinse, repeat. Am I missing something, or is it really as broken as it sounds?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden