Dealing with "deny file-read-data /path/to/icns" when injecting into sandboxed app about colorfulsidebar HOT 7 CLOSED

What exactly is the arbitrary location?

1. I don't see any issues with loading images from locations like Desktop/Documents.
2. Couldn't you just move the image somewhere the app has access to and then load form there?

from colorfulsidebar.

I think the issue is unrelated to the entitlements, since it doesn't work with the save dialogs on a plain (non-sandboxed) app either (as an example, if I open up "Console.app" and hit cmd-O the sidebar item images in the open panel are not replaced), although the extension is indeed loaded into console.app (Console doesn't seem to use the openAndSavePanelService so that too is moot).

My fork does seem to cover both cases of TSidebarItemCell and FI_TSidebarItemCell as yours does (https://github.com/krackers/colorfulSidebar_9/blob/master/colorfulSidebar9/colorfulSidebar9.m), so I'm unsure what the issue might be.

I'll close the issue for now since it seems to be an issue only with my forked version.

from colorfulsidebar.

What version of macOS are you using?

Console does use the openAndSavePanelService.

Have you tried moving the image to a location it can be read?

from colorfulsidebar.

10.9, which is another reason why I closed the issue since I don't want to waste your time trying to debug this.

Have you tried moving the image to a location it can be read?

On 10.9 at least Console is not sandboxed so reading the image isn't an issue there, and the extension is injected without errors. The sidebar is still not updated though which makes me think something else is awry.

from colorfulsidebar.

So if you're using colorfulSidebarX I think you should be able to work around this by placing the image inside the bundle.

Example:
/Library/Application Support/MacEnhance/Plugins/colorfulSidebarX.bundle/Contents/Resources/mydankimage.png

And then adding it to the appropriate icons.plist with a key like this:

<key>mydankimage.png</key>
<array>
	<string>~/Pictures</string>
</array>

To add the functionality to your own build you'd need to add this part into
+ (void)setUpIconMappingDict

// Check if it's a bundle resource
if (image == nil) {
    NSString *keyPath = [key stringByDeletingPathExtension];
    NSString *keyExt = [key pathExtension];
    NSString *bundleResource = [[NSBundle bundleForClass:self] pathForResource:keyPath ofType:keyExt];
    image = [[NSImage alloc] initWithContentsOfFile:bundleResource];
}

The images should then load.

from colorfulsidebar.

Yeah that helps solve the sandboxing issue, although the icon still doesn't load. I think the issue is that FI_TSidebarItemCell is not loaded until the save panel is first opened, by which point all the swizzling has been done. (I verified this by using FScript to inspect the loaded classes before/after the save panel was opened).

EDIT: Oh I think your colorfulSidebarX takes care of this by swizzling NSImage itself and then checking if the superview matches FI_TSidebarItemCell. I'll switch to using this approach, which should make things work. Thank you!

from colorfulsidebar.

Yup, I was able to get it working by swizzling NSImage using

@implementation wb_NSImageView

- (void)_setImageView:(id)arg1 {
    NSObject *aSuper = [self superview];
    if (aSuper) {
        if ([[aSuper className] isEqualToString:@"FI_TListHeaderCellView"]) {
            dispatch_once(&ONCE_FI_TSidebarItemCell, ^ { ZKSwizzle(wb_TSidebarItemCell, FI_TSidebarItemCell); });
        }
    }
    ZKOrig(void, arg1);
}

@end

(I had to check if superview was FI_TListHeaderCellView because attempting to check the classname of self always returned NSImageView. I'm not sure why this is, since i would expect it to return FI_TImageView or something).

from colorfulsidebar.