Bibliothèque

Réponses

• LeChatNoir Membre, Modérateur

  novembre 2012 #2

  pour avoir le "Documents" directory, tu fais ça :
  

  <br />
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);<br />
      NSString *basePath = ([paths count] &gt; 0) ? [paths objectAtIndex:0] : nil;<br />
  

  
  
  
  
  Regarde donc la doc de NSSearchPathForDirectoriesInDomains, ça devrait répondre à  ta question.
  
  
  
  Pour le point 2, je connais moins, car je suis plus sous iOS...
• AliGator Membre, Modérateur

  novembre 2012 #3

  Pour le point 1, ton "~/Library" ne marche pas car il faut le transformer en chemin réel (le "~" n'est qu'une accommodation du shell), donc il faut utiliser "[font=Courier, Consolas, monospace]stringByExpandingTildeInPath[/font]" pour qu'il remplace le tilde par le chemin vers ta petite maison.
  
  
  
  Cependant, ça c'est pour l'explication, mais ça n'empêche que mettre un tel chemin en dur n'est pas la bonne solution. Pour trouver le chemin vers les répertoires standards (le "Library" du système ou celui de ta Home, le dossier Documents de ta Home, etc), utilise la méthode citée par LeChatNoir en indiquant les bonnes constantes selon le dossier standard dont tu veux récupérer le chemin. C'est la façon officielle de faire.
  
  
  
  Pour le point 2, il faut utiliser NSOpenPanel. Tu as même dans la doc de la Class Reference de NSOpenPanel un lien vers le "Sheet Programming Topics" qui t'explique toutes les étapes pour afficher des "sheets" sous la barre de titre de ta fenêtre comme le font la plupart des applis Mac.
• BertrandMartin Membre

  novembre 2012 #4

  OK pour le point 1: ça marche !
  
  
  
  Je me plonge dans le point 2.
• Céroce Membre, Modérateur

  novembre 2012 #5

  Note que si ton appli est distribuée sur le Mac App Store, elle ne peut pas accéder à  un fichier en dehors de sa sandbox, sauf si l'utilisateur passe par NSOpenPanel pour choisir le fichier. C'est à  dire que la technique 1 ne fonctionne pas sur le MAS.
• BertrandMartin Membre

  novembre 2012 #6

  L'application en question n'a pas vocation à  être distribuée sur le MAS. Elle sera peut-être mise en ligne sur le site Projet G5 . Mais, admettons que je veuille la distribuer sur le MAS, quel est le répertoire auquel mon application peut avoir accès ? Car, autant prendre les bonnes habitudes tout de suite : Rien ne dit que je ne finirai pas par développer des applications pour le public et le MAS risque d'être bientôt le passage obligé.
  
  
  
  D'ailleurs, la seule voie pour contourner le MAS (et celle-ci, je ne vois pas comment Apple pourraà®t la fermer) sera bietôt d'installer une application que l'on compilera soi-même à  partir d'un code source téléchargé. Ah, les joies linuxiennes du "./Configure, Make et sudo make install" ! Avec les dépendances qui ne sont JAMAIS satisfaites et qui dépendent elle même d'autres dépendances !
• Céroce Membre, Modérateur

  novembre 2012 #7

  'BertrandMartin' a écrit:

  
  
  Mais, admettons que je veuille la distribuer sur le MAS, quel est le répertoire auquel mon application peut avoir accès ?
  

  
  
  Comme c'est une question plus complexe qu'il n'y parait, je t'invite à  lire la doc.
  
  
  

  'BertrandMartin' a écrit:

  
  
  D'ailleurs, la seule voie pour contourner le MAS (et celle-ci, je ne vois pas comment Apple pourraà®t la fermer) sera bietôt d'installer une application que l'on compilera soi-même à  partir d'un code source téléchargé.
  

  
  
  Dans l'hypothèse très improbable (j'allais écrire paranoà¯aque) qu'Apple interdise d'exécuter toute application qui ne soit pas signée, je ne vois pas en quoi compiler soi-même l'appli change quoi que soit. Même si tu la compiles toi-même, elle sera toujours non signée, et le système d'exploitation refusera de la lancer.
• BertrandMartin Membre

  novembre 2012 #8

  Certes, mais dans ce cas, il faudrait interdire de programmer : Qu'est-ce qui différenciera un code source tapé soi même d'un code source téléchargé ? Il faudrait alors qu'Apple réserve les outils développeurs a des entreprises connues. Ce qui, d'une part contreviendrait à  la GPL (XCode est basé sur des outils libres) et surtout serait tout a fait contradictoire avec la politique d'Apple de chercher à  ce que le maximum de contenu soit produit pour ses produits, ordis et iBidules (exemple : iBook Author qui n'est même pas payant ). Soit on laisse les outils XCode à  la disposition de tous, pour que beaucoup de logiciels sortent, et dans ce cas, on pourra compiler ce que l'on veut, son propre code ou bien du code de diverses provenances, soit Apple se tire définitivement une balle dans le pied en bloquant tout .
• AliGator Membre, Modérateur

  novembre 2012 #9

  'BertrandMartin' a écrit:

  
  
  Certes, mais dans ce cas, il faudrait interdire de programmer : Qu'est-ce qui différenciera un code source tapé soi même d'un code source téléchargé ?

  Bah la signature de code.
  
  
  
  Il faut bien comprendre que la signature du code n'est là  que pour signer le code (ça parait une évidence mais il semble bon de le rappeler quand même), c'est à  dire pour apposer ta signature sur l'application et certifier que c'est untel qui l'a développée et créée.
  
  Ainsi s'il y a un problème, que l'application fait des choses malveillantes, on sait à  qui s'en prendre, la personne a signé son oeuvre.
  
  Ceci n'a rien à  voir avec le Sandboxing.
  
  
  
  Rien ne t'empêche d'exécuter une application non-signée (tu peux tout à  fait le désactiver dans GateKeeper, ou faire un clic-droit -> Ouvrir sur l'appli pour l'ouvrir même si elle n'est pas signée et que GateKeeper te déconseillerait de l'ouvrir sinon). C'est juste qu'alors si elle te fait des misères, vole tes données ou quoi, tu ne pourras t'en prendre qu'à  toi-même.
  
  Cela est juste fait pour t'inciter à  n'exécuter que des applications de confiance, pas des trucs téléchargés un peu n'importe où (réseaux pirates ou autres) et te retrouver avec un cheval de troie genre une application qui se fait passer pour quelqu'un d'autres, genre tu penses avoir téléchargé le dernier Microsoft Office sur un réseau pirate mais c'est un cheval de troie qui en fait te pourrit ton ordi et envoie ton carnet d'adresse au pirate et transforme ton mac en relai de spam ou je ne sais quoi... si tu avais vérifié avant que le Microsoft Office que tu as c'est bien celui signé par Microsoft et non pas une appli non signée, tu n'aurais pas eu de déboires.
  
  
  
  Tout ce système de signature de code permet donc de s'assurer que tu n'exécutes que des applications qui ont été signées par leur auteur et donc certifiées comme étant les applications d'origine de leur auteur. Une fois compilées et signées, tu ne peux pas modifier le binaire de l'application (pour introduire du code malveillant dedans par exemple) sans casser la signature. Après bien sûr si tu télécharges une application faite par qqun de malveillant et qui l'a signée avec son propre certificat, l'application est signée et pourra exécuter son code malveillant, mais tu sauras qui blâmer et l'auteur sera rapidement identifié banni de toute façon.
  
  
  
  
  
  Tout ceci n'a rien à  voir avec le Sandboxing (même si malheureusement beaucoup de personnes font l'amalgame), qui lui consiste à  s'assurer qu'une application est confinée à  son propre environnement et de lui interdire de toucher au reste de ton système pour éviter de le corrompre en modifiant des fichiers auxquels il n'a pas le droit d'accéder.
  
  Mais rien ne t'empêche de continuer à  créer des applications, qui accèdent à  des fichiers du système en dehors de sa sandbox (tu ne pourras alors pas distribuer ton application via le MacAppStore -- sauf dérogation spéciale ou raison justifiée et autorisée de cette sortie de sandboxing, mais c'est rare), et de signer cette application avec ton certificat développeur, et distribuer ton application sur ton site internet ou par n'importe quel moyen de ton choix. Et cette application pourra être exécutée sur n'importe quel Mac, même si ce Mac a GateKeeper d'activé et n'autorise que les applications signées.