In most windowing toolkits, there usually exists a master controller of some form or another. The UI toolkit assumes the responsibility of handling all user input. While this method provides a very straight-forward approach to application design, it does not fit well with most visualization-centric applications.

GLAM's event model utilizes a more free-form approach. It is up to the application to generate and send user events to the event distributor, which then sends them to the proper widget. The widget is then responsible for handling the event in an appropriate fashion. This approach allows for a much more flexible integration paradigm than the traditional "the application revolves around the UI toolkit". Rather, with GLAM "the UI toolkit revolves around the application".

There are several important user event classes that the developer should be aware of, namely:

The Actions and Listener interface provides a means for inter-widget communication. The event distribution architecture handles only external input events (directly from the user), so a robust internal action architecture was created. Widgets can implement certain types of listening interfaces. Using those interfaces, they can register with other widgets to recieve actions. This allows widgets to 'talk' to each other.

Another purpose for this architecture is highlighted through an understanding of the difference between, for example, a mouse button click (a user event) and a "button press." A button press is generally not as simple as a mouse click. A user may, for instance, click on a button, continue holding the mouse button, leave the button and return before releasing the mouse button again. This action is considered a "button press." Understanding who is responsible for handling this kind of behavior is where actions and listeners play their role.

As can be seen from our previous example, it is the button widget that actually determines its own function, not a mouse click. The same is true for all other widgets in GLAM. With this in mind, the architecture for widget "action" handling was devised.

In GLAM, user events are generated and assigned to certain widgets by the developer. The widget is then responsible for how it will handle the user event. In this manner, the function of a widget will determine what a widget is. For instance, the function of a button is the abstract "button press" action, as previously described. A button widget and how the user will interact with it is determined by its function. By virtue of this important design, the form of a widget follows its function.

As user events are translated by widgets into the appropriate behavior, a more abstract communication layer is developed. The actions that widgets perform in response to a user event can be "listened" to by other widgets or classes. This is accomplished through the implementation of various listener interfaces. For each type of abstract widget action, a widget listener interface is available. In keeping with the previous button examples, button actions can be listened to by implementing a button listener.

The developer is expected to extend the core set of action and listener classes provided in GLAM when necessary to accomplish the specific goals of his application. Below are the base action and listener classes, as well as some core action & listener classes and some widgets that support them.