> On Mar 14, 2019, at 17:20, René J.V. Bertin <[email protected]> wrote:
>
>> Apple requires each app to specify that it supports Retina mode.
>
> AFAIK applications have always existed that set NSPrincipalClass to
> NSApplication; do these now behave incorrectly on high-dpi screens if they
> don't contain any modifications to their code? Somehow I doubt that.
As far as I know, no. My remark above referred mainly to apps that do not use
NSApplication. Those that use NSApplication already get Retina enabled since
they specify NSPrincipalClass in Info.plist.
>> MacPorts and CMake should not second-guess Apple about that. Some apps may
>> not work correctly in Retina mode, and we and CMake should not break those
>> apps by defaulting to Retina mode.
>
> Again AFAIK: the Info.plist just informs the OS whether or not an application
> is capable of supporting a high-dpi mode (NSHighResolution*Capable*), it
> doesn't actually activate the mode.
>
> The only scenario where this can go wrong is where having an INappropriate
> NSHighResolutionCapable=true in the Info.plist (implicitly or explicitly)
> imposes a software DEactivation of the high-dpi mode very early in main.
>
> Cmake reverted the change that enabled default high-dpi support not because
> of such issues but because NSApplication is not approprioate on iOS and other
> embedded Darwin variants.
>
> I guess I'll get flak for adding the NSPrincipalClass magic to my cmake port
> if that causes inappropriate behaviour in certain applications.
Apps that use NSApplication should set NSPrincipalClass in Info.plist.
Coincidentally, this will also get them Retina support. Apps that do not use
NSApplication should not set NSPrincipalClass. If they support Retina, they
should use NSHighResolutionCapable.
Enabling Retina mode via either of the two Info.plist keys will cause the OS to
launch the app in Retina mode. Its window titlebars, for example, will then be
in Retina mode. Not requesting Retina mode in the Info.plist will cause the OS
to launch the OS in low-resolution compatibility mode, and its window titlebars
and content will be pixel-doubled instead.
>> NSApplication supports Retina mode, so Apple enables Retina mode when this
>> key is present in the Info.plist
>
> How many applications do you know that are built as app bundles via cmake but
> do not use NSApplication no matter how deeply hidden in a middleware like Qt?
> My guess would be that there will be less ports where the NSPrincipalClass
> key has to be patched OUT of the Info.plist than ports where it should be
> patched into that plist in order to get proper high-dpi rendering.
I have no knowledge of that.
My information comes from recent forays into adding Retina compatibility for
Mini vMac.
>> Setting this key to any value in an application that does use NSApplication
>> would be inappropriate, but doing so will
> "does NOT use" I presume?
Sorry, yes, typo.
>> 2. NSHighResolutionCapable can be set to 1. This is what should be done in
>> applications that do not use NSApplication.
>
> I already wrote and submitted a patch to introduce a new key with a
> modifiable default (LSUIElement). Repeating the exercise for
> NSHighResolutionCapable would be trivial.
>
> R
