Los eventos de Apple son el mecanismo de comunicación entre procesos basado en mensajes en Mac OS , que apareció por primera vez en System 7 y es compatible con todas las versiones del Mac OS clásico desde entonces y 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 "hacer clic" y "pulsar una tecla". Los eventos de Apple forman la base del sistema de scripting de Mac OS, la Open Scripting Architecture (el lenguaje principal es AppleScript ).
El punto de partida es un formato de descriptor extensible y de tipo dinámico llamado AEDesc , que es simplemente un código OSType que especifica el tipo de datos, junto con un bloque de datos dependientes del tipo. Por ejemplo, el código OSType inteindica 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, hay dos tipos de descriptores estructurados predefinidos: un AERecord , que tiene tipo de datos reco(registro), y AEList con tipo list(lista o matriz). La estructura interna de estos contiene AEDescs anidados recursivamente, mientras que AERecord también asocia cada elemento con un ID de campo de registro único, que es un OSType. Apple Event Manager proporciona llamadas API para construir estas estructuras, así como extraer su contenido y consultar el tipo de contenido que contienen.
Apple Event Manager también admite coerciones , que convierte AEDescs de un tipo de datos a otro. Además de las coerciones estándar, por ejemplo entre tipos enteros y reales, las aplicaciones pueden instalar sus propias devoluciones de llamada de controlador de coerción , que manejan conversiones hacia y desde tipos de datos personalizados.
Un evento de Apple propiamente dicho es un AERecord con campos que dependían del propósito del evento. Además, tiene atributos (que son distintos de los campos de registro, que ahora se denominan parámetros del evento) de un conjunto predefinido por Apple Event Manager. Estos especifican lo que se supone que debe hacer el evento (a través de la clase de evento y el ID del evento ), la dirección de destino a la que se enviará el evento (que podría ser un proceso en la máquina local o remota) y varias otras opciones para manejarlo. él. Inicialmente, las máquinas remotas debían conectarse a través de AppleTalk , pero Mac OS 9 agregó la opción de conexiones a través de TCP/IP .
Después de enviar un evento de Apple a su proceso de destino, el proceso de envío puede optar por recibir una respuesta a un evento de Apple. Esto puede contener varios bits de información devueltos por el objetivo sobre el procesamiento del evento original, incluido un código de error que indica éxito/fracaso, cualquier información solicitada por el evento original y/u otra información apropiada.
Los eventos de Apple son la base del modelo de objetos AppleEvent , que a su vez es la base de OSA y AppleScript . A partir de 2016 [actualizar], la implementación oficial de la API de Apple Event Manager está disponible en C y sus descendientes, incluido C++ . También se proporcionan enlaces oficiales para Objective-C y Swift a través de Cocoa API . También existen enlaces no oficiales para otros lenguajes (con distintos grados de limitación), incluidos Perl , UserTalk , Ruby y Python .
El modelo de objetos AppleEvent ( AEOM ) era un conjunto de protocolos creados sobre AppleEvents mediante el cual las aplicaciones que se ejecutaban en Mac OS y macOS clásicos podían controlar las funciones de cada una. Las aplicaciones que implementaban alguna parte de AEOM se denominaban programables porque podían controlarse mediante AppleScript . Desafortunadamente, la compatibilidad con la capacidad de secuencias de comandos siguió siendo irregular e inconsistente a lo largo de la historia del Mac OS clásico.
La AEOM proporcionó una capa sintáctica bajo la cual cualquier aplicación podía publicar sus objetos internos, permitiendo que esos objetos fueran manipulados de manera estandarizada. A diferencia de otros conceptos que suenan similares, como ToolTalk , existía una distinción clara y ortogonal entre sustantivos y verbos ; por lo tanto, en lugar de proporcionar comandos separados para "cerrar documento" y "cerrar ventana", había un único verbo "cerrar" que podía hacer referencias a objetos "documento" o "ventana", o cualquier otro objeto que publicara la aplicación.
Los objetos que una aplicación puso a disposición a través de su soporte AEOM estaban organizados en una jerarquía. En la parte superior estaba la aplicación en sí, a la que se hace referencia mediante un descriptor de objeto nulo. Se hizo referencia a otros objetos especificando (recursivamente) su objeto principal, junto con otra información que lo identifica como hijo de ese padre, todo recopilado en un AERecord . Los padres proporcionaban un iterador para enumerar a sus hijos, o hijos de una determinada clase, lo que permitía que las aplicaciones abordaran un conjunto de elementos. El sistema era en general similar al modelo de objetos de documento utilizado en XML , aunque con algunas diferencias en los patrones de acceso.
Cada objeto podrí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 cambiarse. Por ejemplo, la aplicación puede tener uno o más elementos de ventana que representen ventanas que muestren el contenido de los documentos actualmente abiertos. Estas ventanas pueden tener propiedades como título, posición y tamaño.
Una aplicación podría definir verbos personalizados para operar en sus objetos. La AEOM también especificó varios verbos estándar que (se esperaba) las aplicaciones implementarían de manera consistente, como abrir, cerrar, crear elemento, eliminar, configurar datos y obtener datos. Cada verbo se definió como un AppleEvent de un tipo y clase específicos, junto con parámetros particulares de tipos particulares que se esperaba que estuvieran presentes. Por ejemplo, el evento "obtener datos" era el medio estándar para obtener el valor de una propiedad: esencialmente se necesitaba 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" tomó dos parámetros, el descriptor de objeto de la propiedad a establecer y el nuevo valor de la propiedad; Solo se esperaba que el evento de respuesta devolviera un estado de éxito o un código de error de error.
Toda la arquitectura AppleEvent identifica cosas usando códigos OSType de cuatro bytes , evitando cuidadosamente palabras o frases reales en inglés (o cualquier otro idioma). En cambio, la correspondencia entre los códigos internos de AppleEvent y las descripciones externas en lenguaje natural se especifica a través del recurso aete ( AppleEvent Terminology Extension ) : la "extensión" es la terminología estándar integrada en el propio AppleScript. Una aplicación puede proporcionar múltiples recursos 'aete' para múltiples idiomas, de acuerdo con el diseño multilingüe original del propio AppleScript.
Por ejemplo, considere la siguiente secuencia de AppleScript que controla una aplicación de dibujo ficticia:
decirle a la aplicación "ScriptableDraw" que establezca el color de fondo de la ventana "Nuevo Dibujo" en el color de fondo de la ventana "Dibujo Antiguo" finalizar decirleEn realidad, esto implica el envío de dos AppleEvents a la aplicación de destino (y la recepción de sus respuestas correspondientes): primero, se envía un evento de obtención de datos para recuperar la propiedad de color de fondo de la ventana identificada con el nombre "Dibujo antiguo"; luego se envía un evento de datos establecidos para aplicar el valor devuelto como propiedad de color de fondo de la ventana denominada "Nuevo dibujo".
Dado que este tipo de patrón de acceso era típico, AppleScript hizo un uso generalizado de la telldeclaración, que cambiaba el contexto al objeto nombrado de una manera similar a la withdeclaración encontrada 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 permitieron la identificación de objetos de diversas formas. La más interesante fue usar una cláusula dónde (que se tradujo a la terminología de AppleScript como expresión de filtro ). Por ejemplo, el SDK de AppleScript 1.0 se envió con el código fuente de una aplicación de ejemplo llamada Scriptable Text Editor, que respondería a scripts como:
decirle a la aplicación "Editor de texto programable" decirle a la ventana "Documento de ejemplo" establecer el estilo de texto de cada palabra cuya longitud > 7 hasta el final en negrita decirle al final decirle Incluso hoy en día, es raro encontrar este tipo de potencia en lenguajes de programación 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 tuvieron que identificar sus objetos y escribir código a mano para poder abordarlos. Por lo general, esto tomaba la forma de código para devolver el "siguiente" objeto de un tipo particular, lo que permitía a AppleScript iterar sobre ellos. Pero como el sistema operativo no contenía un modelo de objetos, este trabajo quedó enteramente en manos de los desarrolladores, muchos de los cuales no lo implementaron. Curiosamente, incluso el propio marco de aplicaciones de Apple , MacApp , no ofrecía dicho modelo excepto para los objetos GUI que conocía, lo que una vez más hizo que el desarrollador hiciera la mayor parte del trabajo de crear scripts para los objetos que representan los datos mismos. En gran parte por estas razones, la compatibilidad con AppleScript no estaba muy extendida.
Apple intentó abordar este problema con la introducción de varios "conjuntos" de objetos, que representaban objetos y verbos estándar que se esperaba que fueran compatibles con diferentes tipos de aplicaciones. Por ejemplo, se esperaba que todas las aplicaciones admitieran el "conjunto principal" y que cualquier aplicación de edición de texto admitiera el "conjunto de texto". Al seleccionar un conjunto adecuado de suites, el desarrollador podría al menos reducir la carga de trabajo de planificar cómo exponer sus objetos. Sin embargo, debido a que estos objetos generalmente no eran parte del sistema en sí (con la excepción del editor TextEdit, muy limitado), la implementación real se dejó en manos del desarrollador.
Las aplicaciones desarrolladas en Cocoa , el sistema anteriormente conocido como OpenStep , ofrecen un tiempo de ejecución de objetos enriquecido que se puede consultar desde cualquier otra aplicación. Esto facilita considerablemente la implementación de AEOM, reduciendo drásticamente la cantidad de código necesario en una aplicación promedio. Además, la mayoría de las aplicaciones Cocoa se construyen principalmente a partir de objetos estándar Cocoa, todos los cuales se actualizaron para ofrecer una capacidad de secuencias de comandos bastante amplia. Esto se extiende no sólo a los objetos GUI como en MacApp, sino también a los objetos de datos dentro de ellos, incluidos texto, tablas y varios objetos de lista. Se utiliza un archivo de texto para asignar los nombres internos "similares a objetos" a versiones legibles por humanos y, en la mayoría de los casos, crear esto es todo lo que se necesita para agregar una capacidad de secuencias de comandos bastante sustancial a la mayoría de los programas.
Si bien las aplicaciones Cocoa no están basadas en AEOM y, a menudo, utilizan objetos sutilmente diferentes a los objetos estándar definidos originalmente por Apple, las aplicaciones Cocoa generalmente son mucho más programables que sus contrapartes "clásicas"; de hecho, es poco común encontrar una aplicación Cocoa que no sea programable. hasta cierto grado.
Scripting Bridge es un marco de macOS que permite que las aplicaciones se comuniquen entre sí sin el uso de un lenguaje de scripting intermediario como AppleScript . Al igual que AppleScript, Scripting Bridge utiliza eventos de Apple para la comunicación entre aplicaciones . [1]
El Scripting Bridge se usa típicamente 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 .
{{citation}}: Mantenimiento CS1: falta el editor de la ubicación ( enlace ). En particular, consulte la Sección 2.3 “Apple Events” (páginas 9 a 13), aunque la historia y la importancia de Apple Events también se analizan en otras partes del documento.