Anyone using cmake for iOS development?

[Ryan Schmidt]

> On Mar 14, 2019, at 17:20, René J.V. Bertin <rjvbertin at gmail.com> 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