Los eventos de Apple son el mecanismo de comunicación entre procesos basado en mensajes en Mac OS , aparecieron por primera vez en System 7 y son compatibles con todas las versiones del Mac OS clásico desde entonces y con macOS . Los eventos de Apple describen eventos de "alto nivel" como "documento abierto" o "archivo de impresión", mientras que los sistemas operativos anteriores habían admitido eventos mucho más básicos, a saber, "clic" y "pulsación de tecla". Los eventos de Apple forman la base del sistema de secuencias de comandos de Mac OS, la Arquitectura de secuencias de comandos abierta (el lenguaje principal de este tipo es AppleScript ).
El punto de partida es un formato descriptor extensible de tipo dinámico llamado AEDesc , que es solo 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 inte
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, hay dos tipos de descriptores estructurados predefinidos: un AERecord , que tiene un 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 a la API para construir estas estructuras, así como extraer su contenido y consultar el tipo de contenido que contienen.
Apple Event Manager también admite coacciones , que convierte AEDescs de un tipo de datos a otro. Además de las coacciones 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 dependen 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 de manejo eso. Inicialmente, las máquinas remotas tenían que estar conectadas 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 un evento de Apple de respuesta. 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 diversos grados de limitación), incluidos Perl , UserTalk , Ruby y Python .
Modelo de objeto
El modelo de objetos AppleEvent ( AEOM ) era un conjunto de protocolos creados sobre AppleEvents mediante los cuales las aplicaciones que se ejecutaban en el Mac OS clásico y macOS podían controlar las funciones de cada uno. Las aplicaciones que implementaron alguna parte de AEOM se denominaron programables porque podían controlarse a través de 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.
El 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 de sonido similar como ToolTalk , había una distinción clara y ortogonal entre sustantivos y verbos ; así, en lugar de proporcionar comandos separados para "cerrar documento" y "cerrar ventana", había un solo verbo "cerrar" que podía hacer referencias a objetos "documento" o "ventana", o cualquier otro objeto que la aplicación publicara.
Los objetos que una aplicación puso a disposición a través de su soporte AEOM se organizaron en una jerarquía. En la parte superior estaba la aplicación en sí, referenciada 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 proporcionaron un iterador para enumerar a sus hijos, o hijos de una determinada clase, lo que permite que las aplicaciones se dirijan a un conjunto de elementos. En general, el sistema era similar al modelo de objetos de documento utilizado en XML , aunque con algunas diferencias en los patrones de acceso.
Cada objeto puede tener elementos y propiedades ; Los elementos eran otros objetos que podían crearse o borrarse, mientras que las propiedades no podían crearse ni borrarse pero tenían valores que podían ser interrogados o cambiados. Por ejemplo, la aplicación puede tener uno o más elementos de ventana que representan ventanas que muestran el contenido de los documentos abiertos actualmente. Estas ventanas pueden tener propiedades como su título, posición y tamaño.
Una aplicación podría definir verbos personalizados para operar en sus objetos. El AEOM también especificó varios verbos estándar que (se esperaba) las aplicaciones implementarían de manera consistente, como abrir, cerrar, crear elemento, eliminar, establecer 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: se necesitaba esencialmente un parámetro, que era un descriptor de objeto que identificaba la propiedad a consultar. El valor de esa propiedad se devolverá en el evento de respuesta. El evento "establecer datos" tomó dos parámetros, el descriptor de objeto para la propiedad a establecer y el nuevo valor para la propiedad; solo se esperaba que el evento de respuesta devolviera un estado de éxito o un código de error de falla.
Toda la arquitectura AppleEvent identifica cosas utilizando códigos OSType de cuatro bytes , evitando cuidadosamente palabras o frases reales en inglés (o en cualquier otro idioma). En cambio, la correspondencia entre los códigos internos AppleEvent y descripciones en lenguaje natural externos se especifica a través de la aete ( AppleEvent Terminología de extensión ) de recursos - la "extensión" estar a la terminología estándar incorporado en sí AppleScript. Una aplicación puede proporcionar múltiples recursos 'aete' para múltiples idiomas, de acuerdo 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:
decirle a la aplicación "ScriptableDraw" establecer el color de fondo de la ventana "Nuevo dibujo" al color de fondo de la ventana "Dibujo antiguo" end tell
En realidad, esto implica el envío de dos AppleEvents a la aplicación de destino (y la recepción de sus correspondientes respuestas): 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 de conjunto para aplicar el valor devuelto como la 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 tell
declaración, que cambió el contexto al objeto nombrado de una manera similar a la with
declaración que se encuentra en Visual Basic o Pascal . Todos los comandos posteriores tell
al correspondiente end tell
se 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 varias formas. El más interesante fue el uso de una cláusula where (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 secuencias de comandos como:
decir a la aplicación "Editor de texto programable" ventana de decir "Documento de ejemplo" establecer el estilo de texto de cada palabra cuya longitud > 7 hasta el final en negrita decir fin decir
Incluso hoy en día, es raro encontrar este tipo de poder 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 a mano para poder abordarlos. Normalmente, 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 se dejó completamente a los desarrolladores, muchos de los cuales no lo implementaron. Curiosamente, incluso el propio marco de aplicaciones de Apple , MacApp , no ofrecía tal modelo a excepción de los objetos GUI que conocía, lo que una vez más hizo que el desarrollador hiciera la mayor parte del trabajo de programar los objetos que representan los datos en sí. En gran parte por estas razones, el soporte de AppleScript no estaba muy extendido.
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 la "suite principal", y se esperaba que cualquier aplicación de edición de texto admitiera la "suite 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 severamente limitado), la implementación real se dejó al desarrollador.
Las aplicaciones desarrolladas en Cocoa , el sistema anteriormente conocido como OpenStep , ofrecen un tiempo de ejecución de objetos rico que se puede consultar desde cualquier otra aplicación. Esto hace que la implementación del AEOM sea considerablemente más fácil, reduciendo drásticamente la cantidad de código necesario en la aplicación promedio. Además, la mayoría de las aplicaciones de Cocoa se construyen principalmente a partir de objetos estándar de Cocoa, todos los cuales se actualizaron para ofrecer una capacidad de escritura bastante amplia. Esto se extiende no solo 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 mapear los nombres internos "similares a objetos" en 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 secuencia de comandos bastante sustancial a la mayoría de los programas.
Si bien las aplicaciones Cocoa no se basan en AEOM y, a menudo, utilizan objetos sutilmente diferentes a los objetos estándar definidos originalmente por Apple, las aplicaciones Cocoa son generalmente 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.
Otras lecturas
- Cook, William R. (29 de septiembre de 2006), AppleScript (PDF) , Universidad de Texas en Austin, págs. 1–1–1–21, CiteSeerX 10.1.1.76.6993 , doi : 10.1145 / 1238844.1238845 , consultado el 9 de mayo de 2009. En particular, consulte la Sección 2.3 “Eventos de Apple” (páginas 9 a 13), aunque la historia y la importancia de los Eventos de Apple también se discuten en otra parte del documento.
enlaces externos
- appscript: puente de eventos de Apple para Python, Ruby y Objective-C