evento de Apple

Los eventos de Apple son el mecanismo de comunicación entre procesos basado en mensajes de Mac OS , que apareció por primera vez en System 7 y ha sido compatible con todas las versiones del Mac OS clásico desde entonces, así como con macOS . Los eventos de Apple describen eventos de "alto nivel", como "abrir documento" o "imprimir archivo", mientras que los sistemas operativos anteriores admitían eventos mucho más básicos, como "clic" y "pulsación de tecla". Los eventos de Apple constituyen la base del sistema de scripting de Mac OS, la Open Scripting Architecture (cuyo lenguaje principal es AppleScript ).

El punto de partida es un formato de descriptor extensible y de tipado dinámico llamado AEDesc , que consiste simplemente en un código OSTypeinte que especifica el tipo de datos, junto con un bloque de datos dependientes del tipo. Por ejemplo, el código OSType indica que los datos eran un entero con signo de cuatro bytes en formato big-endian .

Además de los códigos de tipo predefinidos para varios tipos simples comunes, existen dos tipos de descriptores estructurados predefinidos: un AERecord , que tiene el tipo de datos reco(registro), y un AEList, con el tipo list(lista o matriz). La estructura interna de estos contiene AEDescs anidados recursivamente, mientras que el AERecord también asocia cada elemento con un ID de campo de registro único, que es un OSType. El Administrador de eventos de Apple proporciona llamadas a la API para construir estas estructuras, así como para extraer su contenido y consultar el tipo de contenido que contienen.

El Administrador de eventos de Apple también admite conversiones , que transforman los AEDesc de un tipo de dato a otro. Además de las conversiones estándar, por ejemplo, entre tipos enteros y reales, las aplicaciones pueden instalar sus propias funciones de devolución de llamada para gestionar las conversiones , que se encargan de las conversiones hacia y desde tipos de datos personalizados.

Un evento de Apple propiamente dicho es un AERecord con campos que dependen de su propósito. Además, posee atributos (distintos de los campos del registro, ahora llamados parámetros del evento) de un conjunto predefinido por el Administrador de eventos de Apple. Estos especifican la función del evento (mediante la clase y el ID del evento ), la dirección de destino a la que se enviará (que puede ser un proceso en la máquina local o remota) y diversas opciones para su gestión. Inicialmente, las máquinas remotas debían conectarse mediante AppleTalk , pero macOS 9 añadió la opción de conexión mediante TCP/IP .

Tras enviar un evento de Apple a su proceso de destino, el proceso emisor puede optar por recibir una respuesta. Esta respuesta puede contener diversa información devuelta por el proceso de destino sobre el procesamiento del evento original, incluyendo un código de error que indique si la operación fue exitosa o fallida, cualquier información solicitada por el evento original y/u otra información pertinente.

Los eventos de Apple son la base del AppleEvent Object Model , que a su vez es la base de OSA y AppleScript . A partir de 2016La implementación oficial de la API de Apple Event Manager está disponible en C y sus derivados, incluido C++ . También se proporcionan enlaces oficiales para Objective-C y Swift a través de la API de Cocoa . Existen además enlaces no oficiales para otros lenguajes (con distintos grados de limitación), como Perl , UserTalk , Ruby y Python .

El AppleEvent Object Model ( AEOM ) era un conjunto de protocolos basados ​​en AppleEvents que permitían a las aplicaciones que se ejecutaban en macOS clásico y macOS controlar las funciones de las demás. Las aplicaciones que implementaban alguna parte del AEOM se denominaban programables porque podían controlarse mediante AppleScript . Lamentablemente, la compatibilidad con la programación fue irregular e inconsistente a lo largo de la historia de macOS clásico.

El AEOM proporcionaba una capa sintáctica bajo la cual cualquier aplicación podía publicar sus objetos internos, permitiendo que estos se manipularan de forma estandarizada. A diferencia de otros conceptos similares, como ToolTalk , existía una distinción clara y ortogonal entre sustantivos y verbos ; así, en lugar de proporcionar comandos separados para "cerrar documento" y "cerrar ventana", existía un único verbo "cerrar" que podía referirse a objetos "documento" o "ventana", o a cualquier otro objeto que la aplicación publicara.

Los objetos que una aplicación ponía a disposición mediante su compatibilidad con AEOM se organizaban jerárquicamente. En la cúspide se encontraba la propia aplicación, referenciada mediante un descriptor de objeto nulo. Otros objetos se referenciaban especificando (recursivamente) su objeto padre, junto con otra información que los identificaba como hijos de dicho padre, todo ello recopilado en un AERecord . Los padres proporcionaban un iterador para enumerar sus hijos, o los hijos de una clase determinada, lo que permitía a las aplicaciones acceder a un conjunto de elementos. El sistema era, en general, similar al Modelo de Objetos de Documento (DOM) utilizado en XML , aunque con algunas diferencias en los patrones de acceso.

Cada objeto podía tener elementos y propiedades ; los elementos eran otros objetos que podían crearse o eliminarse, mientras que las propiedades no podían crearse ni eliminarse, pero tenían valores que podían consultarse o modificarse. Por ejemplo, la aplicación podía tener uno o más elementos de ventana que representaban ventanas que mostraban el contenido de los documentos abiertos. Estas ventanas podían tener propiedades como su título, posición y tamaño.

Una aplicación podía definir verbos personalizados para operar sobre sus objetos. El AEOM también especificaba varios verbos estándar que (se esperaba) las aplicaciones implementarían de forma consistente, como abrir, cerrar, crear elemento, eliminar, establecer datos y obtener datos. Cada verbo se definía como un AppleEvent de un tipo y clase específicos, junto con parámetros particulares de tipos específicos que se esperaba que estuvieran presentes. Por ejemplo, el evento "obtener datos" era el método estándar para obtener el valor de una propiedad: tomaba esencialmente un parámetro, que era un descriptor de objeto que identificaba la propiedad que se iba a consultar. El valor de esa propiedad se devolvería en el evento de respuesta. El evento "establecer datos" tomaba dos parámetros, el descriptor de objeto para la propiedad que se iba a establecer y el nuevo valor para la propiedad; se esperaba que el evento de respuesta solo devolviera un estado de éxito o un código de error.

Toda la arquitectura de AppleEvent identifica los elementos mediante códigos OSType de cuatro bytes , evitando cuidadosamente palabras o frases reales en inglés (o cualquier otro idioma). En su lugar, la correspondencia entre los códigos internos de AppleEvent y las descripciones externas en lenguaje natural se especifica mediante el recurso aete ( AppleEvent Terminology Extension ) , donde la "extensión" se refiere a la terminología estándar integrada en el propio AppleScript. Una aplicación puede proporcionar varios recursos 'aete' para varios idiomas, en consonancia con el diseño multilingüe original de AppleScript.

Por ejemplo, considere la siguiente secuencia de AppleScript que controla una aplicación de dibujo ficticia:

Dile a la aplicación "ScriptableDraw" que establezca el color de fondo de la ventana "Nuevo dibujo" al color de fondo de la ventana "Dibujo antiguo". Fin de la instrucción.

Esto implica el envío de dos eventos Apple a la aplicación de destino (y la recepción de sus respuestas correspondientes): primero, se envía un evento get-data para recuperar la propiedad de color de fondo de la ventana identificada con el nombre "Old Drawing"; luego, se envía un evento set-data para aplicar el valor devuelto como propiedad de color de fondo de la ventana llamada "New Drawing".

Dado que este tipo de patrón de acceso era típico, AppleScript hizo un uso generalizado de la tellinstrucción, que cambiaba el contexto al objeto nombrado de una manera similar a la withinstrucción que se encuentra en Visual Basic o Pascal . Todos los comandos posteriores tellal correspondiente end tellse enviarían al objeto nombrado en tell, en lugar del objeto predeterminado, que era la aplicación actual.

Los descriptores de objetos permitían la identificación de objetos de diversas maneras. La más interesante era mediante una cláusula where (que en la terminología de AppleScript se traduce como una expresión de filtro ). Por ejemplo, el SDK de AppleScript 1.0 incluía el código fuente de una aplicación de ejemplo llamada Editor de texto programable, que respondía a scripts como:

dile a la aplicación "Editor de texto programable" dile a la ventana "Documento de ejemplo" establece el estilo de texto de cada palabra cuya longitud sea mayor que 7 a negrita fin dile fin dile

Incluso hoy en día, es raro encontrar este tipo de potencia en lenguajes de scripting de propósito general fuera de SQL .

Agregar soporte para AEOM en el Mac OS clásico fue un proceso difícil. Los desarrolladores de aplicaciones tenían que identificar sus objetos y escribir código manualmente para poder acceder a ellos. Esto generalmente se manifestaba en forma de código para devolver el siguiente objeto de un tipo específico, lo que permitía a AppleScript iterar sobre ellos. Pero como el sistema operativo no contenía un modelo de objetos, este trabajo quedaba completamente en manos de los desarrolladores, muchos de los cuales no lo implementaban. Curiosamente, ni siquiera el propio marco de aplicaciones de Apple , MacApp , ofrecía dicho modelo, excepto para los objetos de la interfaz gráfica de usuario que reconocía, lo que obligaba una vez más al desarrollador a realizar la mayor parte del trabajo de programación de los objetos que representaban los datos. En gran medida por estas razones, el soporte para AppleScript no estaba muy extendido.

Apple intentó solucionar este problema con la introducción de varios conjuntos de objetos, que representaban objetos y verbos estándar compatibles con distintos tipos de aplicaciones. Por ejemplo, se esperaba que todas las aplicaciones fueran compatibles con el conjunto principal, y que cualquier aplicación de edición de texto fuera compatible con el conjunto de texto. Al seleccionar un conjunto adecuado, el desarrollador podía, al menos, reducir la carga de trabajo de planificar cómo exponer sus objetos. Sin embargo, dado que estos objetos generalmente no formaban parte del sistema (con la excepción del editor TextEdit, que tenía funcionalidades muy limitadas), la implementación quedaba a cargo del desarrollador.

Las aplicaciones desarrolladas en Cocoa , el sistema anteriormente conocido como OpenStep , ofrecen un entorno de ejecución de objetos enriquecido que puede consultarse desde cualquier otra aplicación. Esto simplifica considerablemente la implementación del AEOM, reduciendo drásticamente la cantidad de código necesaria en la mayoría de las aplicaciones. Además, la mayoría de las aplicaciones Cocoa se construyen principalmente a partir de objetos estándar de Cocoa, los cuales se actualizaron para ofrecer una amplia capacidad de scripting. Esto se extiende no solo a los objetos de la interfaz gráfica de usuario (GUI), como en MacApp, sino también a los objetos de datos que contienen, incluyendo texto, tablas y diversos objetos de lista. Se utiliza un archivo de texto para asignar los nombres internos, similares a los de los objetos, a versiones legibles para humanos , y en la mayoría de los casos, crear este archivo es todo lo que se necesita para añadir una capacidad de scripting considerable a la mayoría de los programas.

Si bien las aplicaciones Cocoa no se basan en AEOM y a menudo utilizan objetos ligeramente diferentes a los objetos estándar definidos originalmente por Apple, en general son mucho más programables mediante scripts que sus contrapartes "clásicas"; de hecho, es raro encontrar una aplicación Cocoa que no sea programable en cierta medida.

Scripting Bridge es un marco de trabajo de macOS que permite que las aplicaciones se comuniquen entre sí sin utilizar un lenguaje de scripting intermedio como AppleScript . Al igual que AppleScript, Scripting Bridge utiliza eventos de Apple para la comunicación entre aplicaciones . ^{[ 1 ]}

El Scripting Bridge se usa normalmente desde Objective-C , ^{[ 1 ]} pero se puede usar en otros lenguajes de programación a través de un puente Objective-C como MacRuby ^{[ 2 ]} y PyObjC .

• Cook, William R. (29 de septiembre de 2006), "AppleScript" (PDF) , Actas de la tercera conferencia ACM SIGPLAN sobre la historia de los lenguajes de programación , Universidad de Texas en Austin, págs.  1–1–1–21, CiteSeerX 10.1.1.76.6993 , doi : 10.1145/1238844.1238845 , ISBN  9781595937667, S2CID 220938191 , consultado el 9 de mayo de 2009 {{citation}}: CS1 maint: falta el editor de la ubicación ( enlace ) . En particular, consulte la Sección 2.3 “Eventos de Apple” (páginas 9-13), aunque la historia y la importancia de los Eventos de Apple también se analizan en otras partes del documento.

• appscript — Puente de eventos de Apple para Python, Ruby y Objective-C