Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

46
Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits

Transcript of Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Page 1: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

Construcción de Interfaces a Usuario: Toolkits

Page 2: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

Contenidos

Objetos de Interacción (OI)– Relación con el sistema de ventanas

– Tratamiento de eventos

– Composición de OI

– Recursos

– Comunicación entre OIs

Toolkits– Intrinsics

– Procedurales / OO

– Especializados

– Virtuales

Page 3: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 4: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 5: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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ú

Page 6: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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.

Page 7: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 8: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 9: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 10: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 11: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 12: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 13: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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 la representación visual actual

Page 14: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 15: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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)

Page 16: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 17: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 18: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 19: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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’

Page 20: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

‘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

Page 21: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 22: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

‘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

Page 23: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

‘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

Page 24: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 25: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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)

Page 26: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 27: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 28: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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.

Page 29: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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.

Page 30: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 31: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

contenedor Los 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

Page 32: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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.

Page 33: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

‘Toolkits’

Bibliotecas de OIs, disponibles para los programadores Reusabilidad de comportamientos estandar Consistencia entre aplicaciones desarrolladas con el mismo toolkit Generalmente, 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?

Page 34: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

‘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)

Page 35: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

X Windows

Programas de Aplicación

Toolkit

Window Manager

Window System

Paquete Gráfico

Page 36: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

Macintosh / MS Windows

Programas de Aplicación

Toolkit

Window Manager

Window System

Paquete Gráfico

Page 37: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 38: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 39: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

X Toolkit (Xt) Intrinsics

Object

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

Page 40: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

OSF / Motif

Object

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

Page 41: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 42: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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)

Page 43: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 44: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 45: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999

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

Page 46: Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Toolkits.

Construcción de Interfaces a Usuario - ©1999