Eventos reconocidos

El propósito de esta sección es enumerar los eventos identificados hasta el momento. En la mayoría de bibliotecas gráficas se reconoce un conjunto de eventos sensiblemente mayor al aquí identificado. Como posteriormente se verá, es relativamente sencillo agregar eventos nuevos en nuestra arquitectura y seguramente esto se hará incrementalmente a medida que surja la necesidad. Al igual que en BiCoTI-I no se pretendió implementar todo algoritmo imaginable (entre otras razones porque hubiera sido en vano), sino dar un framework sobre el cual crecer; en BiCoTI-II el esfuerzo estuvo centrado en buscar una arquitectura con las mismas características.
Si bien son en definitiva los actores las fuentes de eventos concretas, la existencia de un módulo interaction donde se establece la naturaleza de los eventos, se justifica al ser la primer etapa a concretar a la hora de incrementar el grado de interacción. Este es primer módulo donde se deben agregar las clases que extiendan el grado de interacción soportado, sin necesidad aún de concentrarse en la implementación concreta de los mismos.
Los esquemas de interacción en cuestión son:

• Interaction Timer:En este esquema hay dos tipos de entidades involucradas: bicotiInteractionSourceTimer que dispara tics periódicamente y bicotiListenerTimer que es notificado cada vez que se llega a una marca de tiempo en el timer. Como ocurre normalmente en el modelo, cuando un listener está interesado en ser notificado de los eventos que sucedan en el source, debe declararse ante este último con el método AddListenerTimer(). En el momento que el listener no desee escuchar más los eventos debe eliminarse de la lista con RemoveListener. En Fig.4 puede verse la relación explicada.

Figure 4: Interaction Timer

Se considera que un evento TimerTic ha sucedido, en el momento que es invocado el método FireTimerTic().

• Interaction Mouse:Un bicotiInteractionSourceMouse dispara a todos sus listeners un evento de tipo MousePressed() cuando se haya presionado el mouse o MouseReleased() cuando se haya liberado el mismo sobre el objeto. En cualquier caso entre la información que es proporcionada al listener están: el actor que está disparando el evento en cuestión y una instancia de bicotiEventMouse con la información del caso. Esta información incluye: coordenadas (GetX() y GetY()) y botones(IsLeftButton(), IsMiddleButton(), IsRightButton()). El origen de coordenadas es la esquina superior izquierda del source con ejes horizontal a la derecha y vertical hacia abajo respectivamente. El diagrama de clases correspondiente puede verse en Fig.5.

Figure 5: Interaction Mouse

 

• Interaction Mouse Motion:Este tipo de interacción es muy similar a la anterior. De hecho podría haberse incluido en el mismo mecanismo si no fuera por una razón de conveniencia. Los eventos en este caso son disparados, cada vez que el mouse se mueve sobre el source. Estos eventos no se incluyeron en (b) por la pérdida de eficiencia que puede darse en el caso que un listener solo interesado en los presseds y releaseds sea bombardeado con los eventos de mouse motion. Por la misma razón se han incluido (private) los métodos ActivateMouseMotionTracking() y DeactivateMouseMotionTracking(). Ambos métodos son virtuales y están delegados al actor concreto. El primero indica que se dispare un FireMoved() cada vez que el mouse se mueva sobre el actor y es invocado cuando el primer listener se registra con AddListener. El segundo desactiva estos fires y es invocado cuando se hace el RemoveListener del último listener presente.

Figure 6: Interaction Mouse Motion

La anterior Fig.6 esquematiza esta relación.

• Interaction Push Button:Nuevamente tenemos eventos relacionados con el mouse. Ahora se genera un evento clicked cada vez que el botón izquierdo del mouse sea presionado y liberado sobre el actor. Este interacción en particular es programable a partir de (b), sin embargo la explicitación de la misma proporciona un mecanismo de alto nivel para reconocer este evento, típicamente asociado a los botones de una aplicación. En Fig.7 se detallan los métodos involucrados.

Figure 7: Interaction Push Button

 

• Interaction Menu:Todo menú tiene uno o más items para seleccionar. Cuando un bicotiListenerMenu quiere estar al tanto si algún ítem es seleccionado, se registra en este con AddListenerMenu() suministrando el nombre del item en cuestión. La figura Fig.8 esquematiza la relación.

Figure 8: Interaction Menu

Los eventos: (a), (b), (c), (d) y (e) presentan como característica común no involucrar cambios de estado en el actor. A modo de ejemplo, el estado de un botón (posición, tamaño, texto, color, etc.) es independiente de que se produzca un FirePushButtonClicked() en este.
En cambio en (f), (g), (h) e (i), cualquier evento está asociado a un cambio de estado. Antes de entrar en detalles comentaremos la diferencia semántica entre un fire en ambos casos. En el primer grupo, un fire implica automáticamente que todos los listeners son notificados del evento. En el segundo en cambio hay que chequear que realmente se está dando un cambio de estado y cambiarlo efectivamente de ser cierto. Este control se delega a las clases especializadas (los actores), que son los que tienen la información de estado, mediante los métodos check() como se ve en el detalle de cada caso.
 

• Interaction Geometry:Se entiende por evento geométrico, un cambio en la posición o en el tamaño en la fuente de eventos. Cuando se invoca un FireActorMoved() con la nueva posición del source, este último chequea que la posición a cambiado con el método virtual CheckPosition. Si el resultado de este es positivo, se procede a comunicar a todos los listeners disparando en estos el método ActorMoved(), con el parámetro bicotiEventGeometry que contiene la nueva posición del source. También es responsabilidad de CheckPosition() cambiar efectivamente la posición del actor en cuestión.

Un mecanismo completamente análogo se da en un cambio de tamaño como puede verse en Fig.9.

Figure 9: Interaction Geometry

 

• Interaction Field:Un text field es un campo donde puede desplegarse un texto que puede ser editado interactivamente por el usuario. Los eventos interesantes para los listeners en este caso son: un cambio en el texto (FieldTextChanged()) y que se ha presionado el enter estando activa la edición (FieldReturnPressed()). Como el primer evento implica un cambio en el estado, existe un CheckText() asociado como puede apreciarse en Fig.10. Por el contrario no es necesario un método similar para FireReturnPressed().

Figure 10: Interaction Text Field

 

• Interaction Scroll Bar:El scroll bar en muchos de sus formas, es uno de los componentes más comunes en las aplicaciones gráficas. Aunque sus usos pueden ser muy diversos e ir desde desplazamientos de texto hasta selectores de valores; todos los scroll bar comparten una lógica común de interacción. Cada posición del slider está asociada a un valor en un rango de enteros, digamos  [min,max]. Ciertos objetos (los listeners registrados) deben realizar acciones de acuerdo a este valor y por lo tanto deben ser notificados de cualquier cambio en el mismo con el método ScrollBarValueChanged.

Figure 11: Interaction Scroll Bar

Suele existir más de una forma de cambiar la posición (valor) del slider entre las que rescatamos:

• Presionar las flechas en los extremos del mismo, lo que produce un incremento/decremento de cantidad line step.
• Presionar el espacio entre la flecha y el slider, lo que produce un incremento/decremento de cantidad page step.
• Presionar con el mouse el slider y moverlo hasta su nueva posición donde el mouse será liberado.
Con el fin de no tomar acciones frente a cada cambio de valor en el caso anterior, están discriminados los eventos ScrollBarSliderPressed() y ScrollBarSliderReleased(). Por último se registran los cambios en los parámetros del slider: line step, page step y el rango  [min,max]. El resumen de los métodos se ve en Fig.11.
 
• Interaction File Dialog:El file dialog es un widget de alto nivel que sirve típicamente para navegar en el disco duro hasta seleccionar un archivo en forma completamente gráfica. Los eventos destacables en este caso son: FileDialogDirectoryChanged(), FileDialogFileHighlighted() y FileDialogFileSelected() como se representan en Fig.12.

Figure 12: Interaction File Dialog


Aunque los nombres son bastante descriptivos comentaremos brevemente que:
• FileDialogDirectoryChanged es disparado cada vez que el usuario cambia de directorio durante la búsqueda de aquel que contiene el archivo deseado. Como el directorio actual de trabajo es parte del estado del actor, el fire correspondiente tiene asociado un check.
• FileDialogFileHighlighted es disparado cada vez que el usuario clickea con el mouse un archivo en particular dentro del directorio de trabajo.
• FileDialogFileSelected se aplica cuando se a elegido un archivo en particular. Esto último suele estar asociado a alguno de estos casos: se produce un doble-click en un archivo o luego de hacer un highlight se presionó el botón de OK.