Construcción de Interfaces a Usuario: Toolkits

Niveles de Abstracción de un SI

Núcleo Funcional

Control del Diálogo

Objetos de Interacción

Sistema de Ventanas

Drivers

Control de losdispositivos físicos

Control de losrecursos E/S

Control de losobjetos de interacción

Control del secuen-ciamiento de las acciones del usuario -

Conocimiento del dominio

Incremento en elnivel de abstracción

Objetos de Interacción Objetos de Interacción (OI): abstracciones de

software representando conceptos sintácticos o semánticos en la interacción

‘widgets’ (X-Windows), “controles” (Macintosh, MS Windows), “objetos” (NeXTStep)

En muchos casos, establecen la forma de utilizar un dispositivo de input para ingresar un valor dado

Generalmente disponibles a través de bibliotecas (‘toolkits’).

Algunos ejemplos comunes de OI : Menúes Botones Barras de desplazamiento Cajas para ingreso de texto

Objetos de Interacción El comportamiento del OI está incluido dentro

de su implementación En principio, no puede ser modificado por el

operador El comportamiento puede ser adaptado, por medio

de la especificación de ciertos atributos Incluyen comportamiento de output e input:

output: comportamiento perceptible, en términos de propiedades visuales o auditivas

ej. forma, highlighting, sonido input: determina las acciones físicas que puede

realizar el operador ej. movimiento de iconos, selecciones en un menú

Objetos de Interacción Ocultan los detalles de bajo nivel

Los servicios provistos por los sistemas de ventanas poseen un nivel de abstracción demasiado bajo

Los eventos del usuario son convertidos en eventos con un nivel de abstracción mayor

ej. doble click comando de selección El proceso cliente es notificado del evento, pero no de

las acciones de bajo nivel efectuadas por el operador El cliente especifica las propiedades de la presentación,

pero la implementación específica es ocultada por el OI En general, los OI son incapaces de interactuar

directamente con otros OI La interacción debe ser efectuada por el control del

diálogo.

Objetos de Interacción: Ejemplo

Comportamiento determinado por la implementación del OI Especificado parcialmente por el operador y/o el proceso cliente

Print

Unhighlightedunset

Print

MouseEnter

Highlightedunset

Print

MousePressed

Highlightedset

Print

MouseReleased

Highlightedunset

Print

MouseLeaves

Unhighlightedunset

Creación OI La creación y modificación de los OI es

realizada por medio de primitivas especiales No es posible acceder directamente a las

estructuras de datos de los OI El proceso cliente es responsable de colocar

y modificar los parámetros que determinen la apariencia y el comportamiento

Creación OI: Ejemplo (Athena Toolkit)

void Activate () {printf (“button was activated. \n”); }

void main (unsigned int argc, char **argv) {static XtCallbackRec callbacks[]= {

{Activate, NULL} };

static Arg args[] = {{XtNcallback, (XtArgVal)callbacks },{XtNlabel, (XtArgVal)”Hello World”},};

toplevel=XtInitialize(NULL,“Demo”,NULL,0,&argc,argv);

XtCreateManagedWidget(“command”, commandWidgetClass, toplevel, args, XtNumber(args));

XtRealizeWidget (toplevel);

XtMainLoop();}

Parámetros del widget

Callback

Creacióndel widget

Relación Sistemas de ventanas - OI

Proceso Cliente

Sistema de Ventanas

Presentación(modelo de output)

Eventos físicos(modelo de input)

Proceso Cliente

Sistema de Ventanas

Presentación(modelo deoutput)

Eventos físicos(modelo deinput)

Invocación de funciones(callbacks)

Coloc. Parámetros(colores, acciones, callbacks)

OI Estado

Especificación Look & Feel

Feedback léxico

Estados de un OI Con respecto a sus recursos físicos:

“Adquirido” (‘acquired’): recursos interactivos están asignados

“Liberado”(‘released’): sin asignar sus recursos interactivos ej. en su estado inactivo, un menú popup posee sus items

liberados. Al activarse el menú, se asigna un espacio de pantalla

(recurso) a los items del menú (los OI son adquiridos). Al seleccionarse un item del menú, los items desaparecen

(liberados) La adquisición y liberación dinámica permite compartir

recursos entre distintos OIs ej. permite el ahorro de espacio en pantalla

Si existen muchos OIs, la aplicación sólo puede adquirir algunos de ellos simultáneamente

Es posible compartir un mismo recurso por varios OI No en forma simultánea

Estados de un OI Con respecto a la aceptación de

eventos: “Habilitado”: acepta eventos del operador “Deshabilitado”: no acepta eventos del operador Los OI deshabilitados suelen ser presentados en

forma diferente ej. Items de un menú con menor contraste

No es conveniente liberar un OI deshabilitado La muestra de un OI deshabilitado indica al usuario

su localización usual, pero que actualmente no acepta eventos

Estados de un OI De acuerdo a si el operador está interactuando

con el OI “Activo”: en el momento en el que el operador está

interactuando con dicho OI Debe proveerse un feedback visual para indicar al

usuario que la aplicación está respondiendo a sus acciones

ej. cuando se presiona un botón, debe existir alguna indicación visual de que dicha presión tiene efecto.

Siempre debiera poder deducirse el estado actual del OI a partir de su representación visual actual

OI: tratamiento de eventos La forma del manejo de eventos

depende del toolkit particular. Métodos básicos:

‘Polling’ (Macintosh) El proceso cliente verifica los eventos disponibles,

y cuales de ellos son de interés para cada objeto de interacción

Callbacks (Xt) Rutinas asociadas con cada posible evento sobre

el OI

OI: Tratamiento de eventos Macintoshwhile (go) {

if (GetNextEvent(everyEvent, &myEvent))switch (myEvent.what) { case keyDown: .....; break; case mouseDown: wheremouse = FindWindow(myevent.where),

&whichwindow);switch (wheremouse) { case inDesk: .....; break; case inMenuBar: .....; break; case inContent: localwhere = myevent.where; GlobalToLocal(&localwhere); whereincontrol = FindControl(localwhere,

&whichwindow, &whichcontrol); if (whichcontrol != NIL) {

switch (whereincontrol) { case inButton: // lexical feedback of button} // end whereincontrol

} // end if (whichcontrol != NIL)} // end wheremouse

} // end myEvent.what} // end while(go)

OI: Tratamiento de eventos Definición de eventos de mayor nivel

X Toolkit: “acciones” definidas en términos de expresiones regulares

Expresiones basadas en eventos primitivos (mouse button up o down, key pressed, etc.)

El cliente define sus acciones de alto nivel en una ‘translation table’

El OI interpreta esta tabla para determinar que acción generar y cuál procedimiento invocar

OI: Definicion de nuevos eventos (Xt)

XtTranslations mytranstable; static void beep(Widget w,Xevent *event,String *params, int numparams){

Xbell(XtDisplay(w), 50);}static void quit (Widget w,Xevent *event, string *params, int numparams) {

exit (0);}static XtActionsrec myactionstable[] = {

{“beep”, beep}, {“quit”,quit}, }; static char mytranslations[] =

“<Key> Return: beep() \n\Ctrl<Key>J: beep() \n\Ctrl<Key>Q: quit()”;

XtAddActions(myactionstable, XtNumber(myactionstable));

mytranstable = XtParseTranslationTable(mytranslations);

w = XtCreateManagedWidget (...);

XtOverrideTranslations (w, mytranstable);

Asociación acción-procedimiento

Procedimientos

Tabla de traducción

Registro nueva acción

Compilación de la tabla

Instalación tabla en un widget

Composición de OI OI “compuesto”: OI que puede contener

otros OI “componentes” Conforman una jerarquía de OI La localización de un OI componente es

relativa a la posición del OI compuesto OI “contenedores” : OI compuestos sin

interacciones propias. Son los más simples de los OI compuestos

ej. Cajas de diálogo Pueden ser componentes de otros OI

contenedores

Administración de la geometría Administración de la geometría

Algunos toolkits proveen una administración automática de la geometría de los OI compuestos

ej. Xt Intrinsics, Andrew Idea básica: el OI contenedor es responsable por el

tamaño y posicionamiento de sus OI componentes Pueden existir negociaciones entre el OI contenedor

y sus componentes para administrar el espacio ej. un OI componente indica el tamaño mínimo

requerido En otros casos, pueden indicarse “restricciones”

entre los distintos OI componentes Algoritmos de ‘layout’

‘Fixed-Position Layout’ Cada OI componente es colocado en una posición

fija dentro del OI compuesto ej. cajas de diálogo Esta posición es expresada en términos de las

coordenadas del OI compuesto Los OI siempre permanecen en la misma localización

Modelo muy simple Utilizado por la mayoría de los toolkits

Pueden existir inconvenientes en el redimensionamiento de las ventanas

ej. Localización de un barra de desplazamiento, al modificar el tamaño de la ventana que la contiene

Para evitar esta situación, los sistemas asignan una posición fija al OI. Luego, permiten al sistema modificar esta posición ante un redimensionamiento

envían un mensaje al OI contenedor ante un redimensionamiento

Especificación con restricciones Las relaciones geométricas entre los OI

componentes son expresadas por medio de fórmulas (“restricciones”) ej. e.right = f. Left El redimensionamiento es administrado

automáticamente La especificación por medio de ecuaciones

no es muy sencilla

‘Struts & Springs Layout’ Simplificación del algoritmo de

restricciones Provee dos tipos de objetos para colocar

en los layouts “soportes” (‘struts’): objetos rígidos “muelles” (‘springs’): objetos comprimibles. Estos objetos pueden ser colocados para

expresar relaciones geométricas entre los OI componentes.

Puede ser especificado visualmente

‘Intrinsic Size Layout’ El tamaño intrínseco de cada OI es usado

como base para la asignación de espacio. Cada OI componente determina sus

necesidades de espacio, y se las informa a su OI contenedor

ej. items en un menú El OI compuesto calcula el espacio necesario

para contener a todos sus OI componentes Si existen más niveles de anidamiento, se

propagan las necesidades de espacio Algoritmo ‘bottom-up’ No trata los problemas de redimensionamiento

‘Variable Intrinsic Size Layout’ El tamaño es determinado por el operador, y los OI

deben adecuarse a dicho tamaño Consta de dos fases:

1. Fase ‘bottom-up’ Cada OI reporta sus necesidades de espacio, a partir de las

necesidades de sus OI componentes Los OI también pueden indicar las posibilidades de relajación

en dicho espacio ej. Cuanto más chico y/o más grande puede ser dicho espacio

2. Fase ‘top-down’ El espacio disponible es particionado entre los OI

componentes, de acuerdo a sus necesidades. Utilizado en TEX e Interviews. Se proveen objetos ‘glue’ para colocar entre OI

componentes Una variante de este algoritmo es utilizado en el AWT de

Java.

OI: ‘Resources’ Los OI proveen parámetros para especificar

algunos aspectos de apariencia y comportamiento

‘Resource files’: colección de parámetros Pueden ser editados por el operador En tiempo de ejecución, son procesados por el toolkit

para crear los OIs No necesitan ser compilados conjuntamente con el

código de la aplicación X Windows: archivos textuales

OI compuestos: UIL Macintosh:

editable con ResEdit (Macintosh Toolbox)

Resources Xt ## Draw: Class resource file the simple draw program

Draw*commands.columns: 1Draw*quit.label: QuitDraw*drawline.label: Draw LineDraw*drawrect.label: Draw RectangleDraw*movelineright.label: Draw Line RightDraw*movelineleft.label: Draw Line LeftDraw*canvas.xRefName: commandsDraw*canvas.xAddWidth: TrueDraw*canvas.xAttachRight: TrueDraw*canvas.xAttachLeft: TrueDraw*canvas.xAttachBottom: TrueDraw*canvas.xAttachTop: TrueDraw*canvas.xAttachRight: True

Vinculación aplicación / recursos Macintosh:

El código y los recursos son mantenidos en forma conjunta

Cada archivo contiene: ‘Data fork’: contiene datos, en una forma similar a un

archivo convencional ‘Resource fork’: contiene los recursos, identificados con

un nombre y un tipo. El SO provee rutinas para acceder a los recursos por su

nombre y/o tipo. Cada recurso es una secuencia simple de bytes

Mecanismo general y extensible Conteniendo los datos y recursos en un mismo archivo

evita la pérdida de los recursos de una aplicación

Vinculación aplicación / recursos X Windows:

No existe una vinculación estricta entre el programa y sus recursos.

Los recursos se encuentran en un directorio definido por la aplicación

MS Windows: Un compilador de recursos agrupa los

recursos, incorporándolos como un segmento de datos a un módulo ejecutable.

No se producen pérdidas de los recursos.

Herramientas para especificación de recursos Compiladores de recursos

Convierten una especificación textual en el formato del recurso

Generalmente provistas por los toolkits Los lenguajes de recursos son bastante sencillos y

primitivos

Herramientas de diseño de interfaces Programas interactivos que permiten diseñar

visualmente las interfaces Estas herramientas pueden:

Editar directamente los recursos Crear código fuente en formato textual, utilizado

posteriormente por el compilador de recursos.

Comunicación entre OIs ‘Pseudoevents’

Eventos creados para la comunicación entre objetos

No se corresponden con los eventos de input reales

Modelos básicos de comunicación: Callbacks (Motif, Xtk) Notificación al padre Modelo de conecciones

Comunicación entre OIs Callbacks

El código de los callbacks puede contener comunicaciones con otros OIs.

Las distintas interrelaciones entre los OIs no son fáciles de comprender

Notificación al padre Cada OI puede comunicarse con otro OI por medio

de su OI contenedorLos OI están restringidos a comunicarse con sus

padres Puede producir el envío de muchos mensajes

ej. si los OI están distantes, no relacionados por un único OI contenedor

Comunicación entre OIs Modelo de conecciones

Los objetos pueden comunicarse directamente entre sí. ej. una barra de desplazamiento puede invocar

directamente algún método sobre el editor de texto. El método exacto a usar en la comunicación puede no

ser conocido en el momento de programación Las interrelaciones entre los OIs deben ser provistas en

la inicialización ej. NeXTSTEP : usa 2 campos para establecer la

comunicación: Destino (widget que será notificado) Acción (identificación del método a invocarse). Estos valores son colocados en tiempo de ejecución

Los widgets no están restringidos a comunicarse con sus padres.

‘Toolkits’ Bibliotecas de OIs, disponibles para los

programadores Reusabilidad de comportamientos estandar Consistencia entre aplicaciones

desarrolladas con el mismo toolkitGeneralmente, proveen una cantidad

limitada de estilos de interacción• ej. cómo crear una barra de desplazamiento con

dos elevadores?Implementación costosa Pueden ser difíciles de usar

ej. cuál rutina utilizar en Macintosh Toolbox?

‘Toolkits’ Alternativas de implementación:

Utilizando los servicios provistos por el sistema de ventanas

Sus servicios son utilizados por el sistema de ventanas Macintosh:

El toolkit está implementado a bajo nivel La interfaz del sistema de ventanas (‘window manager’)

está construida con el toolkit. El ‘window manager’ puede utilizar las las rutinas

sofisticadas del toolkit para implementar su interfaz X Windows:

El toolkit se encuentra implementado por encima del WS Los ‘window manager’ deben implementar su propia

interfaz Pueden utilizarse varios toolkits (ej. Xt, Interviews,

Garnet, Tk)

X Windows

Programas de Aplicación

Toolkit

Window Manager

Window System

Paquete Gráfico

Macintosh / MS Windows

Programas de Aplicación

Toolkit

Window Manager

Window System

Paquete Gráfico

Intrinsics Nivel de software que permite la construcción

de diferentes toolkits Provee servicios básicos para los toolkits

ej. técnicas OO, control de layout Los widgets son implementados con estos servicios

como base Provee independencia del look&feel de la interfaz

Los widgets desarrollados sobre este nivel pueden tener cualquier apariencia y comportamiento

Cada toolkit particular determina un estilo de look&feel Inversamente, el look&feel de un determinado toolkit

podría ser implementado sobre distintos Intrinsics

Xt Intrinsics

Motif AthenaOpenLook

Xt Intrinsics InterviewsGarnet

Motif Motif Motif

X Toolkit (Xt) Intrinsics Provee un conjunto de clases básicas para

implementar toolkits (X-Windows) Establece un paradigma orientado a objetos No especifica ningún look&feel particular

Hardware

X Windows

Sistema Operativo

Xlib

OSF Motif

Aplicación

Xt Intrinsics

X Toolkit (Xt) IntrinsicsObject

RectObj

Core

Constraint

OverrideShell

TransientShell

ApplicationShell

TopLevelShell

Shell

WMShell

VendorShell

Composite

Widgets con interfaz con el adm. de ventanas

Widgets compuestos

OO, administración deespacio, bordes, ...

Widgets básicos

OSF / MotifObject

RectObj

Core

Constraint

OverrideShell

TransientShell

ApplicationShell

TopLevelShell

Shell

WMShell

VendorShell

Composite

XmMenuShell

XmDialogShell

XmDisplay

XmDrawingAreaXmFrameXmPanedWindowXmRowColumnXmScaleXmScrolledWindow XmMainWindowXmBulletinBoard

XmForm XmMessageBox XmSelectionBox

XmArrowButtonXmListXmScrollBarXmSeparatorXmTextXmLabel XmCascadeButton XmDrawnButton XmPushButton XmToggleButton

XmManager

XmPrimitive

XmManager

OPEN LOOK Intrinsics ToolkitObject

RectObj

Core

Constraint

OverrideShell

TransientShell

ApplicationShell

TopLevelShell

Shell

WMShell

VendorShell

Composite

MenuShell

NoticeShell

PopupWindowShell

Manager

CheckBox

ScrolledWindowRubberTileNonexclusivesFormFooterPanelExclusivesControlArea

Caption

TextFieldBulletinBoard

Primitive

OblongButton

Pixmap

MenuButtonAbbrevMenuButtonButtonGaugeScrollBarFlatSliderStaticTextTextEdit

RectButton

BaseWindowShell

Toolkits Procedurales Interfaz procedural Colección de procedimientos

ej. SunTools (SunView), Macintosh Toolbox Más sencillos de implementar que los

toolkits OO Es más sencillo proveer una interfaz con

múltiples lenguajes

Toolkits OO Forma más natural de pensar en OIs Los widgets pueden mantener un estado propio

Algunas tareas pueden ser realizadas automáticamente por el toolkit (ej. ‘refresh’)

Es posible crear nuevos tipos de OI Subclases

Alternativas de implementación Implementación de un sistema de objetos propio

ej. Xt, Andrew, Garnet Utilización de sistema de objetos existente

ej. Interviews (C++), NeXTStep (Objective C), Rendezvous (CLOS)

Interfaz general con la aplicación: callbacks Código dificil de mantener (alta cantidad de callbacks) Dificultades con la portabilidad (los toolkits pueden tener

diferentes protocolos de callbacks)

Toolkits Especializados Desarrollados para tipos específicos de

aplicaciones Educación: SUIT UI manipulación directa: Garnet Múltiples usuarios: RendezVous 3D: UGA, Inventor UI temporales: Ttoolkit Animación: Artkit Lenguajes interpretados: Tk Restricciones: Garnet, RendezVous, Amulet

Toolkits Virtuales OI “virtuales”: OI especificados

independientemente de la plataforma Intentan ocultar las diferencias entre los distintos

toolkits Los OI virtuales se corresponden con los OI reales de

cada toolkit También denominados “sistemas de desarrollo

‘cross-platform’” Portabilidad

Alternativas de implementación: Vínculos con los toolkits reales Reimplementación de los widgets en cada estilo

Toolkits Virtuales Vinculación con los toolkits reales

ej. XVT Provee una interfaz C++, vinculada a los toolkits reales Motif,

OpenLook, Macintosh, MSWindows, OS/2 Utiliza los widgets reales

El look&feel se comporta exactamente igual al toolkit real En general, se proveen solamente aquellas funciones que

están presentes en todos los toolkits Reimplementación de los widgets

ej. Galaxy, OpenInterface Proveen bibliotecas de OIs que se comportan de acuerdo a

cada plataforma En tiempo de ejecución, debe existir una biblioteca

grande Además de los widgets nativos de la plataforma, debe

incluirse la reimplementación de estos widgets en el toolkit virtual