I have an application that breaks in HiDPI mode unless I chose "get Info" in finder and there tick the "open in low resolution" checkbox. Fixing the application is not an option as it was made using authoring software that is no longer really actively maintained by its vendor.
Now here is the thing: When I take the application, put it on the desktop, zip it and afterwards set the "open in low resolution" checkbox to true, delete the application and unzip the original one the checkbox stays checked. So wherever OS X stores the property "open in low resolution" it's not along with the file. That means that when distributing the application to other Retina Mac systems it'll be broken again until manually checking that checkbox on each system.
I found that the Info.plist
got a NSHighResolutionCapable
property and I added that Boolean
to my app's Info.plist
and set it to false
but to no avail. That seems not to be equivalent to the "open in low resolution" option.
The linked document sais that: If the “Open in Low Resolution” checkbox is selected by default you can change the default by: Setting the NSHighResolutionCapable attribute to YES, in the Info.plist Well, the reverse does not work... What I'd like is an out of the box solution. I'd like to avoid that customers need to configure this on their own. It should simply be set when unzipping the application.
So two questions:
a) Is it possible to configure what equals the "open in low resolution" checkbox being checked along with the file - e.g. in the Info.plist
?
b) Where does OS X store the choices I made for the "open in low resolution" checkboxes I get to via Finder's Info screen?
EDIT December, 7 (added plist details):
As seen in plist editor:
As seen in modern Xcode on Mavericks:
The only difference is the name that's displayed. Xcode calls it "High Resolution Capable" while in the file it's still really "NSHighResolutionCapable"
Here is the portion of the file info dialog we care for:
I'm not currently in a position to check, but it's likely that the presence or absence of the NSHighResolutionCapable
key is cached in the Launch Services database. That's where most properties of an app which are specified in the Info.plist are stored. The fact that copying the app to a USB thumb drive worked seems to confirm that theory.
You might search the output of the following command for your app's bundle ID and then see if there's anything obviously related to high resolution capability:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -dump
If there is, then, after you modify an app's Info.plist, it might work to do:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /path/to/the/modified.app
If not, then perhaps the more powerful:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -seed
If none of that helps, then (from our above comments) it seems that trying in a new user account works.
Takes a little more finesse, you need to reset the -user- domain.
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /Applications -all local,user
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With