Aller au contenu

jp

Modérateurs
  • Compteur de contenus

    6,564
  • Inscription

  • Dernière visite

Messages posté(e)s par jp

  1. Ah oui d'accord. Et effectivement, dans mes app qui font de l'AS les codes font toujours 8 caractères, avec les 4 premiers caractères étant le code de la suite. J'ai surement dû prendre l'habitude de faire comme ça sans trop me souvenir si c'était nécessaire ou quoi.

     

    Merci pour cette trouvaille !
  2. Avec plaisir :)

     

    Pour le tag code, je ne sais pas. J'ai toujours fait comme ça (mais j'ai peut-être eu tord, et si ça passait avant, peut-être qu'Apple a corrigé un truc qui fait que ça passe plus ?).

     

    Ou alors un bug dans Xcode 7 beta (si c'est ça que tu utilises)

     

    Si tu trouves l'origine du problème, oui poste ça ici !

     

    -- Edit

     

    En même temps, si tu regarde la Standard Suite (celle par défaut, fournie par Apple), y'a des code > 4 caractères, comme "coremove" par exemple.

  3. Salut sigma6 ! C'est une bonne question ça :P

     

    Est ce que tu as essayé de préfixé ta classe avec le token "@objc" pour dire au compilo que ta classe Swift est aussi une classe Objective-C ? J'ai pas essayé, mais comme l'API s'attend à une classe OC, j'imagine que ça doit être requis.

     

    -- Edit

     

    Quoi que ta / tes classes qui prennent en charge les messages AS doivent hériter de "FSAppleScriptCommand" normalement, donc le "@objc" doit être implicite.

     

    Je vais essayer sur un petit projet vierge voir ce qu'il en est (j'ai fait de l'AS sur des projets OC, mais jamais Swift pour l'instant).

  4. Le seul intérêt que je vois de démarrer en 32 bits, c'est si un kext n'a pas été porté en 64 bits. Je ne connais pas trop, mais je ne pense pas que des plug-ins audio utilisent des kext / driver ?

     

    Si tu veux forcer une application à se lancer en 32 bits (et si l'application est compilée 64 + 32), alors tu peux aller dans ses informations dans le Finder, et cocher "Open in 32-bit mode".

  5. C'est uniquement kernel_task qui est important, les autres processus n'apportent rien à la question.


     


    Pour ce qui est de uname, ça me semble étonnant, mais je ne connais pas assez précisément ce qu'il affiche, ni la manière qu'à Apple de nommer ses releases pour dire si c'est incohérent ou pas…


  6. "D'accord mais comme c'est plutôt un sujet dédié aux débutants, mieux vaux garder le titre actuel."

    De mon point de vue, les débutants ont besoin de précision dès le début, sinon ils finissent par se planter parce qu'ils ont créé un schéma mental approximatif, voir erroné.

     

    Pour ce qui est de ce nouvel exemple : oui, ça me semble bien plus sérieux que les deux exemples précédant. C'est pas tout à fait ce que tu veux (va falloir mettre des checkbox à la place des images), mais déjà, ça semble beaucoup plus juste et viable !

  7. L'exemple que tu donnes est très étrange… Tu as trouvé ça où ?


     


    Déjà il semble que la fonction de NSTableViewDelegate "func tableView(_ tableView: NSTableView, viewForTableColumn tableColumn: NSTableColumn?, row row: Int) -> NSView?" a été traduite en français… ce qui ne peut pas fonctionner (NSTableView s'attend à la fonction anglaise, pas autre chose).


    Ensuite il semble que cette fonction de delegate est réutilisée pour insérer la vue résultante dans "MonLabel". Bon ça c'est… fractalement erroné, si je puis dire ! En gros tu es en train de récupérer une vue que NSTableView construit pour l'ajouter dans une de tes vues à toi.


     


    NSTableView est là pour afficher un ensemble d'information, comme tu peux le voir dans la vue en liste dans le Finder, dans iTunes, etc. Cocoa se charge de tout pour toi : tu n'as plus à gérer comment ça se passe. Il s’agit de bien configurer ta NSTableView, et de lui fournir les bonnes informations, et c'est tout.


     


    Je te conseille de trouver un autre exemple (je n’ai pas trop le temps de t'en écrire un là, mais on en trouve des dizaines sur le net).


     


    Sur quel ligne tu as une erreur ?


     


    Sinon une remarque : il faut éviter au maximum d’utiliser les «!» dans Swift, ça casse un peu le modèle des optionals, et la sécurité apportée par ce système. Utilise «?» quand tu peux, et des «if let» pour dépaquer tes optionals. Au risque de me répéter, une lecture, même en diagonale du livre de référence d’Apple sur Swift est utile (il est gratuit sur iBooks).


  8. Concernant la "librairie", c'est le terme qui apparait dans l'application même (fenêtre de droite en bas), l'application s'appelle bien XCode (même si "Cocoa" est plus précis, "XCode" n'est pas incorrect).  Je ne parle pas de librairie XCode, mais de librairie d'objets XCode. C'est à dire l'ensemble des "objets" qui apparaissent dans la fenêtre "librairie" de l'application XCode.

    Comment le formuler autrement?

     

    Ah ah oui d'accord. Admettons.

     

    La meilleurs formulation reste de parler de Cocoa, des classes Cocoa, ou des contrôles d'AppKit (la "librairie" de Xcode n'est qu'un endroit où ils regroupent les différents contrôles d'AppKit - qui fait lui même partie de Cocoa - pour faciliter la vie des développeurs qui utilisent Xcode).

  9. Swift est beaucoup plus strict que OC sur les typages (il est plus comparable à C++ sur ce point là). NSMakeRect prend des CGFloat, et il n'y a pas de constructeur explicite pour faire un CGFloat à partir d'un Int. Il faut que tu "force" la conversion :

    var vY = 42;
     
    var rect = NSMakeRect(200, CGFloat(vY), 80, 20)
    

    Par contre si tu as une liste d'éléments à présenter (même avec des checkbox), qui plus est de longueur variable, je te recommande grandement l'utilisation du contrôle qui va bien : NSTableView. Ça prend un peu de temps pour comprendre comment tout fonctionne, mais ça reste relativement simple.

     

    P.-S. L'API Cocoa n'a rien à voir avec Xcode (le premier est un API / Framework, le deuxième un IDE) - il est possible d'utiliser Cocoa avec autre chose que Xcode. Et il n'y a pas de "librairie XCode" ;p

  10.  

     

    AnyObject offre plus de souplesse. On utilise lorsqu'il faut assembler divers types de variables, mais aussi lorsqu'on ne sait pas quel type d'informations seront rentrées dans un champs donné?

    Oui, pour simplifier oui. Et il existe un type encore plus générique : "Any". Lui peut absolument tout contenir (les objets comme les structures).

     

    Mais de manière générale, il vaut mieux éviter (ça casse un peu le système de typage, et ça rend le code plus obscure). Là on l'utilise parce 1/ on peut pas vraiment faire autrement (plusieurs types différents à collectionner) 2/ l'API Cocoa nous y oblige.

     

     

     

    Dans le script, rien n'indique que c'est un Array de AnyObject.

    En fait si : les [ ] autour de AnyObject indique que c'est un Array. Une variable de type "[AnyObject]" est un array de AnyObject. Une variable de type "[string]" est un array de String, etc.

     

    AnyObject peut être utilisé en dehors du cadre d'un Array (une variable peut-être de type AnyObject simple). Il n'y a pas de rapport entre AnyObject et les arrays.

     

     

     

    On utilise un Array à chaque fois que le résultat est fait de multiples réponses ou uniquement lorsque les résultats sont faits de types de variables différents?

    Disons qu'on l'utilise quand on a besoin de réunir des objets dans un même endroit. Le besoin d'utiliser un Array est pratiquement aussi naturel que le besoin d'utiliser une bibliothèque pour stocker ses livres dans la vie réelle.

    Y'a pas tellement de règles générale, mais usuellement quand tu as un nombre d'élément variables à stocker quelque part ou à transmettre à une méthode, tu utilise un Array (ou un conteneur autre).

     

     

     

    Ce qui m'intéressait c'était surtout de savoir si componentsJoinedByString est exclusivement réservé au variable de type Array ou aussi disponible à d'autres.

    C'est réservé aux Array (c'est une méthode de classe, associé au type Array - à ce niveau là il faut que tu étudie la POO). Enfin plus précisément au type cocoa NSArray. Mais Swift bridge les deux de toute façon (assez logique : ce sont des conteneurs du même type), donc ça reviens au même.

     

     

     

    Chaque type de variable utilise sont propre type d'objets?

    Chaque variable à son type oui.

     

    var toto : String // Variable de type String uniquement

    var toto : Int // Variable de type Int uniquement

    var toto : Any // Variable qui peut contenir tous les types, ce qui se rapproche le plus des variables Shell. À éviter autant que faire se peut.

    etc.

     

     

     

    Est-il possible de poster l'application sur votre site (ça pourrait vous faire un peu de pub)? Elle fait 4,8 MB.

    Non je ne met pas d'application tiers sur mon site. Mais peut-être que ça pourrais avoir sa place ici. Je sais plus si on a une section pour ça. Faut voir avec les admins :)

  11. Qu'est ce qui motive ton choix d'une variable AnyObject pour 'elemPart'?
    Alors il faut être précis : c'est un array de AnyObject, pas juste un AnyObject. Et il y a deux choses qui motivent ce choix :
    1 - C'est le type qu'attend la méthode "performWithItems"
    2 - On met des éléments de différents types dans l'array (une string et une NSURL). AnyObject est le plus proche équivalent de "id" en Objective-C, c'est à dire un type qui accepte tous les objets. C'est d'ailleurs pour ça que les NSArray des méthodes OC sont bridgé vers du [AnyObject].

     

     

    La fonction 'append' a été abordée lors de la rédaction du script précédent mais je ne connais pas bien sont étendue. Permet-elle de lier toute sorte de variable?
    La variable elemPart est un array. La fonction 'append' permet d'ajouter un élément à cet array. Y'a pas tellement de lien entre les objets (enfin autant qu'il peut y en avoir entre un livre et un DVD que tu stockerais dans une bibliothèque : ce sont tous les deux des objets). Ils sont juste stockés dans un même conteneur.
     
    Là encore je pense que tu restes dans le modèle "programmation shell" où y'a pas de notion de conteneur ni de typage. Il faut que tu te renseignes sur la programmation orientée objet, les conteneurs, et les conteneurs dans Swift.

     

     

    NSURL avec AnyObject (et surement d'autres combinaisons), quelles sont ses limites? Y a-t-il des types de variables incompatibles?

    AnyObject accepte toutes les instances de classe (mais pas les structures). NSURL est un objet et String est une structure (mais le compilateur cast implicitement les String en NSString dans ce cas, d'où le fait qu'on a pas d'erreur en mettant un String dans une variable de type [AnyObject]).

     

     

     

    Quelle est la raison de l'utilisation de "componentsJoinedByString("\n")"? Est-ce lié au fait que c'est une NSURL?

    1 - La variable 'body' est un array (enfin en tout cas dans la version que je t'ai renvoyée). La fonction 'componentsJoinedByString' permet de générer un string en joignant tous les strings de l'array avec le caractère "\n". C'est juste pour faciliter la lecture / écriture du code (c'est subjectif).

    2 - La variable 'body' n'est PAS une NSURL. C'est 'attachement' qui en est une.

  12. Je pense que tu doit raisonner encore trop en terme de script shell. Swift (comme beaucoup d'autres langages) utilise le concept de scope pour les déclarations.

     

    Une déclaration faite dans un scope n'est visible qu'à l'intérieur de ce scope, pas à l'extérieur.

     

    Dans ton code, tu déclare deux fois elemPart dans deux scopes différents (délimités par { et } ) qui sont les corps de ton "if" et de son "else". Au moment où tu appelle "service.performWithItems(elemPart)" tu n'est plus du tout dans un de ces deux scopes, et elemPart n'existe plus. Le compilateur te fait une erreur pour te dire qu'il ne sais pas de quoi tu parle.

     

    Si on garde ta structure, ça devrais plutôt être comme ça :

    if let service = NSSharingService(named:NSSharingServiceNameComposeEmail)
    {
      let elemPart : [AnyObject]
     
      if let attachement = Attachement.URL
      {
        elemPart = [ body.componentsJoinedByString("\n"), attachement ]
      }
      else
      {
        elemPart = [ body.componentsJoinedByString("\n") ]
      }
     
      service.delegate = self
      service.recipients = [courrielStr]
      service.subject = "Votre offre d'emploi au poste de \(fonctionStr). V. Réf. : \(vRefStr)"
      
      service.performWithItems(elemPart)
    }
    else
    {
      NSLog("Impossible d'utiliser le service d'envois de mail")
    }
    

    Note: tu ne doit plus tester l'attachement dans la première condition, sinon tu ne rentre jamais dans ton code quand il n'y a pas d'attachement (ce qui n'est pas ce que tu veut).

    Note 2 : ne met pas de ( ) autour de tes nom de variables, ça ne sert vraiment à rien.

    Note 3 : la possibilité d'initialiser une déclaration "let" plus tard est une nouveauté bien pratique des dernières versions de Swift. L'idée est que tu fait l'init quand tu veut, du moment qu'au moment où tu l'utilise dans ton code, elle soit complètement initialisée.

     

    Mais dans ton cas, plutôt que de construire deux versions différentes de ton array, je pense que c'est mieux d'en construire un seul variable dans lequel tu rajoute l'attachement s'il y en a un, comme ça :

    if let service = NSSharingService(named:NSSharingServiceNameComposeEmail)
    {
      var elemPart : [AnyObject] = [ body.componentsJoinedByString("\n") ]
     
      if let attachement = Attachement.URL
      {
        elemPart.append(attachement)
      }
     
      service.delegate = self
      service.recipients = [courrielStr]
      service.subject = "Votre offre d'emploi au poste de \(fonctionStr). V. Réf. : \(vRefStr)"
    
      service.performWithItems(elemPart)
    }
    else
    {
      NSLog("Impossible d'utiliser le service d'envois de mail")
    }
    
  13. Le NSPathController fonctionne assez bien non ? J'ai lu en diagonale le lien que tu donne, mais il me semble qu'ils rallent (à raison) sur un truc que tu n'utilise pas.

     

    Tu peut faire un drag & drop sur la fenêtre elle même, mais c'est un peu plus chiant à gérer. L'avantage de NSPathController, c'est que tout est géré pour toi (jolie affichage du path + drag & drop).

     

    Pour vérifier l'attachement, le mieux est surement de ne pas mettre de path du tout dans ton NSPathController dans ton XIB de manière à ce que par défaut "Attachement.URL" soit nil. Ensuite dans ta méthode "Courriel", si cet URL est nil tu le met pas dans l'array "elemPart", et si c'est pas nil tu vérifie que c'est bien un fichier, et si tel est le cas, tu le met dans "elemPart".

  14. Oui je t'avoue j'ai peut être lu en diagonale certains messages :D Bon au moins ça servira à ceux qui se posent la question ;)

     

    Mais de toute façon, ça reste utile si le disque dur n'est pas chiffré, ne serait-ce qu'en cas de vol de matériel.

     

    Pour ce qui est de la procédure, elle n'a rien de secret. Elle se trouve assez facilement. De toute façon, je ne considère pas que ce système soit d'une quelconque sécurité, et il ne faut pas que les gens pensent que ça en soit une et se repose aveuglément dessus.

  15. Je n’ai pas de soucis avec un NSPathControl. Tu utilises bien la propriété "URL" ? (et pour le coup, tu n’as plus besoin de "let attachementURL = NSURL(fileURLWithPath: attachement)" vu que tu as déjà une NSURL sous les mains).


     


    Pour ce qui est du \n et \r, c'est un vieux cauchemar venant d'obscures raisons historiques tout à fait discutables.


     


    Si je me rappelle bien, ça vient des premières imprimantes et Télétypes.


     


    \n c'est Line Feed, c'est à dire "instruction de scroller d'une ligne vers le bas".


    \r c'est Carriage Return, c'est-à-dire "instruction de remettre le chariot en début de ligne".


     


    Pour passer à la ligne, il fallait les deux instructions.


     


    C'est devenu complètement désuet bien sûr, mais forcément tout le monde a choisi de faire évoluer ça "à sa sauce" pour représenter un passage à la ligne. Microsoft a choisi CRLF (\r\n), Unix LF (\n) et Apple CR (\r).


     


    Bon, mais depuis OS X, et vu que c'est un Unix, on utilise aussi \n pour passer à la ligne. Tout ça pour dire que si \r marche surement (la plupart des codes gèrent les 3 cas), la norme sous OS X et Unix est d'utiliser \n.

  16. Le mode target fonctionne même en activant FileVault ? J'ose espérer que non sinon il y a aucun intérêt à ce truc, donc tu peux activer Filevault si tu le souhaites.
    Non non, si les données sont chiffrées, elles sont inaccessibles.  Si tu branches un ordinateur chiffré avec CoreStorage en target mode sur un autre ordi, OS X va te demander le mot de passe pour le déchiffrer. Pas de bypass possible, les données sont vraiment toutes chiffrées, le mot de passe n'est pas un artefact.
    Mais si les données ne sont pas chiffrées : un démontage de disque dur, du target mode, ou du boot en single mode, et hop tu accèdes à tout.

     

     

     

     

    Sinon pour un ordinateur perso, franchement je ne vois pas bien l'intérêt de sécuriser autant les données effacées.

    Il peut aussi mettre un password UEFI pour empêcher (dans une moindre mesure) le démarrage en single boot.

    Je ne sais plus ce qu'il en est depuis l'EFI, mais avec l'OF, c'était possible de faire sauter ce mot de passe (il fallait enlever une barrette de RAM et zapper la PRAM, de souvenir). Ça reste une protection très artificielle, et ça ne protège pas d'un démontage pour récupérer le disque dur, par exemple.

     

    Après sur l'intérêt de protéger ses données, ça relève de la vie privée et de la sécurité. Tu ne peux pas savoir dans quelles mains vont réellement finir ton ordi et ton disque dur. Est ce que tu as envie que quelqu'un puisse voir ton historique internet, tes documents Pages où tu déclares ta flamme pour je ne sais qui, tes relevés de compte bancaire, d'éventuelles données bancaires, d'éventuelles photos érotiques personnels, des photos de ta famille, des opinions politiques, religieuses, etc. ?

     

    La légalité des informations n'est pas le problème (tout ce que je viens de citer est parfaitement légal), ça veut pas pour autant dire que tu as envie qu'un pervers, un psychopathe, un ado boutonneux, un opposant idéologique, ou quiconque puisse éventuellement y accéder.

  17. À noter tout d'abord qu'il s'agit plus d'une problématique de Cocoa que de Swift ici.

     

    Sinon, les pièces à joindre sont à mettre dans le même array que ton texte de corp de message.

     

     

    func forge_body() -> NSAttributedString
    {
       let line1 = NSAttributedString(string: "Première ligne.", attributes: [NSFontAttributeName : NSFont(name: "Helvetica-Bold", size: 12.0)!])
       let line2 = NSAttributedString(string: "Deuxième ligne.", attributes: [NSFontAttributeName : NSFont(name: "Helvetica-Oblique", size: 12.0)!])
     
       let result = NSMutableAttributedString()
     
       result.appendAttributedString(line1)
       result.appendAttributedString(NSAttributedString(string: "\n"))
       result.appendAttributedString(line2)
     
       return result
    }
     
    func forge_mail()
    {
       let recipient = "[email protected]"
       let subject = "Mon Email"
       let body = forge_body()
       let attachement = "/path/to/my.pdf"
     
       if let service = NSSharingService(named:NSSharingServiceNameComposeEmail), let attachementURL = NSURL(fileURLWithPath: attachement)
       {
          let items = [ body, attachementURL ]
     
          service.recipients = [ recipient ]
          service.subject = subject
     
          service.performWithItems(items)
       }
       else
       {
          NSLog("Something is wrong somewhere")
       }
    }
    
  18.  

     

    ça je ne crois pas, en tout cas par sur un disque à plateaux (car sur un SSD, les cellules doivent effectivement être préparées à recevoir de nouvelles données).

    La défragmentation sur un SSD est assez inutile :

    1/ la vitesse d'accès est (majoritairement) constante quel que soit l'endroit où est stocké la donnée

    2/ le SSD fragmente de toute façon tes données dans ton dos, pour les répartir au mieux, avec une rotation, afin de minimiser l'usure d'une cellule en particulier (une donnée que tu écrit à un endroit X et une autre à un endroit X+1 ne seront pas forcément stocké physiquement à X et X+1 sur ton SSD).

     

     

     

    Faut déjà le vouloir pour récupérer des données effacées.

    Chez moi DataRescue a déjà fait des miracles. Et il est très simple à utiliser.

     

     

     

    Sinon tu utilises une session différente avec mot de passe et déjà ça bloque un minimum (sauf si une personne ayant accès à ta machine est administrateur bien entendu).

    Ne pas oublier le mode target (permet de bypasser les droits) et le boot en single mode (qui te permet d'accéder au disque dur en root, sans mot de passe).

×
×
  • Créer...