• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
LSCopyAllRoleHandlersForContentType is unhelpful (Was: Content types processable by an application)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LSCopyAllRoleHandlersForContentType is unhelpful (Was: Content types processable by an application)


  • Subject: LSCopyAllRoleHandlersForContentType is unhelpful (Was: Content types processable by an application)
  • From: Dave DeLong <email@hidden>
  • Date: Sun, 31 Oct 2010 21:26:47 -0600

So, after playing around some more, I've gone ahead with parsing the output of lsregister -dump to acquire a list of all known UTIs, and then figuring out what applications can handle those types.  (It's a bit longer, but it gets me the information I need)

However, I've noticed something interesting.  LSCopyAllRoleHandlersForContentType() sometimes returns totally unhelpful information.

For example:

CFArrayRef bundleIDs = LSCopyAllRoleHandlersForContentType(CFSTR("com.apple.iwork.pages.pages"), kLSRolesAll);
NSLog(@"%@", (NSArray *)bundleIDs);

This logs:

(
	com.apple.local-library
)

If I then run this bundle identifier through -[NSWorkspace absolutePathForAppBundleWithIdentifier:], I get NULL.

Currently, my way around this would be to find (via an NSMetadataQuery) a file with this UTI in its kMDItemContentTypeTree, then use LSCopyApplicationURLsForURL().  But this seems like a lot of extra work just to find which application opens (in this case) pages files (yes, I know that it's Pages.app, but this happens for many other content types as well; 56 others, to be exact [on my machine]).

Any suggestions?

Thanks,

Dave

On Oct 30, 2010, at 5:16 PM, Dave DeLong wrote:

> Hi everyone,
>
> Given an application path (or NSBundle to an application, etc), is there a way to easily/efficiently determine what content types that application can open?
>
> My initial attempt was to read the applications Info.plist file and extract the content types listed under the kUTExportedTypeDeclarationsKey key.  However, there are some flaws with this approach which I haven't been able to work around.
>
> 1.  Not all applications use this key.  For example, BBEdit does not, but instead lists a whole bunch of recognized file extensions.
> 2.  UTIs are case-sensitive.  Pages, for example, lists "com.apple.iWork.Pages.pages" as an exported content type, yet no Pages document actually has that type listed in its content type tree.  Documents use "com.apple.iwork.pages.pages", which is defined by the iWork quicklook generator (at /Library/QuickLook/iWork.qlgenerator).
>
> In know that with some of the LaunchServices functions (LSCopyApplicationURLsForURL(), LSCopyApplicationForMIMEType(), etc), I can get the applications that can open a file (or a file type), but I'd like to do the inverse.  (Perhaps I'll have to resort to parsing the output of `lsregister -dump`?)
>
> Essentially, what I'm trying to do is show a list of applications, and then for each application, show a list of files that that application can open (at least as a Reader, not necessarily as an Editor).  Both of these lists are retrieved by Spotlight (NSMetadataQuery).
>
> Any suggestions?
>
> Thanks,
>
> Dave
_______________________________________________

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

References: 
 >Content types processable by an application (From: Dave DeLong <email@hidden>)

  • Prev by Date: Re: audio-specific UI component libraries for Cocoa?
  • Previous by thread: Content types processable by an application
  • Next by thread: Programmatic initialization of a NSManagedObject with a Relationship
  • Index(es):
    • Date
    • Thread