chockenberry / provisioning Goto Github PK

For a long time, I've had issues with QuickLook showing blank previews of images. Looks like it's because I enabled the QLEnableTextSelection option after installing the Provisioning QL plugin:

http://apple.stackexchange.com/questions/128825/quicklook-blanks-when-displaying-some-images

This is obviously not a problem with the plugin, but perhaps a note of caution could be added to the front page?

Since the Provisioning Quick Look plug-in handles iOS App (IPA) files, it would be beneficial and meaningful to display the app icon (which is archived inside the IPA file) in the following places:

1. Display the app icon as the icon preview Thumbnail (instead of the generic IPA document icon).
2. Display the app icon inside the Quick Look Preview panel - most likely at the top-left of the provisioning profile information, near the app title. For consistency, other non-IPA file types could display their generic document icon in the same position.
3. Display the app icon as the Quick Look Preview (default to 512 x 512 points), when the IPA file contains no provisioning profile. This would apply to all IPA files obtained through iTunes, typically stored here:

~/Music/iTunes/iTunes Media/Mobile Applications/

This concept isn't new – the IPA Quick Look plug-in by Julien Chauveau @julienchauveau has provided the above functionality (items 1 and 3) since 2009. It's located here:

http://code.google.com/p/quicklook-ipa/
https://github.com/julienchauveau/quicklook-ipa

It should be noted, however, that this plug-in hasn't been updated since 2009, and doesn't appear to work on Mavericks 10.9.x. A casual glance at the Console error logs seems to indicate a Sandbox error, but further investigation would be required there.

Secondly, with the release of iOS 7, Apple changed the appearance of all iOS app icons by altering the corner radius of the mask applied to the icon image. (The icon images of iOS apps are square, masked programmatically when displayed on iOS and in iTunes.) The aforementioned plug-in uses a pre-iOS 7-style corner radius.

It may be better to apply an iOS 7-style corner radius, though apparently this isn't as easy as it seems. Some work has been done to determine the new style of corner radius, such as by Manfred Schwind @manide:

http://www.mani.de/backstage/?p=483

Looking at the icon rendering in iTunes 11.1, it looks like app icons are still masked in the pre-iOS 7 style, but it's probably just a matter of time before this changes to the new style.

Thanks!

It would be really useful to mention the provisioning profile type in the info.

If you need info on how to determine these, I can probably submit a pull request.

Regards,

pieter

I added a brew cask for version 1.0.4. Cask is an extension for Homebrew which makes it easy to install applications and QuickLook plugins from the command line.

If you have homebrew and homebrew cask installed, simply

brew cask install provisioning

If you don't have homebrew cask installed,

Install Homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go/install)"

Install Homebrew cask

brew tap phinze/homebrew-cask
brew install brew-cask

Install the Provisioning Quick Look plugin:

brew cask install provisioning

This is a great little tool, which I use regularly for debugging code signing and provisioning issues.

I've noticed that it support .app and .ipa files, but doesn't work for iOS today and watch extensions which have .appex.

I assume this can be added to the Provisioning-Info.plist like how the .app handling is defined, but I'm not sure how to find out the bundle type to add to the LSItemContentTypes.

Xcode stores device information in user defaults:

$ defaults read com.apple.dt.XCode DVTSavediPhoneDevices

This information can't be read by the plug-in since it's now running in a sandbox. The NSUserDefaults class documentation states:

A sandboxed app cannot access or modify the preferences for any other app. (For example, if you add another app's domain using the addSuiteNamed: method, you do not gain access to that app's preferences.)

This information also can't be read using NSTask and NSPipe: the console logs "Sandbox: defaults(####) deny file-read-data" errors when the preference file is accessed.

Hi,

It seems that an awful lot of Quicklook plugins no longer work on High Sierra (or so)...? I tried debugging with:

sudo qlmanage -p <my profile>.mobileprovision

Output is:

Testing Quick Look preview with files:
	<redacted>.mobileprovision
2018-02-28 11:48:28.887 qlmanage[14276:2181130] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x7a03, name = 'com.apple.coredrag'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2018-02-28 11:48:29.108 qlmanage[14276:2181130] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x13c3b, name = 'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.

Any ideas? Just needs a new build?

I'd like to have way to copy the raw plist data in the .mobileprovision file to the clipboard. Unfortunately, I can't find a way to do this with the HTML presented in com.apple.quicklook.satellite process (the thing that the Quick Look daemon uses to display the HTML for the preview.)

Things I've tried:

• Displaying a dialog with the plist data using window.prompt('Here's the plist:", "xml data here"); -- WebKit has a native implementation of the prompt function on the window object, but never calls it.
• Capturing the 'copy' event and using the clipboardData object as described at https://developer.apple.com/library/mac/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/CopyAndPaste.html -- text in the Quick Look web view can't be selected, so there's no way to copy it and generate the event in the first place.
• Presenting the data in a textarea element -- the information can be displayed, but not selected and copied to the clipboard.

The only thing I can think of is copying the data to NSPasteboard at the time the preview is generated. Since there would be no user action prior to this happening, using the plug-in would effectively destroy any current clipboard contents. Not good.

If anyone has any other suggestions, I'd love to hear them.