1.-En estos temas se va dar a conocer las herramientas necesarias para la aplicación de un sistema interactivo haciendo énfasis en la programación.

2.-Las Herramientas de programación para sistemas interactivos proporcionan un medio eficaz para traducir los diseños abstracción y los principios de usabilidad en una forma ejecutable. Estas herramientas proporcionan diferentes niveles de servicios para el programador.

3.- El kits de herramientas de interacción abstracto le permitirá al programador describir los comportamientos de los objetos a un nivel similar a cómo los percibe el usuario.

4.- En los sistemas de gestión de la interfaz de usuario son el nivel final de las herramientas de soporte de programación que permite al diseñador y programador controlar la relación entre los objetos y las herramientas con su funcional en la aplicación actual.

 capacidad para proporcionar independencia al programador de los detalles de los dispositivos de hardware. Una estación de trabajo típica implicará alguna pantalla de visualización, un teclado y un dispositivo señalador como un ratón. Cualquier variedad de estos dispositivos de hardware se puede utilizar en cualquier sistema interactivo y todos ellos son diferentes en cuanto a los datos que se comunican y los comandos que se utilizan para instruirlos.

 Es imprescindible ser capaz de programar una aplicación que se ejecuta en una amplia gama de dispositivos. Para ello, el programador tiene que dirigir una terminal de comandos, que comprende un lenguaje más genérico y puede ser traducido, y también a muchos otros dispositivos específicos. Además de hacer más fácil la tarea de programación, el terminal abstracto hace que la portabilidad de los programas de aplicación sea posible.

 Sólo un programa de traducción o controlador de dispositivo tiene que ser escrito para un dispositivo de hardware en particular y luego cualquier programa de aplicación puede acceder a él.

 Un sistema de ventanas dado tendrá un lenguaje genérico fijado para el terminal abstracto que se llama la imagen de modelos. Las imágenes de modelos son suficientes para describir imágenes muy arbitrarias. Por razones de eficiencia, primitivas específicas se utilizan para manejar imágenes de texto, ya sea como imágenes de píxeles específicos o definiciones de fuente como más genéricos

 Píxeles la pantalla se representa como una serie de columnas y filas de puntos o píxeles que pueden ser explícitamente encendido o apagado, o le da un color. Se trata de un modelo común de imágenes para ordenadores personales.

 Sistema gráfico del kernel (GKS) Una norma internacional de los modelos de pantalla como una colección de segmentos conectados, cada uno de ellos es una macro de comandos de gráficos elementales.

 Interfaz Jerárquico del Programador de Gráficos (PHIGS) Otra norma internacional, basado en GKS, pero con una extensión al modelo de la pantalla en forma de segmentos editable.

 PostScript Un lenguaje de programación desarrollado por Adobe Corporation, los modelos de pantalla son como un conjunto de caminos que sirven como límites infinitamente delgadas o las plantillas que se pueden rellenar con colores o patrones de textura e imágenes

 Bass and Coutaz [29] identifica tres posibles arquitecturas de software para implementar las funciones de un sistema de ventanas. todos ellos asumen que los controladores de dispositivos son independientes de los programas de aplicación. la primera opción es implementar y replicar la gestión de los múltiples procesos dentro de cada una de las aplicaciones por separado

 esto no es una arquitectura muy satisfactorio ya que si las fuerzas de cada aplicación para estudiar los problemas difíciles de resolver los conflictos de sincronización con los dispositivos de hardware.

 la segunda opción es llevar a cabo la función de gestión dentro de la kernel del sistema operativo, la centralización de la gestión de tareas liberándola de las aplicaciones individuales. aplicaciones aún debe ser desarrollado con las características específicas del sistema operativo en particular en mente

 la tercera opción ofrece la mayor portabilidad, como la función de gestión que está escrito como una aplicación independiente por derecho propio y el apoyo a la gestión de los recursos compartidos.

cliente de la aplicación Resumen de terminales controladores de dispositivo gestor de recursos

Ventan a 2 Ve nta na 1 Ventana n ratón Teclado

 un ejemplo clásico de sistema de ventanas basado en la arquitectura cliente-servidor es el sistema estándar de la industria de ventanas X, deloped en el Instituto Tecnológico de Massachusetts (MIT) en 1980

Aplicación cliente Servidor_______ Controladores de dispositivos Ventana del administrado r de clientes teclado ratón 8,3 el sistema X de Windows (liberación II) de la arquitectura

 Cada cliente del servidor XII es asociado a una abstracta terminal o principal ventana El servidor X realiza las siguientes tareas:

 Permite acceder a la visualización de multiples aplicaciones de clientes  Interpreta las peticiones de los clientes para realizar la operación de la pantalla o proporciona otro tipo de información  Multiplexa la corriente de los eventos de entrada física del usuario y los pasa al cliente adecuado  Minimiza el trafico en la red mediante el alivio de los clientes de tener que realizar un seguimiento de la información a determinadas, como las fuentes, en estructuras complejas de datos que los clientes puedan acceder por ID de números

 Un gerente independiente como lo es el gerente hace cumplir las políticas para resolver los conflictos y las solicitudes de entrada y salida hacia los demás clientes El gerente también adopta diferentes políticas también tiene la opción de moverse dentro de las demás ventanas

 Permite la transferencia de datos entre clientes  Métodos para seleccionar un cliente  El cliente activa el foco de entrada  Esquema de trazo de la superposición de ventanas/azulejos como regiones de la pantalla

En la programación de la aplicación se describe paradigmas de programación que se puede utilizar para organizar el flujo de control dentro de la aplicación.  El primero es el de lectura-evaluación, que es interno en la misma aplicación.

 Diagrama del paradigma de lectura- evaluación. Lee la entrada Procesa la entrada Servidor Salir ? Dispositiv o Comienza Termina

 Cuando el notificador recibe un evento del sistema, ve si el evento fue identificado por el programa de aplicación y si es así, pasa a la eventos y el control sobre el procedimiento de devolución de llamada que se ha registrado para el evento. Después del procesamiento del evento, se va al procedimiento de devolución de llamada y devuelve el control al notificador, ya sea para continuar recibiendo los eventos o solicitar la terminación.

registro de las devoluciones de llamada con el notificador Llama al notificador Procesa el evento Lee la entrada Enviar la devolución apropiada seguir ? comienzo no si Fin Notificad or Aplicació n El paradigma de la comunicación basada en la programación

El programa presenta una ventana o marco, con un botón, la etiqueta dejar de fumar, cuando se selecciona el dispositivo de señalización hace que el programa deje de hacerlo. El programa de aplicación se inicia al notificante por la xv_main_loop llamada de procedimiento. Cuando el notificador recibe un evento de seleccionar el botón, se pasa el control a la salir de procedimiento que destruye la estructura exterior y la terminación peticiones.

Supongamos que haiga la condición de error durante el procesamiento de un caso de type_2 tipo. Una vez que la condición de error se reconoce, la aplicación comienza otro ciclo de lectura y evaluación de contenidos dentro de la rama de la declaración del caso. Dentro de ese bucle, todos los eventos no relevantes pueden ser recibidos y descartados. El ejemplo dado anteriormente pseudocódigo podría ser modificado de la siguiente manera:

repeat read-event(myevent) case myevent.type type_l : do type_l processing type_2 : if (error-condition) then repeat read-event(myevent2) case myevent2.type type_l type_n : end case until (end-condition2] end if t y p e _ n : do type_n processing end case until (end-condition)

En el paradigma de la comunicación basada en un diálogo preventivo no sería tan simple, porque el flujo de control está fuera de las manos del programador de aplicaciones. Los procedimientos de devolución de llamada a todos tendría que ser modificado para reconocer las situaciones en que es necesario el diálogo preventivo y las situaciones caso omiso de todos los eventos que se transmiten a ellos por el notificante. Para ayudar en el diseño de gestores de ventanas específicas, el Consorcio X bas produjo el Inter-cliente Convenciones del manual (ICCCM), que establece las convenciones de diversas cuestiones de política que no están incluidos en la definición de X.