¿Qué es “AppleScript”?, por Julifos

La descripción más rápida que se me ocurre, es “el lenguaje de programación que, en relación al esfuerzo que cuesta aprenderlo, es el más poderoso que existe para macintosh”. Por supuesto, hay lenguajes mucho más potentes, como C++. Pero AppleScript es sencillísimo de aprender y es capaz, él solito, de manejar todas las rutinas de nuestro ordenador, de mandar órdenes a todos los programas para que actúen así o asá y, al fin, de solucionarnos la vida con el mínimo esfuerzo (que es de lo que se trata este lenguaje).

Yo empecé a trabajar en una editorial en el ’99. Utilicé un mac por primera vez en mi vida. Allí se funcionaba fundamentalmente con Quark, y luego también Adobe Acrobat. Pronto me cansé de andar siempre haciendo lo mismo. Si, por ejemplo, me daban un texto desde Word y tenía que maquetarlo, me tiraba dos horas haciendo búsquedas y reemplazos para limpiar el texto, otras dos horas para aplicar los estilos, y así todo.

Ya no sé de qué manera me dí cuenta de que existía AppleScript. Creo que dí por casualidad con la página de Sal Soghoian, actualmente AppleScript Manager de Apple y uno de los más importantes applescripter de Quark que ha conocido la historia. Allí había algunos scripts que me servían para ahorrar algo de tiempo. Y, por lo poco que leí, parecía que podía hacerse cualquier cosa con el lenguaje en cuestión.

Mi paso más importante fue abrir el primer script (después de haberlo hecho correr, claro). Allí había unas simples palabrejas en inglés que parecían una descripción de lo que hacía el programa, más que el código en sí. Decía cosas del tipo «tell application "QuarkXPress"», «display dialog "Do you wish continue?…"».

Vamos, en resumen, que las cosas se hacen haciéndolas y que, aproximadamente el 90% de los script que uno hace funcionan sólo en su ordenador, porque son cosas que le solucionan a uno la vida. ¿Quién no ha hecho el típico script de ejemplo de vaciar la papelera o imprimir un documento?

Digamos que, por poner un ejemplo, el típico primer script importante del que está aprendiendo puede hacer cosas absolutamente personalizadas, como "dile al Outlook Express que me mire el correo. Si hay algún mensaje, notifícamelo, pero antes vacía la bandeja de entrada, archiva los mensajes antiguos, mira a ver si tengo algo en mi carpeta de documentos pendientes en el Escritorio, y haz lo que diga en ellos. Luego te vas a leer el documento llamado ‘canciones.txt’ que tengo en el Escritorio, y te las descargas con el Interarchy.

Y luego, apaga el ordenador y vete a dormir.". Lo cual quiere decir que, si tenemos costumbre de hacer todas estas cosas antes de apagar, y nos llevan media hora, ahora ¡¡¡podemos darle a un botón e irnos a dormir media hora antes!!!

Parece que Apple va a seguir en la brecha con este lenguaje "casero", porque más que nunca se nota su presencia en la lista de correo, y cada vez facilita más el camino a los desarrolladores independientes de software para que hagan sus aplicaciones "escriptables". Por ejemplo, varias de las aplicaciones más importantes en el mundo de la edición, como Photoshop e Indesign, han sacado un plug-in especial para hacer sus aplicaciones altamente "escriptables". Macromedia hizo también lo propio en su día con Freehand y su Xtra de AppleScript; Quark ha seguido desarrollando la "escriptabilidad" de su producto (con menos que más fortuna, a juzgar por lo que se comenta sobre Quark 5)*, sacando incluso un menú de scripts; y así viene ocurriendo últimamente con productos muy poderosos, como el Outlook Express y el Entourage de Microsoft, el BBEdit y el MailSmith de BareBones, y un larguísimo etcétera.

* Acaba de salir el pre-release de Quark 6, después de AÑOS de espera, la versión para Mac OS X. Como toda beta, es bastante inestable… Pero si funciona bien la versión final, puede ser impresionante, porque tiene un diccionario de casi 50 páginas!

Recuerdo que en mi antiguo trabajo había un viejo mac, que apenas si podía con el OS 8, y que estaba tirado en un rincón. Recuerdo que hice un par de scripts que servían sólo para imprimir documentos de manera automática, y recuerdo también que hubo una época en que yo producía el triple que cualquier empleado (aunque eso no subió mi sueldo, sino que me trajo malos rollos y envidias tontas).

Cómo funciona AppleScript: Apple Events

AppleScript es un lenguaje de script, como puedan serlo Perl o el mismo JavaScript. Así como los elementos de JavaScript son los elementos del navegador, o los de ActionScript los objetos de Flash, la peculiaridad de AppleScript reside en que sus objetos son "cualquier cosa que pertenezca al sistema": documentos, aplicaciones y sus contenidos, etc. En general, casi cualquier cosa que hacemos en el ordenador, se puede replicar con unas líneas de código: vaciar la papelera, escribir un mail, imprimir unos documentos… Todo (¡o casi!).

Dicho de una manera simple, las flechitas rojas de la figura son los "apple event". O sea, unos pequeños comandos que entienden las aplicaciones, que contienen instrucciones precisas acerca de "lo que yo quiero que haga". Los "apple event" es la manera que tienen los programas de relacionarse unos con otros, y AppleScript tiene total autoridad en este campo.

Según está definido en la tabla de Apple Events, cada uno de ellos consta de "class" (a qué tipo pertenecen) un de un &quotid", una identidad, representados ambos por cuatro letras. El "class" es el que suele agruparlos en "Suites" (o sea, grupillos), aunque sólo sea en teoría. Por ejemplo, los eventos de tipo "core" son aquéllos que podríamos llamar "estándar", como, por ejemplo en el "Finder"; «event coredelo» (delete, borrar) o «event corecnte» (count, contar).

Los cuatro eventos más básicos que acepta toda aplicación son run, open, print y quit (aevtoapp, aevtodoc, aevtpdoc, aevtquit), y éstos los manda directamente el Finder. O sea que, aunque una aplicación no sea "scriptable" (esto es, que no le podemos enviar eventos directamente), podemos pedirle al Finder que lo haga él.

Para resumir, cuando ejecutamos un script, éste es gestionado directamente por la extensión o componente "AppleScript", que ejecuta lo

que dice el código.

Hay muchos eventos "escondidos", no definidos por nadie, que hacen cosas muy útiles y que, como diría Paul Bertkowitz, descubrir uno de ellos hace las delicias de cualquier applescripter. Más adelante veremos alguno de estos eventos "secretos".

Pero AppleScript no puede manipular todas las aplicaciones.

Correcto. Así es. Para que una aplicación haga caso a AppleScript, tiene que ser "scriptable". La manera más rápida de saber si una aplicación lo es o no, es dejar caer su icono sobre el icono de un editor de scripts. Si es "scriptable", se abrirá de inmediato su "diccionario", que contiene los comandos que acepta, y que AppleScript puede emplear para comunicarse con ella.

Aún así, casi siempre hay una manera de manipular una aplicación, aun cuando ésta no sea escriptable. ¿Cómo? A través de simulaciones de teclado, o de manipular sus menús. En sistemas anteriores al OS X, existían varios "osaxen" o "adiciones de script" (veremos más adelante qué son) capaces de simular el tecleo. El clásico ejemplo de su uso era abrir el "SimpleText", simular la pulsación de Comando + N (nuevo documento), y luego la de "eres un kapullo", y luego la de Comando + S (guardar). También existía una herramienta magnífica, llamada "PreFab Player", que hacía lo mismo, y llegaba allí donde no llegaban los demás: menús, botones, pop-up, manejo de diálogos modales, etc.

En OS X tenemos, recién salido del horno, el nuevo experimento de Apple, llamado "UI Scripting". Básicamente, es lo mismo que era PreFab Player, a través de "System Events" (una aplicación que viene instalada por defecto), pero sólo es capaz de acceder a elementos de aplicaciones basadas en Cocoa (con Carbon no suele funcionar). Eso sí, lo hace muy bien (teniendo en cuenta que es una beta), y puede acceder a absolutamente todos los elementos de la visibles de la aplicación.

También tenemos Extra Suites, de Kanzu software, que puede simular tecleos, y más cosas interesantes.

En fin, una ventaja de AppleScript es que cuenta con muchas ayudas externas 😉

La sintaxis de AppleScript es, por lo general, sencilla e intuitiva, aunque hay algunos programadores que lo hacen realmente difícil… Pero por lo

común, son órdenes en inglés legible y con parámetros comprensibles. Por ejemplo:

Devolverá como resultado los primeros 20 caracteres contenidos en el documento "mi documento", contenido en la carpeta "mi carpeta" del disco "mi disco".

Esto mismo, traducido al castellano, sería algo así como:

Sencillo, ¿no? ¡No hace falta un doctorado!

En cuanto al DOM (Document Object Model), como se llama en otros lenguajes, también suele ser sencillo. Por ejemplo, una aplicación contiene documentos, que contienen texto, que contienen palabras, que contienen letras. El clásico ejemplo para Mac OS X:

Aunque, más precisamente, diríamos que una aplicación contiene objetos con propiedades. Por ejemplo, podríamos haberle pedido a "TextEdit" que nos dijera el tamaño de letra de dicha palabra diciendo "size of word 1", y nos habría devuelto su tamaño, en forma de número real: 12.0. O podríamos preguntarle cuántas letras tiene con "count characters of word 1": 7.

En JavaScript, si hay por aquí algún javascripter, y para trasladar el ejemplo, podemos preguntar por el número de letras que hay en el campo de texto de un formulario:

Y en un script de la shell, el tamaño en bytes de un documento:

Aunque ahora que lo pienso, éste último ejemplo no tiene nada que ver. ¿Qué se le va a hacer?