Craig Federighi : Apple n'a pas enterré les scripts dans macOS
Les scripts et l’automation ont un avenir chez Apple. Après le départ visiblement forcé de Sal Soghoian, à qui l’on doit la plupart des outils permettant de créer et d’utiliser des scripts sur macOS, l’inquiétude est forte chez les amateurs d’AppleScript, d’Automator et consorts. Et il est vrai que Soghoian a laissé fortement penser que l’avenir de cette pratique était compromise du côté de Cupertino.
Un lecteur de 9to5Mac a demandé à Craig Federighi quelle était la position d’Apple après que l’entreprise eut montré la porte de sortie à ce vieux routier du Mac. Le vice président en charge du logiciel a pris le temps de répondre et surtout, de rassurer :
C’est assurément une bonne nouvelle, même si Apple concentre ses ressources sur Swift plutôt que sur ses outils de scripts. Automator, lancé avec Mac OS X 10.4, a reçu très peu de mises à jour depuis, et il n’existe pas de solution « maison » de script pour iOS (on peut en passer par des applications tierces comme Workflow).
L’avenir semble de toutes manières briller plus du côté de Swift, dont Apple assure une grosse promotion. Des ateliers Heure de Code autour du langage de programmation vont être organisés début décembre dans les Apple Store.
En même temps, Craig allait pas répondre : "fuck off"
Pour moi macOS s'éteint doucement
"En même temps, Craig allait pas répondre : "fuck off""
Il n'aurait pas répondu.
Ce qu'il faut comprendre, c'est que le départ de Sal Soghoian n'est pas lié à la disparition de l'automatisation de Mac OS X
Mais donc il reste pas mal de possibilités.
J'en vois essentiellement deux :
- Refus de Sal Soghoian à passer à Swift plutôt qu'AS ?
- Problème de personne entre un nouveau manager et Sal Soghoian ?
Quoi qu'il en soit, soit AS reste avec automator (cool) soit Apple a dans ses cartons un truc génial bien plus cool et ouvert, plus standard, plus simple à mettre en place etc... (super cool)
Pas de quoi pleurer donc.
Ben en fait, non AS et Automator ne sont pas geniaux du tout et posent de nombreux problemes.
Je vais pasrevenir sur la syntaxe et la logique bizare d'AS, il y a une partie subjective et on peut s'y faire si on fait que ça.
Le probleme c'est l'inconsistance et la difficulté de mise en oeuvre.
Un systeme de scripting, d'automatisation, implique de pouvoir controler les composants (applications, services, extensions,...) selon un protocole standard et systematique. Ça veut dire que n'importe quelle application doit etre pilotable de la meme maniere.
Avec Automator et AppleScript c'est pas du tout le cas.
Il faut que les applications soient prevues et programmées specifiquement pour repondre a Applescript. C'est pas universel ni automatique, beaucoup d'applications ne sont simplement pas scriptables.
Le probleme est encore plus gros avec Automator, puisque il faut que des modules soient fournis par l'editeur pour remplir des taches specifiques et limités: impossible d'acceder a des fonctions non prevues.
Et c'est un tres gros probleme, le principe du scripting etant justement de permetre un usage non couvert par une fonction du logiciel.
Je prends un exemple simple: une excellente application, tres bien programmée, activement développée et tres fonctionnelle, PixelMator, n'est pas scriptable.
Impossible d'automatiser la generation de fichiers a partir de layer, et avec un nom normalisé. C'est un traitement tout ce qu'il y a de plus automatisable et qui est contre productif de faire a la main, et pourtant c'est pas possible, parce que l'application n'est pas scriptable.
On peut reprocher aux editeurs de ne pas concevoir l'application pour etre scriptable, mais en vérité le problème vient de MacOS: si le systeme de scripting etait consistant les logiciels seraient automatiquement scriptable, au moins pour les fonctions de base. Non, il faut developper spécifiquement.
@C1rc3@0rc
Tu décris de nombreux problèmes liés aux limites d'Automator. Cela ne signifie en rien qu'Automator n'est pas génial. C'est tout le challenge proposé aux développeurs d'applications. Il faut qu'ils les rendent modulaires et scriptables.
Sous Windows, il n'y a pas d'équivalent à Automator et tu dois tout faire à la main. Tu dois répéter les mêmes actions manuelles des centaines de fois !!!
Laisse-moi te donner un exemple de processus Automator que j'avais réalisé et qui m'avait vraiment facilité la vie.
Contexte :
J'avais besoin de me constituer une bibliothèque d'images. Si tu lances Bing (le moteur de recherche de Microsoft), chaque jour il y a une nouvelle image. J'avais trouvé un site où il y en avait des centaines de toutes sortes.
Sous Windows pour récupérer les images tu fais clic droit puis enregistrer sous... et tu répètes des centaines de fois la même manip ! Tu y passes un temps fou !
Avec Automator, tu lui donnes l'URL puis il y a une action Safari pour récupérer les images de la page (en fait il scrute les balises HTML img).
Automator, les récupère dans un dossier de ton choix. Ensuite, j'enchainais par un redimensionnement des images pour qu'elles aient toutes les mêmes dimensions et enfin par un renommage avec un préfixe particulier.
Pour récupérer des centaines d'images et les reformater, avec Automator ça te prend entre 5 à 15 minutes et tu ne te fatigues pas.
Essaie de faire ça avec le système de Microsoft. Tu m'en diras des nouvelles...
Cool non !
Et si tu fais ça avec un outil comme Selenium, tu passes moins de temps à créer ton script, non ?
Et cerise sur le gâteau, il est multiplateforme !
Cool
@Un Vrai Type
Tu n'as rien compris. Selenium ne permet que de faire des traitements Web. Automator fait des tas de choses !
Pour quelqu'un comme moi qui a l'habitude d'utiliser Automator, le workflow pour récupérer des images, les redimensionner et les renommer ne prend que 5 minutes à écrire et à tester !
Je ne vois pas comment tu peux dire que l'on passe du temps à créer des workflows avec Automator. C'est juste que tu ne l'utilises pas !
Selenium ne peut pas te réveiller le matin et lancer iTunes !
Donc tu n'as rien compris à l'éventail des possibilités d'Automator !
Pour faire tout ce que Automator est capable de faire, sous Windows il te faut combien de logiciels spécifiques pour traiter une tâche particulière ?
Sors-moi la liste de toutes les applis dont tu as besoin sous Windows pour faire l'équivalent de tout ce que Automator peut faire !
Automator est pré-installé sur Mac.
Hi hi hi !!!!!
@Un Vrai Type
Pour enfoncer un peu plus le clou et pour te montrer que tu n'as rien compris aux possibilités d'Automator voici la suite du traitement que j'avais réalisé :
Une fois les images récupérées, redimensionnées et renommées, je créais un dossier compressé que j'envoyais via FTP sur un serveur (toujours avec Automator). Ensuite un autre processus Automator lié au dossier (processus action sur dossier) sur le serveur de récupération, décompressait l'archive et copiait les images dans un dossier d'images d'un site web destinataire des images.
Les images étaient ensuite disponibles dans mes pages web.
Mais le dossier compressé tu peux aussi l'envoyer par Mail avec Automator au lieu de l'envoyer par FTP. Etc, etc, etc...
Tu peux toujours essayer de faire tout ça avec Selenium, tu m'en diras des nouvelles !...
Hi hi hi
@ C1rc3@0rc : « la logique bizare d’AS »
La logique est pourtant très classique et la même qu’on trouve dans la plupart des langages les plus connus.
« on peut s'y faire si on fait que ça. »
Même si on ne fait pas que ça, d’ailleurs.
« Et c'est un tres gros probleme, le principe du scripting etant justement de permetre un usage non couvert par une fonction du logiciel. »
Pas vraiment. Le principe des scripts, c’est de combiner les fonctions des logiciels de la façon qu’on veut.
« On peut reprocher aux editeurs de ne pas concevoir l'application pour etre scriptable, mais en vérité le problème vient de MacOS: si le systeme de scripting etait consistant les logiciels seraient automatiquement scriptable, au moins pour les fonctions de base. »
Ce passage-là est juste du grand n’importe quoi. J’ai du mal à voir comment on arriverait à des logiciels scriptables automatiquement sans aucun effort à fournir de la part de leurs développeurs.
«Mais donc il reste pas mal de possibilités.
J'en vois essentiellement deux :
- Refus de Sal Soghoian à passer à Swift plutôt qu'AS ?
- Problème de personne entre un nouveau manager et Sal Soghoian ?
»
On ne vire pas un architecte logiciel pour un conflit avec un manager, ou alors c'est que la societe est suicidaire. On vire plutot le manager...
Ajouter Swift au langages de controle du scripting est quelque chose de relativement simple et c'est une option qui ne signifie pas degager AS. On peut utiliser Javascript a la place d'AS.
Donc ces possibilités semblent improbables comme cause du depart de Soghoian.
Jusqu'a present les "départs" de personnes clés se sont fait sur des questions de pouvoir (conflit avec Ive principalement) ou des reorientations d'architecture en profondeur, voire suppression de fonctionnalité.
Comme je le dis precedemment, l'automatisation sur MacOS est loin d'etre une reussite, et c'est d'autant plus grave qu'on est sur une base Unix qui est conceptuelement construite pour l'automatisation. Il y a donc une rupture de la logique du systeme a un tres haut niveau.
Se pose le probleme de la securité.
On voit que depuis quelques annees Apple s'oriente sur une voie securitaire construite sur la restriction et la fermeture. Et c'est pas une reussite.
Le scripting, s'il est mal fait, ouvre des breches dans la securité, on le voit bien sur Windows avec des virus qui exploitent le Basic dans Office par exemple.
Apple a choisi d'interdire le scripting dans iOS. Pourtant iOS c'est 95% MacOS.
Automator implique de rajouter des modules dans le systeme qui exploitent les fonctionnalité des applications... Cela est contraire a la logique de SIP par exemple.
Pendant des annees MacOS a ete fourni avec Python et Ruby, principaux langages de scripting, et auquel Apple avait contribué a l'integration. Ce n'est plus le cas.
Donc cela fait beaucoup d'elements qui sont de mauvaise augure pour le scripting sur MacOS
@C1rc3@0rc
"ou alors c'est que la societe est suicidaire" ??
C'était un homme clef dont dépendait une grande part de l'avenir économique de l'entreprise? ?
@C1rc3@0rc
A oui tu considères bien le mec comme une ressource clef ?
C’est vraiment ton truc la SF ??
@C1rc3@0rc
"Pourtant iOS c'est 95% MacOS"
Une de tes connerie favorite ?
"On ne vire pas un architecte logiciel pour un conflit avec un manager, ou alors c'est que la societe est suicidaire. On vire plutot le manager..."
Non seulement ça a été la politique de Microsoft pour Internet Explorer (ce qui explique de la version 7 n'est pas une évolution de la version 6 qui n'est pas une évolution de la version 5, mais la version 7 contient les moteurs de rendus des versions antérieures : Les managers sont les mêmes, les ingénieurs ont changés) mais en plus, je vois EXACTEMENT la même situation en ce moment chez un client.
Il faut bien comprendre que les décideurs n'entendent pas les petites gens. Si une personne bien placée peut dire à T.Cook "Soghoian il est méchant avec moi, il m'empêche de faire des trucs géniaux", Soghoian lui ne peut pas se défendre, et ne sera entendu que par les RH qui auront déjà l'instruction de le débarquer.
Voilà la réalité d'entreprise.
@ C1rc3@0rc : « et c'est d'autant plus grave qu'on est sur une base Unix qui est conceptuelement construite pour l'automatisation. Il y a donc une rupture de la logique du systeme a un tres haut niveau. »
Ça aussi, c’est n’importe quoi.
« Automator implique de rajouter des modules dans le systeme qui exploitent les fonctionnalité des applications... »
Non.
« Cela est contraire a la logique de SIP »
Non plus.
Cette réponse tend à confirmer l'hypothèse du développement de nouveaux outils d'automation, plus modernes. ?
Automator c'est cool ?, mais il y a surement moyen de faire encore mieux ! ☝️
@patrick86
Pas impossible que le départ soit motivé par un conflit autour de l'avenir de cette démarche sur macOS non pas en terme d'abandon mais de redéfinition de l'approche sur des bases plus modernes ?
Sur un divorce il est toujours dangereux de ne se fier qu'à un son de cloches ?
@awk
En parlant de cloche...
@mctos
Bravo, quel prodigieux sens de la répartie ?
@awk
C'est sa façon de raisonner à lui.
@Bigdidou
?
Super! Maintenant on attend les réponses de Mr Langue-de-bois (Schiller) sur:
1. Origine des problèmes graphiques/ssd des nouveaux MBP
2. Pourquoi un prix si élevé?
3. À quand le renouvellement du Mac Pro et Mac Mini?
4. Pourquoi le nouveau MBP est fourni sans chiffon et cordon d'alimentation?
...
@mat 1696
tu t'es trompé de news manifestement.
Pourquoi un prix si élevé ? parce que :
le processeur est nouveau et plus cher
le SSD est nouveau extrêmement performant et plus cher
le tracpad est beaucoup plus grand et plus cher
quatre connecteurs sont multifonctions avec des contrôleurs plus complexes et beaucoup plus chers que de simples USB A
les hauts parleurs sont nouveaux plus performants et plus chers
il y a un processeur en plus pour le touch id et un processeur n'est pas gratuit
il y a un nouveau processeur pour le touch bar et un processeur ce n'est pas gratuit
il y a un touch bar Oled qui est infiniment plus cher que les touches fonctions
il il a le lecteur du touch id qui n'est pas gratuit
parce qu'il a fallu développer deux ans pour le nouveau touch bar (un nouvel OS), la nouvelle carte mère, le corps du macbook, les nouvelles intégrations, le nouveau clavier etc et 2 ans de R&D avec des centaines d'ingénieurs, le prototype etc ce n'est pas gratuit
etc. Je suppose que vous vous travaillez gratuitement et que les matériaux que vous utilisez quand vous bricolez vous sont offerts par Leroy Merlin
pour votre 4 vous inventez, il est vrai que le titre de MacGe était mensonger. Le cordon d'alimentation y est bien, c'est la rallonge qui n'y est plus, pas plus qu'elle n'y est pour les iPad et autres iPhone qui n'ont pas non plus de mac safe ce qui n'en secoue pas une aux utilisateurs comme dirait Mac Ge et qui pourtant ont infiniment plus de risques de se faire valdinguer qu'un macbook.
@Malum
Pas le bon sujet, pas le bon forum, pas le bon argumentaire...
Pff Craig me déçoit il aurait dû mettre amazing à la place de great ?????
:)
J'ai raté le début du film mais jai mon pop corn et mes lunette 3D ?
Je suis prêt pour la séance de troll ????
Automator c'est pas cool, c'est super cool !
Tous les matins je me réveille grâce à Automator.
Mon iMac s'allume à 7h et lance au démarrage un processus Automator qui consiste à régler le volume du système à 75%, puis le processus sélectionne ma playlist de radios web et finalement lance iTunes.
Et donc, tous les matins c'est Automator qui lance la radio et me réveille.
Merci Automator !
Surtout qu'Apple continue de perfectionner Automator. Moi, j'adore ! C'est Unique sur Mac.
Sous Windows c'est impossible de faire simplement ce que l'on peut faire avec Automator !
Et demain, tu diras :
"Hey Siri, réveille moi les jours ouvrés de travail à 7h avec un volume à 75% avec ma playlist radios web".
"J'ai ajouté un script à jouer tous les jours de la semaine sauf samedi, dimanche et jours fériés avec ces actions :
- Positionner le volume à 75%
- Ouvrir iTunes
- Jouer la playist radio web
Ai-je fait une erreur ?"
"Parfait"
Bref, AS est peut-être un frein à demain...
@Un Type Vrai
Eh bien écoute, Siri est intégré dans Sierra et il ne fait pas grand chose ! Tu n'as pas Sierra peut être ?
Il n'est ni capable d'allumer l'ordinateur ni de l'éteindre, il peut seulement le mettre en veille !
Il peut ouvrir les app mais pas les fermer etc...
Peut être qu'après après-demain en 2030 tu lui diras :
"Hey Siri, réveille moi les jours ouvrés de travail à 7h avec un volume à 75% avec ma playlist radios web".
Ai-je fait une erreur ?
Siri est un truc assez décevant de la part d'Apple. Passée la découverte des petites blagounettes de Siri, le machin est très limité !
Bref, pour le moment, seul Automator est capable de répondre à mon besoin.
Je réitère ma demande, qu'Apple continue de l'améliorer !
A moins que Google Home fasse le job en 2017 !...
lol
Siri c'est une technologie qui a plus de 30 ans, si c'etait efficace pour quelque chose on le saurait depuis le temps.
Apple a recuperé, comme d'autres, ce produit mis au placard par les militaires et épousseté par SRI, une fois de plus.
Avoir des gros datacenter avec des lutins qui traitent a la main les requetes pas encore entrées dans la base de données, c'est une chose, l'informatique conversationnelle et l'IA c'est autre chose. Mais avant de parler d'IA, y a deja la reconnaissance vocale simple qui fonctionne bien et permet de lancer des automatisations existante. Sauf que c'est pas exploité en dehors de l'aide "d'accessibilité", cherchez l'erreur
Aujourd'hui Apple ne sait plus innover sur la micro, alors ils font comme les autres paumés du secteur informatique et balancent des termes dont le marketing s'est emparé pour faire du moderne et vendre cher des materiels depassés: cloud, IA, deep learning, big data...
Le probleme c'est que ces technologies ne sont pas de la micro-informatique. Toutes celles proposées aujourd'hui reposent sur du datacenter et du traitement centralisé sur des monstres de calcul. Pour quoi Apple les emploie: pour un service gadget auprès d'un utilisateur d'informatique GP individuelle!
Si on veut ajouter de l'automatisation aux machines, cela se fait par la programmation local et rien d'autre. Le scripting c'est de la programmation. On peut en masquer la complexité de realisation derriere une interface graphique, de la programmation visuelle, mais cela reste de la programmation.
Et tout existe pour faire ça depuis les annees 80, et c'est souvent construit sur Smalltalk. Le chainage et la construction d'une automatisation en assemblant des bloc a la Lego, ça date et pourtant s'il y a bien un OS qui aurait du l'integrer c'est bien MacOS et iOS. Nan!
Faut se souvenir aussi du succés d'Hypercard, et si on le ponette avec la puissance d'aujourd'hui on aurait un systeme fantastique. Nan!
@C1rc3@0rc
"Siri c'est une technologie qui a plus de 30 ans, si c'etait efficace pour quelque chose on le saurait depuis le temps.
Apple a recuperé, comme d'autres, ce produit mis au placard par les militaires et épousseté par SRI, une fois de plus."
Tout s'explique !
@C1rc3@0rc
Que d'aigreurs ?
"Il n'est ni capable d'allumer l'ordinateur ni de l'éteindre, il peut seulement le mettre en veille !
Il peut ouvrir les app mais pas les fermer etc..."
Peut-être que le coût pour faire ce que je décris est multiplié par 100 avec AppleScript.
Et que donc sans AppleScript, mais avec une autre approche plus moderne (et plus proche des API qu'Apple maitrise à fond), demain ce sera possible.
Je dis bien DEMAIN. Et Demain, ça peut-être 2017 (sans AS) ou 2107 ;-) avec.
@Un Vrai Type
"Peut-être que le coût pour faire ce que je décris est multiplié par 100 avec AppleScript."
Tu es juste un petit rigolo, qui n'a jamais utilisé Automator ni AppleScript.
Exemple :
tell application "iTunes"
set sound volume to 75
play playlist "Mes radios web"
end tell
Ah oui ! C'est long à écrire ! Comme tu dis ! Il faut au moins avoir fait polytechnique !
lol
"Automator, lancé avec Mac OS X 10.4, a reçu très peu de mises à jour depuis, ..."
Hum…
Pour dire cela, il ne faut pas beaucoup utiliser Automator.
Attention aussi qu'à trop renouveler on risque de rendre obsolète des actions tierces forts utiles.
@Moonwalker
Je suis dans doute allé un peu vite en besogne ?
ils l'ont viré pour les transformer ces outils de scripts. ça peut devenir plus intéressant.
jamais utilisé pour ma part
Mais lol quoi. Apple ne sort qu'un portable bling bling alors que ça sa machine pro n'a plus de mise à jour depuis longemps et vous pensez encore qu'automator à un avenir ?
Désolé je me suis réveillé depuis longtemps.
@iZolmax
Parce que toi tu vois un rapport avec la choucroute?
Suis-je bête il y a un type qui bosse sur le MacPro et c'est le même qui s'occupe de la technologie de script de OS X.
Je remarque que niveau soft (techno dans le coeur de Mac OS X) c'est vraiment d'un très haut niveau depuis quelques années.
Je suis d'accord que niveau hardware, Apple essaye de mettre les codes du succès de l'iPhone dans le Mac, et ça, c'est moche pour moi... (pas pour tout le monde apparement).
C'est pas tant les scripts la problématique, quoi qu'elle soit symptomatique de l'inadéquation d'un langage avec le fonctionnement d'une interface utilisateur.
Mais bon, si une application fourni correctement sa capacité d'interaction programmable à l'utilisateur d'un langage*, c'est déjà un bien du passé.
Par contre automatiser (scripter) l'interactivité entre l'interface et l'utilisateur … tout en tenant compte de l'utilisation qui en est faite sur le moment ?
Ce serait du jamais vu !!!
* logiquement, on devrait pouvoir faire tout ça graphiquement en se passant de langage !!!
@ovea :
"Par contre automatiser (scripter) l'interactivité entre l'interface et l'utilisateur … tout en tenant compte de l'utilisation qui en est faite sur le moment ?
Ce serait du jamais vu !!!"
Automator permet d'enregistrer une séquence d'actions exécutées à la souris et au clavier, mais c'est perfectible. Ça ne fonctionne pas toujours bien si les conditions initiales (app en premier plan, fenêtre ouvertes et leurs positions, etc.), ne sont pas identiques à celles lors de l'enregistrement.
Il faudrait vraiment enregistre le clic sur le menu Fichier de cette app là, je veux dire au nom de l'app en question, et non de celle qui se trouve ne premier plan.
Si ca fonctionne comme ça, c'est un peu con !
Je ne connais pas bien cette app, mais j'imaginais que Automator devait être capable de savoir à quel process appartient la fenêtre sur laquelle on a cliqué lors de l'enregistrement.
"Appel de la fonction liée au "Click" du bouton "valider" de la fenêtre "supprimer" de l'app "machinchose"
Et non pas
"Click" sur position 572,466, quelque soit ce qu'il y a dessous, bon ça c'est fait, ok, on passe à l'étape suivante
Si ca marche comme ça, c'est même super dangereux.
"Appel de la fonction liée au "Click" du bouton "valider" de la fenêtre "supprimer" de l'app "machinchose"
C'est comme cela que fonctionne GUI Scripting sur macOS.
@françois bayrou
« "Click" sur position 572,466, quelque soit ce qu'il y a dessous, bon ça c'est fait, ok, on passe à l'étape suivante »
C'est exactement comme ça que ça marchait déjà en MacPascal, sur Mac Plus, en 1986...
Et oui, ça peut être dangereux.
Et oui, pour que ce ne soit pas dangereux, il faut implémenter soi-même des structures de contrôle et des garde-fous,
À l'époque, c'était même plus facile, à condition d'avoir les volumes d'Inside Macintosh sous la main.
Et puis les OS calls étaient aptes à changer quand les Mac changeaient de ROM, et ça devenait du salmigondis ingérable.
Alors, si @Un Type Vrai a raison, plus loin, d'espérer qu'Apple nous fasse la divine surprise d'un scripting décent, efficace, intégré à Swift, ça serait super.
Mais ils devraient démontrer que cela fonctionne, sans trop de hics, avant de bousiller tous nos workflows.
L'élection de Trump devrait avoir rappelé à tout le monde un vieil adage technique :
« It's one thing to tear down the old shithouse.
It's an entirely different thing to install sanitation.
Do it in the wrong order, and all you're left with is a huge heap of shit. »
@ovea
« Par contre automatiser (scripter) l'interactivité entre l'interface et l'utilisateur … tout en tenant compte de l'utilisation qui en est faite sur le moment ?
Ce serait du jamais vu !!!
* logiquement, on devrait pouvoir faire tout ça graphiquement en se passant de langage !!! »
Il y eut certains concepts très prometteurs dans le genre au début des années '80, dont quelques-uns sur Mac. Mais il furent abandonnés en cours de route, faute de ressources, faute de suivi, faute d'intérêt de la part d'Apple, et en vertu du dumbing-down généralisé des années MS-DOS et Windows première mouture.
Aujourd'hui, les ressources seraient là.
Mais il faudrait que les utilisateurs soient considérés par Apple en premier lieu comme des créateurs adultes capables de générer et de gérer un workflow, éventuellement même pour des activités professionnelles, et non pas comme des consommateurs qu'on n'a pas encore réussi à prendre par la main et à conduire doucement vers le monde merveilleux de Walt Disney, pardon, d'iOS.
Ça, ce serait vraiment du jamais vu.
Et plus tard, quand le post-mortem de macOS sera établi, on s'étonnera de l'immense potentiel créatif galvaudé, et des chances incroyables ratées à chaque tournant.
Si, si !
Quartz Composer (acheté par Apple, je me souvient plus du nom précédent).
Te souviens tu ?
Ça c'était GENIAL ! (surtout la possibilité d'ajouter un script javascript pour certaines actions).
Haaaa qu'est-ce que j'ai fait de ces économiseur d'écran qui allaient chercher des infos à droite ou à gauche et de ces petits jeux débiles en quelques heures...
Pages