Windowing Systems and User Interface Management Systems

Implementation Support

Chapter 8 discusses implementation support for graphical user interfaces.

Windowing System

A windowing system is a system designed to share a computer's graphical display resources and GUI among multiple applications simultaneously. Key roles include:

  • Device/Hardware Independence: Abstracts the hardware to allow applications to run on various devices.

  • Management of Independent Applications: Handles multiple active applications simultaneously.

Elements of windowing systems are important to consider.

Elements of Windowing Systems

It's crucial to program an application capable of running on a broad spectrum of devices. To achieve this, programmers direct commands to an abstract terminal. The abstract terminal understands a generic language that can be translated into the specific language of many hardware devices. This allows portability of the application program.

  • Only one device driver needs to be written for a particular hardware device, enabling any application program to access it.

  • A fixed generic language, known as its imaging model, is used for the abstract terminal.

Windowing System Architecture

The architecture follows a client-server model.

  • Clients: Applications requesting display services.

  • Server: Manages the display, abstract terminal, resources, and device drivers.

  • Abstract Terminal: Translates generic commands to device-specific commands.

  • Resource Manager: Manages system resources.

  • Device Driver: Manages specific hardware devices like mouse and keyboard.

Client-Server Architecture

The architecture consists of clients (applications) communicating with a server which manages the abstract terminal, resources, and device drivers.

Programming the Application

Interactive applications are generally user-driven, with actions determined by user input. Two primary programming paradigms can be used:

  • Read-evaluation loop

  • Notification-based

The windowing system does not enforce either paradigm.

Read-Evaluation Loop

The application continuously reads events and processes them based on their type:

repeat
 read-event(myevent)
 case myevent.type
 type_1: do type_1 processing
 type_2: do type_2 processing
 ...
 type_n: do type_n processing
 end case
end repeat

Notification-Based

The application sets up actions to be performed when specific events occur:

void main(String[] args) {
 Menu menu = new Menu();
 menu.setOption(“Save”);
 menu.setOption(“Quit”);
 menu.setAction(“Save”,mySave)
 menu.setAction(“Quit”,myQuit)
 ...
}

int mySave(Event e) {
 // save the current file
}

int myQuit(Event e) {
 // close down
}

Toolkits

A toolkit provides programmers with pre-built interaction objects, sometimes called interaction techniques or gadgets. These objects have predefined behaviors.

  • Example: A button with a defined behavior.

  • The Java toolkit for developing windowed applications is called the Abstract Windowing Toolkit (AWT).

Toolkit advantages

Toolkits offer consistency and generalizability for interactive systems.

  • They enforce consistency in input and output by providing similar behavior across widgets.

  • This consistency is referred to as the "look and feel" of the toolkit.

Modifying Interaction Objects

Interaction objects can be modified through:

  • Instantiation

  • Inheritance

  • Multiple inheritance

  • Instance attributes

User Interface Management Systems (UIMS)

UIMS provides enhanced development support for interactive system design beyond toolkits. Examples include Serpent & Picasso. A UIMS should support:

  • Conceptual Architecture: Separation between application semantics/logic and presentation.

  • Techniques: Implementing separated application and presentation while preserving the connection between them.

  • Support Techniques: Managing, implementing, and evaluating a run-time interactive environment.

UIMS Conceptual Architecture

Separation between application semantics/logic and presentation improves:

  • Portability: Runs on different systems and provides a device-independent interface.

  • Reusability: Reusing components reduces development costs.

  • Multiple Interfaces: Supports developing multiple interfaces to access the same functionality.

  • Customizability: Allows designers and users to customize without altering the core application.

Seeheim Model

The Seeheim Model divides the architecture into Presentation, Dialogue Control, and Functionality (application interface), with USER and APPLICATION components. It uses switch lexical, syntactic, and semantic.

MVC: Model-View-Controller

MVC is an architectural pattern dividing the application into three interconnected parts:

  • Model: Manages data and logic.

  • View: Displays data to the user.

  • Controller: Handles user input and updates the model and view.

PAC: Presentation-Abstraction-Control model of Coutaz

The Presentation-Abstraction-Control (PAC) model is a multi-agent architecture.

MVC & PAC Differences/Issues

  • PAC:

    • Groups input and output together.

    • Provides an explicit component to maintain consistency between abstraction and presentation.

    • Not linked to any specific programming environment; more of a conceptual architecture.

  • MVC:

    • Separates input and output.

    • Does not assign the task of maintaining consistency to a specific component.

    • Cannot easily isolate the control component.

Implementation Considerations: Dialog Modeling Techniques in UIMS

  • Menu Networks

  • Grammar notations

  • State transition diagrams

  • Event Languages

  • Declarative languages

  • Constraints

  • Graphical specification