Xcode templates not working (RESOLVED)

[Jonny]

I've tried testing https://github.com/SFML/SFML/pull/1384 but had some issues, and it turns out I have the same issues on the current git master anyway:

After copying the templates to the templates folder, I only have the option for the CLT template (no SFML App), and even when creating that, It doesn't build "Out the box" as I'd expect.

First error is "Build setting PRODUCT_NAME undefined", fairly trivial to fix in the build settings, but then it doesn't find any of the headers ( I have double checked and the headers are definitely in /usr/local/include as they should be

I'm using Xcode 9, on macOS 10.13

[Hiura]

After copying the templates to the templates folder

How did you copy the files? The templates are configured according to your CMake settings. Manually copying the files won't work, unfortunately.

Either use CMake to install the templates, or manually configure this file: https://github.com/SFML/SFML/blob/master/tools/xcode/templates/SFML/SFML%20Compiler.xctemplate/TemplateInfo.plist.in I think it's the only one. `*.in` files should also be renamed to drop the suffix.

[Jonny]

I see what's happened, the tutorial needs updating as it suggests manually copying: here:https://www.sfml-dev.org/tutorials/2.4/start-osx.php

Checked the cmake cache and I just need to set SFML_INSTALL_XCODE_TEMPLATES to true to get them to install correctly.

Until high-dpi displays are supported, could we change the template info.plist so the window is the expected size? That would mean setting high resolution capable to "NO"

[Hiura]

I see where the confusion comes from, but this tutorial https://www.sfml-dev.org/tutorials/2.4/start-osx.php#installing-sfml reads First of all you need to download the SFML SDK which is available on the download page.. The templates available from the download page are pre-configured for the specific instructions from the tutorial.

On the other hand, https://www.sfml-dev.org/tutorials/2.4/compile-with-cmake.php is dedicated to building & configuring SFML.

I'm not sure how to make things clearer. Any suggestions?


On high-dpi displays: if you submit a PR to add an on/off option in the app bundle template wizard, I'd accept this as a fix (because I'd argue the default should be 'on'). I think this is the right file to modify: https://github.com/SFML/SFML/blob/master/tools/xcode/templates/SFML/SFML%20Bundle.xctemplate/TemplateInfo.plist

[Jonny]

Ah yes I see, my mistake then, I didn't realise the files would be different in SDK vs source. The docs could maybe contain a warning of the difference, but you're right it's already quite clear.

What's your argument for having high resolution capable on by default? Will that not cause windows to be different sizes on retina/non-retina displays?

[Hiura]

From the top of my head, disabling it will result in window decorations being blurry. As for the size, you always get the same number of pixels. I encourage you to test it and report issues, but the window should be properly resized when moving from a retina to a non-retina display (and vice versa).

Yet, I agree, we probably would benefit from a better API for screens. Not sure how it would look though...

[Jonny]

I encourage you to test it and report issues

Exactly what I've been trying to do here pal

Here's some video proof if needed. hooked retina MacBook up to a regular DPI screen (video is just of the non-retina screen), Run the app on retina and drag to non-retina, then run the app on non-retina. Notice in the first video with high resolution capable set to "yes", the window is half the size when started on the retina screen (Especially painful if your app has any text, it becomes basically unreadable)

https://www.youtube.com/watch?v=8n4IDbjeQ6w

Second video with high resolution capable set to "NO", window is the same size regardless of which screen it's opened on:

https://www.youtube.com/watch?v=cm-8b1Bif9Y

It does have the unfortunate side effect of making the window decorations blurry (but only on retina screens), but in my opinion that's a much lower priority than ensuring the same window size on all hardware

[Hiura]

I see... Well, first of all, thanks for the feedback!

With those evidences, I guess we can change the default until we have proper support for high DPI. Would you like to create a PR for that?

Side note: I don't remember what's the default when there's no plist file (e.g. command line app)...

[Jonny]

In my experience CLI apps open with the incorrect size, but I don't know if that's something that can be handled in code or not? I don't really have any experience with the objective-C stuff (although I  have a feeling I'll need to familiarise myself at some point...) but I'll make a note here and check it out when I can.

PR incoming shortly for the other change

edit: PR not coming THAT shortly, bc I haven't quite worked out how to change this in a template :S