Construcción de Interfaces a Usuario: Toolkits

Presentación del tema: "Construcción de Interfaces a Usuario: Toolkits"— Transcripción de la presentación:

1 Construcción de Interfaces a Usuario: Toolkits

2 Niveles de Abstracción de un SI
Núcleo Funcional Control del Diálogo Incremento en el nivel de abstracción Objetos de Interacción Sistema de Ventanas Drivers 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
Print Mouse Enter Highlighted unset Print Mouse Pressed Highlighted set Print Unhighlighted unset Print Mouse Released Highlighted unset Print Mouse Leaves Unhighlighted unset 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”},}; toplevel=XtInitialize(NULL,“Demo”,NULL,0,&argc,argv); 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) OI Feedback léxico 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) } // end wheremouse } // end myEvent.what } // end while(go)

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[] = “<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); 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
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
Draw*commands.columns: 1 Draw*quit.label: Quit Draw*drawline.label: Draw Line Draw*drawrect.label: Draw Rectangle Draw*movelineright.label: Draw Line Right Draw*movelineleft.label: Draw Line Left Draw*canvas.xRefName: commands Draw*canvas.xAddWidth: True Draw*canvas.xAttachRight: True Draw*canvas.xAttachLeft: True Draw*canvas.xAttachBottom: True Draw*canvas.xAttachTop: 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: Macintosh: X Windows:
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 Programas de Aplicación Window Manager Toolkit Window System
Paquete Gráfico

35 Macintosh / MS Windows Programas de Aplicación Window System Window
Manager Paquete Gráfico Toolkit

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 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 Athena OpenLook Xt Intrinsics Interviews Garnet Motif

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 look&feel particular Hardware X Windows Sistema Operativo Xlib OSF Motif Aplicación Xt Intrinsics

38 X Toolkit (Xt) Intrinsics
OO, administración de espacio, bordes, ... Object RectObj Core Constraint OverrideShell TransientShell ApplicationShell TopLevelShell Shell WMShell VendorShell Composite Widgets básicos Widgets compuestos Widgets con interfaz con el adm. de ventanas

39 OSF / Motif Object RectObj Core Constraint OverrideShell
TransientShell ApplicationShell TopLevelShell Shell WMShell VendorShell Composite XmPrimitive XmArrowButton XmList XmScrollBar XmSeparator XmText XmLabel XmCascadeButton XmDrawnButton XmPushButton XmToggleButton XmManager XmManager XmMenuShell XmDrawingArea XmFrame XmPanedWindow XmRowColumn XmScale XmScrolledWindow XmMainWindow XmBulletinBoard XmDialogShell XmDisplay XmForm XmMessageBox XmSelectionBox

40 OPEN LOOK Intrinsics Toolkit
Object RectObj Core Constraint OverrideShell TransientShell ApplicationShell TopLevelShell Shell WMShell VendorShell Composite Primitive AbbrevMenuButton Button MenuButton 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 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

46