Fonctionnement sous Mountain Lion (OS X 10.8)

[lelinuxien]

Bonsoir à toutes et à tous.

Depuis quelques jours, la nouvelle version d'OS X est disponible en version finale. La bonne nouvelle, c'est que contrairement aux versions précédentes, cette mouture 10.8 ne nécessite pas de nouvelle version de SDL: le mode fenêtré et le mode plein écran de ZS DX sont tous deux fonctionnels.

Mais... Il y a malheureusement un "mais" pour que le jeu fonctionne. Avec cette nouvelle version d'OS X, par défaut, seules les applications provenant de l'Apple Store ou d'un éditeur connu, signées numériquement pourront être lancées sous le nouveau félin. Pour des raisons de sécurité, les autres applications (dont ZS DX) sont donc bloquées.

Pour permettre l'exécution d'applications non signées numériquement (et donc de ZS DX) sous OS X 10.8, il suffit d'ouvrir les Préférences système et de se rendre dans Sécurité et confidentialité. Cliquez ensuite sur le cadenas pour débloquer les modifications et entrez votre mot de passe administrateur. Dans l'onglet général, cochez "N'importe où" et acceptez les modifications.



Enfin, la première fois que vous lancerez le jeu, vous aurez droit à un message sur sa provenance, confirmez. Bon jeu!


La version disponible en téléchargement sur le site (qui est une version x86_64) ainsi que ma version compatible depuis 10.4 (Universal Binary PPC / Intel x86) sont toutes les 2 compatibles Mountain Lion et nécessitent cette modification de paramétrage (il en va bien sûr de même pour ZS XD). Étant donné que Mountain Lion nécessite un processeur 64 bits et qu'il s'agit d'un OS full 64 bits, bien qu'il soit également compatible avec les applications 32 bits, je recommande la version du site optimisée 64 bits.

Voilà, en espérant que ce mini tutoriel sera utile pour certains d'entre vous. 

[Morwenn]

Eh, c'est chouette de voir que pour une fois une version de Mac ne donne pas un mois de travail supplémentaire et l'ajout dans 30 lignes dans le CMakeLists.txt pour fonctionner

[vlag67]

Nan cette fois c'est dans le Info.Plist, orientation App Store oblige ^^

https://developer.apple.com/library/mac/#releasenotes/General/SubmittingToMacAppStore/_index.html#//apple_ref/doc/uid/TP40010572

J'espère juste que le compte développeur gratuit permettra de soumettre l'application via Application Loader, et idéalement que l'un n'ai rien à voir avec l'autre

[Sam101]

Nan cette fois c'est dans le Info.Plist, orientation App Store oblige ^^

https://developer.apple.com/library/mac/#releasenotes/General/SubmittingToMacAppStore/_index.html#//apple_ref/doc/uid/TP40010572

J'espère juste que le compte développeur gratuit permettra de soumettre l'application via Application Loader, et idéalement que l'un n'ai rien à voir avec l'autre

Pas possible pour plusieurs raisons:

1)ZSDX utilise du Lua, c'est "potentiellement pas secure" d'après Apple
2)ZSDX respecte pas les règles du sandbox, notamment sur sur quels fichiers il écrit.

[vlag67]

Ouaip en fait, de toute façon il fallait avoir le compte payant pour obtenir le certificat. Paye tes $99/Year ...

ZSDX utilise du Lua, c'est "potentiellement pas secure" d'après Apple

D'après ce que j'ai compris, c'est pas spécifique à Lua, c'est surtout qu'il faut signer en plus chaque framework/lib/plugin embarqués.

ZSDX respecte pas les règles du sandbox, notamment sur sur quels fichiers il écrit.

Hum, je vais passer pour un noob mais ... C'est quoi exactement le sandbox Apple?
D'après cette page, sandbox = signed application.
Je ne vois pas le soucis du coup, il faudrait juste appliquer bêtement point par point les instructions du lien de mon premier message ...

[Sam101]

Ouaip en fait, de toute façon il fallait avoir le compte payant pour obtenir le certificat. Paye tes $99/Year ...

ZSDX utilise du Lua, c'est "potentiellement pas secure" d'après Apple

D'après ce que j'ai compris, c'est pas spécifique à Lua, c'est surtout qu'il faut signer en plus chaque framework/lib/plugin embarqués.

ZSDX respecte pas les règles du sandbox, notamment sur sur quels fichiers il écrit.

Hum, je vais passer pour un noob mais ... C'est quoi exactement le sandbox Apple?
D'après cette page, sandbox = signed application.
Je ne vois pas le soucis du coup, il faudrait juste appliquer bêtement point par point les instructions du lien de mon premier message ...

To promote a more consistent user experience, applications submitted to the Mac App Store must follow certain rules about where they write files. Users can be confused when applications cause unexpected side effects on the file system (for example, storing databases in the user's Documents folder, storing files in the user's Library folder that are not recognizably associated with your application, storing user data in the user's Library folder, and so on).

Your application must adhere to the following requirements:

    You may use Apple frameworks such as User Defaults, Calendar Store, and Address Book that implicitly write to files in specific locations, including locations your application is not allowed to access directly.

    Your application may write to temporary paths that you acquire using the appropriate Apple programming interfaces.

    Your application may write to the following directories:

        ~/Library/Application Support/<app-identifier>

        ~/Library/<app-identifier>

        ~/Library/Caches/<app-identifier>

    where <app-identifier> is your application's bundle identifier, its name, or your company's name. This must exactly match what is in iTunes Connect for the application.

    Always use Apple programming interfaces such as the URLsForDirectory:inDomains: function to locate these paths rather than hardcoding them. For more information, see File System Programming Guide.

Entre autres

[vlag67]

Cf mon premier message ... :/

Je me demande pourquoi je poste des fois ...

[vlag67]

Avant de tenter de mettre les "sandbox rules" en oeuvre pour Mac 10.8, j'aimerais avoir votre avis.

Sachant que la mise en place de ces règles nécessitent l'utilisation de fonctions OSX 10.6+ ,
et que la compatibilité 10.5 n'est toujours pas fonctionnelle, à priori à cause d'un bug dans SDL_Image (Github -> Issue pour plus d'info) :
Il y a 3 solutions (en partant du principe que les libs embarquées peuvent être signées)

- Abandonner la compatibilité 10.5 (ce qui reviendrait à nettoyer un peu le CMakeList.txt), à savoir que la version proposée par Lelinuxien fonctionnerait toujours dessus.
- Se conformer le plus possible aux règles du sandbox, en hard-codant les fonctions litigieuses pour avoir une compatibilité 10.5 quand le soucis sera réglé du coté SDL (ce qui ne risque pas d'arriver de sitôt, avec le développement de la version 2.0). Sur 10.8, cela ne changerait rien.
- Y aller en mode crado, à coup de #ifdef et OSX_VERSION_MIN, pour pouvoir compiler rapidement 2 versions basées sur les dernières lib.

Je pense que laisser tomber 10.5 est le plus logique, mais ça ne me satisfait pas vraiment donc j'aimerais connaitre votre position dans ce genre de cas.

[benoit]

En tout cas, juste une chose. Je ne suis pas sous MAC, mais ça n'a rien à voir : évite tout de même les double posts. Au pire, copie ton dernier message, enlève-le et réécrit le en ajoutant ce que tu voulait dire en plus.