Construccin de Interfaces a Usuario: Toolkits - PowerPoint PPT Presentation

1 / 46
About This Presentation
Title:

Construccin de Interfaces a Usuario: Toolkits

Description:

widgets' (X-Windows), 'controles' (Macintosh, MS Windows), 'objetos' (NeXTStep) ... editable con ResEdit (Macintosh Toolbox) Resources Xt ... – PowerPoint PPT presentation

Number of Views:75
Avg rating:3.0/5.0
Slides: 47
Provided by: gov87
Category:

less

Transcript and Presenter's Notes

Title: 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)
Write a Comment
User Comments (0)
About PowerShow.com