Construccin de Interfaces a Usuario: Toolkits

1
Construcción de Interfaces a Usuario Toolkits
2
Niveles de Abstracción de un SI
Incremento en el nivel de abstracción
Conocimiento
del dominio

Control del secuen- ciamiento de las acciones
del usuario
-
Control de los objetos de interacción
Control de los recursos E/S
Control de los dispositivos físicos
3
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

4
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ú

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

6
Objetos de Interacción Ejemplo

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

7
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

8
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,
• toplevelXtInitialize(NULL,Demo,NULL,0,argc,ar
  gv)
• XtCreateManagedWidget(command,
  commandWidgetClass, toplevel, args,
  XtNumber(args))
• XtRealizeWidget (toplevel)
• XtMainLoop()

Callback
Parámetros del widget
Creación del widget
9
Relación Sistemas de ventanas - OI
Especificación Look Feel
Proceso Cliente
Proceso Cliente
Coloc. Parámetros (colores, acciones, callbacks)
Invocación de funciones(callbacks)
Eventos físicos (modelo de input)
Presentación (modelo de output)
Feedback léxico
OI
Estado
Presentación (modelo de output)
Eventos físicos (modelo de input)
Sistema de Ventanas
Sistema de Ventanas
10
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

11
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

12
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

13
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

14
OI Tratamiento de eventos Macintosh

• while (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)

15
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

16
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
• ltKeygt Return beep() \n\
• CtrlltKeygtJ beep() \n\
• CtrlltKeygtQ quit()
• XtAddActions(myactionstable, XtNumber(myactionstab
  le))
• mytranstable XtParseTranslationTable(mytranslati
  ons)
• w XtCreateManagedWidget (...)
• XtOverrideTranslations (w, mytranstable)

Procedimientos
Asociación acción-procedimiento
Tabla de traducción
Registro nueva acción
Compilación de la tabla
Instalación tabla en un widget
17
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

18
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

19
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

20
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

21
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

22
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

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

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

25
Resources Xt

• Draw Class resource file the simple draw
  program
• Drawcommands.columns 1
• Drawquit.label Quit
• Drawdrawline.label Draw Line
• Drawdrawrect.label Draw Rectangle
• Drawmovelineright.label Draw Line Right
• Drawmovelineleft.label Draw Line Left
• Drawcanvas.xRefName commands
• Drawcanvas.xAddWidth True
• Drawcanvas.xAttachRight True
• Drawcanvas.xAttachLeft True
• Drawcanvas.xAttachBottom True
• Drawcanvas.xAttachTop True
• Drawcanvas.xAttachRight True

26
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

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

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

29
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

30
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

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

32
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?

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

34
X Windows
35
Macintosh / MS Windows
36
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 lookfeel de la interfaz
• Los widgets desarrollados sobre este nivel pueden
  tener cualquier apariencia y comportamiento
• Cada toolkit particular determina un estilo de
  lookfeel
• Inversamente, el lookfeel de un determinado
  toolkit podría ser implementado sobre distintos
  Intrinsics

37
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 lookfeel particular

38
X Toolkit (Xt) Intrinsics
39
OSF / Motif
XmPrimitive
XmArrowButton XmList XmScrollBar XmSeparator XmTex
t XmLabel XmCascadeButton
XmDrawnButton XmPushButton
XmToggleButton
XmManager
XmManager
XmMenuShell
XmDrawingArea XmFrame XmPanedWindow XmRowColumn Xm
Scale XmScrolledWindow
XmMainWindow XmBulletinBoard
XmDialogShell
XmDisplay
XmForm XmMessageBox XmSelectionBox
40
OPEN LOOK Intrinsics Toolkit
Primitive
AbbrevMenuButton
MenuButton
Button
Manager
Gauge
OblongButton
Caption
ScrollBar
RectButton
CheckBox
Flat
ControlArea
Slider
Exclusives
StaticText
FooterPanel
TextEdit
MenuShell
Form
Pixmap
NoticeShell
Nonexclusives
PopupWindowShell
RubberTile
ScrolledWindow
BaseWindowShell
BulletinBoard
TextField
41
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

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

43
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

44
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

45
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 lookfeel 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

46
(No Transcript)