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
cliente de la
aplicación
cliente de la
aplicación
Resumen de
terminales
Resumen de
terminales
gestor de
recursos
controladores
de dispositivo
Ventan
a2
ratón
Ve
nta
na
1
Ventana
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 lecturaevaluación.
Comienza
Lee la entrada
Servidor
Procesa la
entrada
Salir
?
Termina
Dispositiv
o

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.
comienzo
registro de las
devoluciones de
llamada con el
notificador
El paradigma de la comunicación basada en la
programación
Notificad
Aplicació
or
n
Llama al
notificador
Lee la entrada
Fin
Procesa el
evento
Enviar la
devolución
apropiada
seguir
?
si
no
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
type_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.
Descargar

Arquitecturas de sistema de ventanas