Apple a revu en profondeur les trois logiciels de sa suite bureautique iWork. Certains changements sont incontestablement positifs, mais le constructeur a retiré au passage plusieurs fonctions. Outre des options qui ont disparu dans les interfaces, les amateurs d’automatisation regretteront le retrait pur et simple d’AppleScript. Ce langage inventé par Apple pour créer des scripts et automatiser certaines tâches n’a pas disparu pour autant…

Vingt ans après sa création, AppleScript n’est pas mort. Il est au contraire bien vivant et OS X Mavericks lui apporte plusieurs nouveautés, pour certaines très significatives. Passage en revue rapide des points intéressants pour les utilisateurs de ce langage et d’Automator, l'utilitaire qui facilite son utilisation.

Les scripts dans le nuage

Après le mode plein écran ou la gestion des versions l’an dernier (lire : OS X Mountain Lion : nouveautés AppleScript et Shell), l’Éditeur AppleScript continue d’intégrer les nouvelles fonctionnalités d’OS X avec, à chaque fois, un petit peu de retard. Cette année, le logiciel dédié à l’écriture des scripts intègre iCloud : on peut sauvegarder ses scripts sur les serveurs d’Apple pour les retrouver ensuite sur tous vos Mac associés au même compte.

L’intégration d’iCloud est similaire à celle que l’on retrouve dans tous les logiciels qui intègrent cette fonction. Notons d’ailleurs que les fichiers sont stockés avec les autres documents iCloud et ne sont pas accessibles directement depuis l’icône de la barre des menus d’OS X. Cette fonction est pensée pour synchroniser des scripts, pas à les utiliser directement. Outre l’Éditeur AppleScript, Automator intègre aussi iCloud pour les mêmes raisons. L’interface est d’ailleurs similaire.

Sécurité : signature des scripts et accessibilité

Autre nouveauté, les développeurs de scripts peuvent désormais les signer avec leur certificat pour passer GateKeeper. Rappelons qu’OS X est désormais configuré pour protéger l’utilisateur contre les logiciels potentiellement dangereux. Par défaut, le système n’accepte que les applications téléchargées depuis le Mac App Store ou qui ont été validées par un certificat délivré par Apple. Certes, les utilisateurs peuvent modifier ce réglage, mais la majorité d’entre eux ignoreront son existence.

On peut créer des applications uniquement avec AppleScript — DiskMaker X en est un excellent exemple —, mais elles risquent de ne pas s’ouvrir chez bon nombre des utilisateurs à cause de GateKeeper. Pour éviter des problèmes liés à la sécurité, le mieux est de signer le script ou l’application que vous allez distribuer. Pour cela, l’Éditeur AppleScript dispose d’une nouvelle option pour signer le code au moment de l’export. Un clic suffit, même s’il faut avoir préparé le terrain en amont. À noter que c’est exactement la même chose pour les applications créées avec Automator.

Du côté des utilisateurs, un autre changement peut empêcher le bon fonctionnement des scripts par défaut. Avec OS X Mavericks, l’utilisateur peut accepter ou bloquer le contrôle de l’ordinateur par un logiciel. Un script peut facilement entrer dans cette catégorie : il peut avoir à modifier un paramètre, actionner un bouton ou effectuer d’autres actions encore.

Dans la majorité des cas, il faudra ajouter l’Éditeur AppleScript à la liste blanche dans les Préférences Système. Dans le panneau "Sécurité et confidentialité" et dans l’onglet "Confidentialité", puis dans la rubrique "Accessibilité", il faudra cocher toutes les applications qui doivent modifier l’interface. Malheureusement, OS X ne facilite pas l’ajout d’un élément et il faudra tout faire manuellement avant de pouvoir lancer un script.

Notifications en AppleScript ou avec Automator

Les notifications ne sont pas nouvelles dans OS X, mais il n’y avait jusque-là aucun moyen simple de les utiliser avec un script. Il fallait passer par un autre programme qui faisait l’intermédiaire, ce qui était loin d’être idéal. Fort heureusement, OS X Mavericks offre une solution extrêmement simple pour envoyer une notification.

Dorénavant, il suffit d’utiliser la commande display notification "Message de la notification" pour afficher un message en AppleScript. La commande accepte quelques paramètres, par exemple, pour changer le titre — par défaut c’est le nom du script —, le sous-titre ou encore faire entendre une alerte sonore pour renforcer l’alerte. Ajoutons que l’icône adopte celle du script par défaut : pensez à changer l’icône par défaut pour personnaliser vos alertes.

Pour aller bien plus loin, vous pouvez même agir en fonction de l’action de l’utilisateur sur l’alerte. Ce n’est pas quelque chose de prévu par défaut et il faudra un petit peu plus de développement, mais cela reste assez simple. Vous trouverez des explications et un exemple à cette adresse. Petite note utile : dans un script complet, il est important d’ajouter une pause, même brève, après la commande qui envoie les notifications. Utilisez par exemple la commande delay 1 pour laisser le temps au système d’afficher l’alerte.

Automator peut lui aussi envoyer des notifications. Le principe est identique à celui de l’éditeur de script, même si vous n’aurez rien à coder : il suffit d’ajouter l’élément "Afficher la notifications" pour créer une alerte. En contrepartie, vous n’aurez pas le choix du son — forcément celui par défaut —, ni de l’icône — celle d’Automator.

Puisqu’il s’agit de notifications standard, l’utilisateur peut gérer ces alertes avec les outils de base d’OS X 10.9. Dans les Préférences Système, panneau "Notifications", il peut notamment décider de retirer les alertes du Centre de notifications, voire de les masquer totalement.

Processus qui réagissent à la voix

Cette nouveauté est spécifique à Automator : une application créée avec l’outil d’Apple peut désormais être sauvegardée en tant que "Speakable Items", c’est-à-dire en tant qu’élément prononçable. À partir de là, OS X sera capable de détecter si vous prononcez le nom du processus créé par ce biais et le lancera automatiquement.

Pour utiliser cette fonction, il faut préalablement activer les éléments prononçables. Dans les Préférences Système, panneau "Accessibilité", faites défiler la liste à gauche jusqu’au dernier élément. Cochez la case qui permet d’activer cette fonction et l’option apparaîtra d’elle-même dans Automator.

Concrètement, cette fonction assez ancienne d’OS X ajoute un micro rond sur votre écran. Quand vous pressez les touches définies dans les réglages, l’ordinateur enregistre votre voix et agit en fonction. Avec OS X Mavericks, vous pouvez imaginer de convoquer un processus pour fermer la session en quittant certains logiciels et qui serait invoqué en disant "bye". Ou un autre qui lancerait au contraire plusieurs logiciels en disant "hello". Il est important de choisir soigneusement le nom du processus dans Automator, vu que c’est lui qui lance les opérations. Ajoutons que cette fonction n’est pas adaptée à une prononciation francophone : restez sur des mots simples que vous savez correctement prononcer en anglais.

Bibliothèques AppleScript personnalisées

Préambule

Cette nouveauté est la plus complexe à comprendre et à mettre en place de toutes celles que nous avons évoquées dans cet article, mais c’est aussi, et de loin, la plus importante. Elle est si importante qu’Apple a consacré une session entière uniquement pour ce point à l’occasion de la WWDC 2013. Les développeurs intéressés par le sujet en apprendront d’ailleurs bien plus en regardant la session 416.

Pour les autres, rappelons tout d’abord l’un des principes de base en AppleScript. Ce langage de programmation est basé sur des bibliothèques de commandes qui sont spécifiques à chaque programme que l’on veut automatiser. Pour récupérer l’adresse de la page actuellement ouverte dans Safari par exemple, on peut utiliser ce script qui va mémoriser l’information dans la variable pageURL.

Ce script fonctionne, puisque l’on utilise des commandes spécifiques à Safari. La première ligne sert d’ailleurs à convoquer la bibliothèque du navigateur, et à charger tous les outils spécifiques au logiciel. On ne pourrait pas utiliser la seconde ligne avec Chrome ou Firefox : le premier a sa propre bibliothèque qui diffère légèrement de celle du navigateur d’Apple, le second n’en a pas du tout.

Créer une bibliothèque

Ce rappel étant fait, venons-en à la nouveauté. Avec OS X Mavericks, l’utilisateur peut facilement créer ses bibliothèques avec ses propres outils développés en AppleScript. Cette option est très intéressante pour centraliser du code que vous utilisez dans tous vos scripts. Auparavant, on pouvait déjà rassembler des outils dans une bibliothèque, mais il fallait les développer en Objective-C ou en C, ce qui compliquait l’opération.

Nous allons prendre en guise d’exemple une fonction très simple qui sert à chercher une séquence dans un texte. Cette fonction sert effectivement dans plusieurs scripts qui tournent au quotidien sur plusieurs postes chez MacG et nous avons tout intérêt à l’isoler et à l’intégrer à notre bibliothèque personnalisée. Pour commencer, il faut simplement créer un script qui va contenir la fonction. Cette dernière est très simple : elle accepte trois paramètres (le début et la fin de la séquence à chercher et le texte dans lequel effectuer la recherche) et elle renvoie le bout de texte trouvé.

Ce script doit être placé à un endroit spécifique pour être reconnu et utilisé par les autres scripts que vous créerez. Plusieurs emplacements sont possibles, le plus simple est d’enregistrer le fichier dans ~/Bibliothèque/Script Libraries. Si le dossier ne s’y trouve pas, créez-le et placez-y le ou les script(s). À partir de là, vous pouvez utiliser la fonction dans n’importe quel autre script en convoquant la bibliothèque personnelle de la même manière que l’on appelle la bibliothèque d’un logiciel. Dans notre exemple, on doit utiliser la commande tell script "RechercheTexte" pour utiliser la fonction :

Cet exemple est très simple et ne mérite pas plus d’explications, puisque la bibliothèque est constituée d’une seule fonction. Naturellement, on peut l’enrichir avec d’autres fonctions et se constituer ainsi un outil complexe. Dans ce cas, pour s’y retrouver, le mieux est de créer un dictionnaire qui détaille le rôle et le fonctionnement de chaque fonction dans la bibliothèque.

Si la création de la bibliothèque était très simple, créer un dictionnaire est plus complexe. Il faut enregistrer les fonctions dans un paquet de script et non plus un script et il faut surtout créer un XML à la main qui respecte les exigences d’Apple. On évoquera rapidement ce processus dans la prochaine partie.

Utiliser plus simplement les bibliothèques

Dernière nouveauté à évoquer : OS X 10.9 introduit une nouvelle méthode pour charger les bibliothèques. Cette méthode fonctionne autant pour celles des applications que pour les bibliothèques que l’on crée soi-même.

Avant Mavericks, la seule solution pour contrôler une application ou accéder à ses données était de passer par une commande tell application "Nom" ou tell script "Nom" et on devait absolument indiquer la fin de l’utilisation de la bibliothèque par une commande end tell. C’était un peu contraignant à développer et c’était aussi du code qui était répété très souvent dans un script. Désormais, on peut utiliser une nouvelle commande qui n’intervient qu’une seule fois pour tout un script.

À la place de tell, on peut utiliser en tête de script la commande use qui charge la bibliothèque complète d’une application, ou d’une bibliothèque. Cette fonction est assez similaire dans l’esprit à la commande import que l’on utilise en Python : à partir du moment où des outils ont été chargés en tête de script, on peut les utiliser librement dans la suite.

Dans l’exemple précédent, l’intérêt de cette nouvelle commande est très discutable bien évidemment, d’autant qu’il faut ajouter une ligne supplémentaire pour qu’elle fonction (use scripting additions est nécessaire pour charger certaines bibliothèques, comme ici celle qui permet de créer des boîtes de dialogue). Dans le cas de longs scripts toutefois, use permet de réduire le nombre de lignes du code, parfois de manière significative.

Autre avantage, on peut combiner deux logiciels en une seule fois, comme le montre cet exemple concret. Dans les deux cas, on lance une recherche dans Safari avec le nom de l’expéditeur du mail sélectionné dans Mail. Avec la commande use, une ligne suffit après avoir convoqué les bibliothèques des deux applications. Sans, il faut d’abord enregistrer dans une variable le nom de l’expéditeur en utilisant la bibliothèque de Mail, puis lancer la recherche avec celle du navigateur.

Outre les applications qui fonctionnent avec AppleScript, cette nouvelle commande sert aussi à invoquer une bibliothèque personnelle. Par rapport à ce que l’on évoquait dans la partie précédente, il y a toutefois un prérequis de plus : un dictionnaire est obligatoire. Si vous comptez utiliser use avec vos propres fonctions codées en AppleScript, il faudra modifier le code et rédiger le dictionnaire.

Nous allons reprendre l’exemple très simple de la partie précédente : la fonction de recherche dans un texte. Le code doit être modifié pour passer de la forme nomFonction(parametre1,parametre2) à la forme nomFonction parametre1 avec parametre2 et c’est le dictionnaire qui va définir le rôle de chaque paramètre. AppleScript est un langage anglophone, mais comme vous définissez votre propre bibliothèque, vous pouvez très bien choisir des paramètres en français. Dans notre exemple, nous avons choisi de définir la fonction ainsi :

L’idée est d’avoir à taper, dans un autre script, cette commande pour invoquer la fonction, où début et fin représentent le début et la fin de la séquence recherchée.

recherche dans "Texte à chercher" de "debut" a "fin"

Pour qu’AppleScript comprenne cette syntaxe qui n’existe pas par défaut, on doit créer un dictionnaire. Ce dernier est en fait un document XML qui respecte une syntaxe imposée par Apple. Nous ne pouvons pas détailler ici la création de ce fichier (la session 416 est très bien faite sur ce point), mais voici à quoi ce fichier doit ressembler pour notre fonction de recherche.

Quelques informations à son sujet :

• Les deux premières lignes définissent le type de fichier, il faut les reprendre systématiquement.
• Les fonctions sont regroupées dans une balise <suite> qui doit absolument être définie par un code à quatre lettres — peu importe le code, mais utilisez uniquement des majuscules.
• Chaque fonction est identifiée par une balise <command> définie cette fois par un code à huit lettres : les quatre de la suite, plus quatre autres que vous choisirez.
• À l’intérieur de la balise <command>, on définit la fonction de chaque paramètre avec d’autres balises :
  • il faut au moins un direct parameter qui est le premier élément après le nom de la fonction ;
  • les paramètres suivants sont optionnels et dépendent de vos besoins ;
  • dans tous les cas, il faut un code à quatre lettres pour chaque paramètre.
• Le fichier doit être enregistré avec l’extension .sdef

Pour associer ce dictionnaire à votre script, vous devez partir d’un script vierge. Dans l’Éditeur AppleScript, créez un fichier que vous sauvegarderez comme un paquet de script, c’est essentiel. Il est important aussi de commencer par insérer le dictionnaire, avant de saisir le code des fonctions. Pour cela, cliquez sur l’icône "Contenu du paquet" et glissez le fichier créé à l’étape précédente dans la zone "Ressources" en bas du panneau qui s’ouvre.

Dernière chose à configurer avant de coller votre code, remplir les champs de la barre latérale. Le plus important est "Définition du pilotage" qui doit être strictement identique au nom du dictionnaire. Une fois que tout est configuré, vous pouvez placer votre code dans l’éditeur et, si tout va bien, vous n’aurez pas d’erreur. Le cas échéant, c’est sûrement que le code XML de votre dictionnaire est mal formé : éditez le fichier pour trouver ce qui ne va pas. Pensez ensuite à placer la bibliothèque dans le bon dossier (cf la partie précédente).

Vous pouvez enfin exploiter votre fonction avec la commande use. Comme on peut le voir sur cet exemple, on charge la bibliothèque personnalisée sur la première ligne et on peut ensuite l’utiliser en respectant la syntaxe définie dans le code de la fonction et dans le dictionnaire. Notez que les mots clés définis précédemment sont bien détectés par l’Éditeur AppleScript qui les affiche en bleu et non en noir.

Cet exemple était volontairement très simple. Pour aller plus loin, vous pouvez télécharger les exemples proposés par Mac OS X Automation.

Un mot pour finir sur le partage des scripts. Si vous voulez utiliser la commande use pour appeler une fonction personnalisée dans un script qui devra être partagé à d'autres utilisateurs, pensez bien à créer un paquet de script et non un script standard et à créer un dossier Scripting Libraries dans les ressources du fichier. Sans cela, le script ou l'application ne fonctionnera pas pour les utilisateurs à qui vous les enverrez.