tags:

views:

499

answers:

5

I've found my devices using IOServiceGetMatchingServices and got the property dictionary like this:

kernResult = IORegistryEntryCreateCFProperties(nextMedia,
                    (CFMutableDictionaryRef *)&props,
                                              kCFAllocatorDefault, 0);

From that dictionary I can extract the informations for the icons:

NSString *bId = [props valueForKeyPath:@"IOMediaIcon.CFBundleIdentifier"];
NSString *rFile = [props valueForKeyPath:@"IOMediaIcon.IOBundleResourceFile"];

Those two give me this (as an example):

com.apple.iokit.IOStorageFamily   (Bundle identifier)
Internal.icns                     (Resource File)

I tried to extract the icon using this method:

NSBundle *bundleWithIcon = [NSBundle bundleWithIdentifier:bId];
NSString *iconPath = [bundleWithIcon pathForResource:rFile ofType:nil];

But bundleWithIcon is nil.

Is this even the correct method to get the icon?

I think I have to somehow load the bundle to be able to load it with bundleWithIdentifier, how can I do this?

PS: There's another question which (I think) tries to ask the same thing, but only asks for bundles, not if this is the correct way.

A: 

Those two give me this (as an example):

com.apple.iokit.IOStorageFamily (Bundle identifier) Internal.icns (Resource File)

I tried to extract the icon using this method:

NSBundle *bundleWithIcon = [NSBundle bundleWithIdentifier:bId]; NSString *iconPath = [bundleWithIcon pathForResource:rFile ofType:nil];

But bundleWithIcon is nil.

bundleWithIdentifier: requires you to have already created an NSBundle instance for a bundle with that identifier; it only looks up a previously-created instance. Therefore, you'll need to find the bundle in the file-system and instantiate it by pathname. Fortunately, you seem to already have the link to the question about that.

Peter Hosey
Trouble is, to look through every bundle takes ~2 seconds. Shouldn't it be possible to let IOKit load the bundle, so that there is an instance I can access?
Georg
You could simply instantiate all the kext bundles in /S/L/E once, perhaps in the background a few seconds after your app finishes launching. After you do that, bundleWithIdentifier: will work, as long as the bundle identifier you get from I/O Kit is that of a kext.
Peter Hosey
That would take a long time to start the application, which has to display the icon right at the start.
Georg
A: 

Just recently Andrew Myrick answered a similar question on the darwin-dev mailing list:

KextManagerCreateURLForBundleIdentifier() in <IOKit/kext/KextManager.h> may be of use, though I believe it only works for kexts that are either 1) loaded, or 2) in /S/L/E/. Here is the Snow Leopard headerdoc:

/*!
 * @function KextManagerCreateURLForBundleIdentifier
 * @abstract Create a URL locating a kext with a given bundle identifier.
 *
 * @param    allocator
 *           The allocator to use to allocate memory for the new object.
 *           Pass <code>NULL</code> or <code>kCFAllocatorDefault</code>
 *           to use the current default allocator.
 * @param    kextIdentifier
 *           The bundle identifier to look up.
 *
 * @result
 * A CFURLRef locating a kext with the requested bundle identifier.
 * Returns <code>NULL</code> if the kext cannot be found, or on error.
 *
 * @discussion
 * Kexts are looked up first by whether they are loaded, second by version.
 * Specifically, if <code>kextIdentifier</code> identifies a kext
 * that is currently loaded,
 * the returned URL will locate that kext if it's still present on disk.
 * If the requested kext is not loaded,
 * or if its bundle is not at the location it was originally loaded from,
 * the returned URL will locate the latest version of the desired kext,
 * if one can be found within the system extensions folder.
 * If no version of the kext can be found, <code>NULL</code> is returned.
 */
CFURLRef KextManagerCreateURLForBundleIdentifier(
    CFAllocatorRef allocator,
    CFStringRef    kextIdentifier);

Note that prior to Snow Leopard, it may only work for kexts in /S/L/E; the API existed, but there was no headerdoc describing its behavior.

For me this worked really well on Mac OS X 10.5.

Georg
+2  A: 

You could use NSWorkspace.
The initial image is 32x32, but it has representations for the other sizes and will scale accordingly

NSWorkspace * ws = [NSWorkspace sharedWorkspace];
NSImage * icon = [ws iconForFile:@"/Volumes/Whatever"];
NSLog(@"%@", [icon representations]); // see what sizes the icon has
icon.size = NSMakeSize(512, 512);
Zydeco
This does only work for mounted volumes, I need it for unmounted devices too.
Georg
A: 

this may help you. (or maybe not)...

in playing around with the 'ioreg' command i came across something that reminded me of your question, and so I'll post it:

try issuing the following command:

ioreg -c IOMedia -x

which will yield a big mess of output which looks something like this:

  |     +-o IOBlockStorageDriver  <class IOBlockStorageDriver, registered, matched, active, busy 0, retain 7>
  |       +-o Apple read/write Media  <class IOMedia, registered, matched, active, busy 0, retain 9>
  |         | {
  |         |   "Removable" = Yes
  |         |   "BSD Unit" = 0x4
  |         |   "IOBusyInterest" = "IOCommand is not serializable"
  |         |   "BSD Minor" = 0xc
  |         |   "Ejectable" = Yes
  |   |         |   "BSD Name" = "disk4"
  |         |   "Leaf" = No
  |         |   "IOMediaIcon" = {"CFBundleIdentifier"="com.apple.iokit.IOStorageFamily","IOBundleResourceFile"="Removable.icns"}
  |         |   "Preferred Block Size" = 0x200
  |         |   "Whole" = Yes
  |         |   "Open" = Yes
  |         |   "Size" = 0x100000
  |         |   "Writable" = Yes
  |         |   "Content" = "Apple_partition_scheme"
  |         |   "IOGeneralInterest" = "IOCommand is not serializable"
  |         |   "Content Hint" = ""
  |         | }         |   "BSD Major" = 0xe

this all leads me to believe (and thus here blindly recommend that you investigate) that if you traverse the io registry tree matching against 'IOMedia' you can get property dictionaries that will contain an entry keyed "IOMediaIcon," which itself appears to be a collection informing you of a bundle identifier and a resource file name.

not to say that this is easy... but look into the FireWire SDK for all the example code you may need... in any case it's probably "better" than hard-coding pre-filled paths (which might disappear in future OS releases).

|K<

kent
I'm already using this IOMediaIcon property, as can be seen in my question. The trouble is, that I can't locate the icon afterwards without having some hard-coded paths.
Georg
@gs: my bad... will read more closely next time. thx for being so friendly. |K<
kent
A: 

A volume without a custom icon is going to be displayed with one of the OS's generic icons which you've hard-coded paths to here. A volume with a custom icon is going to store that icon on its filesystem, and if it's not mounted, finding it becomes entirely your job.

Azeem.Butt
What can I do so that I don't have to hard-code the paths?
Georg