On 7/1/16, 4:26 PM, "Quincey Morris" <quinceymor...@rivergatesoftware.com> wrote:
> >On Jul 1, 2016, at 13:03 , Matthew LeRoy <mle...@minitab.com> 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 (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
