Implementación del soporte

IMPLEMENTACIÓN DEL SOPORTE

José Narciso López ZamoraRubén Morales Texis

Mildred Morales XicohtencatlIvette Rodríguez Nava

Elizabeth Sánchez Tolamatl

INTRODUCCIÓNEn 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

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

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.

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.

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.

Estandar jerarquico 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

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.

CARACTERISTICAS Administra múltiples e independientes

aplicaciones activas Proporciona independencia de las

especificaciones de programación de diferentes dispositivos de hardware

ARCHITECTURES OF WINDOWING SYSTEMS

ARQUITECTURA DE LOS SISTEMAS DE VENTANAS

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.

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

Control de Aplicaciones Múltiples

Independencia de dispositivo

Programa De

Aplicación

Programa De

Aplicación

Programa De

Aplicación

Mouse

TecladoWindow

1

Window 2

Window n

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.

Aplicación del Cliente

Terminal de abstracto

Controlador de Dispositivo

Gestor de Recursos

Mouse

TecladoWindow

1

Window 2

Window n

Aplicación del Cliente

Aplicación del Cliente

Terminal de abstracto

Terminal de abstracto

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,

- 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.

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.

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.

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

APLICACIÓN DE LA PROGRAMACIÓN.

1. 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

READ – EVALUE. P-1

Flujo de control

Toma de uso

Envía entradas del usuario

PARADIGMA DE NOTIFICACIÓN . P-2

Identificado

1 /* 2 * quit.c -- simple program to display a panel button that says "Quit". 3 * Selecting the panel button exits the program. 4 */ 5 #include<xview/xview.h> 6 #include<xview/frame.h> 7 #include<xview/panel.h> 8 Frame frame; 9 main (argc, argv)10 int argc;11 char *argv[];12 {13 Panel panel;14 void quit();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 void quit()30 {31 xv_destroy_safe(frame);32 }

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.

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_n precessing end case until(end-condition)

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