Implementación del soporte

1. Implementación del soporte José Narciso López Zamora Rubén Morales Texis Mildred Morales Xicohtencatl Ivette Rodríguez Nava Elizabeth Sánchez Tolamatl

2. Introducción En este capítulo trataremos las varias capas que constituyen el movimiento del hardware bajo la programación. Comenzaremos con: • El sistema de ventanas • Paradigmas de programación

3. Elementos del sistema de ventana Un sistema de ventana se usa para construir una interfaz WIMP. Una característica importante de este sistema es que proporciona al programador independencia de los detalles específicos de dispositivos de hardware

4. Terminal abstracto • Para lograr esta independencia, el programador usa un terminal abstracto, el cual entiende varios lenguajes genéricos y puede traducir el lenguaje especifico de un dispositivo • Un controlador de dispositivo es usado para traducir las funciones de un dispositivo especifico.

5. Modelo de imagenes • Un sistema de ventanas usa un lenguaje generico fijo para el terminal abstracto llamado modelos de imagenes. • Se usa para describir imágenes y manejar imágenes ya sea como imágenes de pixeles o definiciones de fuentes.

6. Modelo de imagenes • Pixeles: la pantalla se divide en filas y columnas de puntos. • Sistema grafico de kernel (GKS): Es un estándar y un lenguaje de graficos, permite que las aplicaciones graficas sean desarrolladas en un sistema. • Estandarjerarquico de graficas interactivas para el programador (PHIGS): Es otro estandar basado en GKS. • PostScript: Es un lenguaje de programacion OO que se usa para describir una imagen, trata a las imágenes como colecciones de objetos geometricos y no como mapa de bits

7. El sistema de ventanas soporta varias tareas de usuario simultaneas compartiendo los recursos de una sola configuracion de hardware con varias copias de un terminal abstracto. • Cada terminal abstracto se comporta como un proceso independiente y el sistema coordina el control de estos.

8. Caracteristicas • Administra múltiples e independientes aplicaciones activas • Proporciona independencia de las especificaciones de programación de diferentes dispositivos de hardware

9. Architectures of windowing systems Arquitectura de los sistemas de ventanas

10. Bass y Coutaz, • 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.

11. 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. • Desventaja - Sincronización

12. Programa De Aplicación Programa De Aplicación Programa De Aplicación Control de Aplicaciones Múltiples Independencia de dispositivo Window 2 Mouse Window 1 Teclado Window n

13. La segunda opción es llevar a cabo la función de gestión dentro del kernel del sistema operativo, la centralización de la gestión de tareas liberándola de la aplicación individual.

14. Aplicación del Cliente Aplicación del Cliente Aplicación del Cliente Terminal de abstracto Terminal de abstracto Terminal de abstracto Gestor de Recursos Controlador de Dispositivo Window 2 Mouse Window 1 Teclado Window n

15. 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 por lo tanto puede proporcionar una interfaz para programas de aplicación que es genérico en todos los sistemas operativos. Esta última opción se conoce como la arquitectura cliente - servidor,

16. Las aplicaciones construidas para un sistema de ventana basado en el modelo servidor-cliente. Un ejemplo clásico de un sistema de la ventana basado en la arquitectura del cliente-servidor es Sistema industria-estandar X, desarrollado por el Instituto de Massachusetts en 1980.

18. El servidor de X realiza las tareas siguientes: • Acceso a la pantalla de Aplicaciones. • Interpreta las peticiones de los clientes para realizar operaciones o facilitar otra información. • Interpretacion de los eventos de entrada física del usuario y los pasa al cliente adecuado. • Seguimiento de la información como las fuentes, en estructuras complejas de datos, los clientes pueden acceder a los números de identificación.

19. Un cliente del gestor de ventanas por separado - hace cumplir las políticas para resolver los conflictos y las solicitudes de entrada de salida desde y hacia los demás clientes. • Gestores de ventanas que se pueden utilizar en X por ejemplo; • El gestor de ventanas que decide cómo el usuario puede cambiar la entrada de una aplicación a otra. • Ejemplo de política del gestor de ventanas es la de si las imágenes son visibles de los clientes.

20. Politicas • Reglas para la transferencia de datos entre los clientes. • Métodos para seleccionar el cliente activa el foco de entrada. • Esquemas de trazado de la superposición de ventanas / azulejos como regiones de la pantalla

21. Aplicación de la programación. Programación de uso interactivo Correspondiente a un cliente en la arquitectura del servidor. 2 paradigmas de programación utilizados para la organización de control de flujo. Leer evaluación. Notificación basada en programación

22. Read – evalue. P-1 Toma de uso Flujo de control Envía entradas del usuario

23. Paradigma de notificación . P-2 Identificado

24. 1 /* 2 * quit.c -- simple programtodisplay a panel buttonthatsays "Quit". 3 * Selecting the panel buttonexits the program. 4 */ 5 #include<xview/xview.h> 6 #include<xview/frame.h> 7 #include<xview/panel.h> 8 Frameframe; 9 main (argc, argv)10 intargc;11 char *argv[];12 {13 Panel panel;14 voidquit();15 xv_init(XV_INIT_ARGC_PTR,ARGV, &argc, argv, NULL);16 frame=(Frame)xv_create(NULL, FRAME,17 FRAME_LABEL, argv[0],18 XV_WIDTH, 200,19 XV_HEIGHT, 100,20 NULL);21 panel = (Panel) xv_crate(frame, PANEL, NULL);22 (void) xv_crate(panel, PANEL_BUTTON,23 PANEL_LABEL_STRING, "Quit",24 PANEL_NOTIFY_PROC, quit,25 NULL);26 xv_main_loop(frmae);27 exit(0);28 }29 voidquit()30 {31 xv_destroy_safe(frame);32 }

25. Supongamos que 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.

26. repeat read-event(myevent) case myevent.type type_1: do type_1 processing type2: ... if (error-condition) then repeat read-event(myevent2) case myevent2.type type_1: . . .type_n: end case until (end-condition2) end if ......type_n: do type_nprecessing end case until(end-condition)

27. Figura 8.7 Pantalla de la imagen producida por el ejemplo del programa quit.c