GUI Programming

Background

In AmigaOS, the face a program shows you – its graphical user interface (GUI) – is created through a subsystem called Intuition. Older literature sometimes used to refer to Intuition as “the Amiga user interface” but this is really not the case. Despite being responsible for much of what you can see in the OS (including its windowing desktop environment, the Workbench), Intuition itself remains invisible to the user. It is merely a system component providing ready-made elements to build GUIs from, and a set of functions through which these elements are manipulated. Intuition also interconnects GUIs with the operating system and handles various communications that underlie application usage and control.

Intuition’s functionality is further extended by a number of auxiliary system components, or toolkits. Like most AmigaOS subsystems, Intuition and its extensions are implemented as libraries of functions that can be accessed from a higher-level programming language like C, C++, Modula-2 or AmigaE.

GUI elements

Amiga programs do not look or behave very differently from, say, Mac or Windows applications because their user interface is based on shared metaphors and familiar elements. There may be differences in naming conventions or programming techniques but the building blocks are similar. The following building blocks (GUI elements) are provided by Intuition and its various extensions:

screens

Virtual desktops on which windows are opened.

windows

Rectangular areas containing an interface through which a program communicates with the user, and vice versa.

gadgets

Various-purpose GUI controls (buttons, toolbars, gauges, text fields...) with a standardized look and behaviour. Often called “widgets” in other operating systems.

images

Non-selectable elements showing graphics or text.

menus

Programmable sets of commands displayed as a pull-down list of options.

requesters

Means for displaying information and for requesting input from the user. They would be called “dialogs”, “dialog boxes” or “dialog windows” in other OSes.

alerts

A method of emergency communication (such as system errors).

pop-up notifications

Automatic messages informing the user when things happen. Unlike requesters, notifications are “unobtrusive” and do not require any input from the user. They are provided by the Application Library, outside of the Intuition environment.

IntuiText

Formatted text to be placed at a specific position inside an Intuition element (screen, window, menu, gadget or requester). Now rarely used.

borders

Graphical structures made of lines that connect a series of defined points. Now rarely used.

The two frameworks

For historical reasons, GUI programming in AmigaOS is not done within a single framework, or API. This fact can be a little confusing and deserves explanation. Strictly speaking, there are two frameworks (APIs) in Intuition, representing two fundamentally different approaches to GUI programming:

1. The datastructure-oriented framework is the original API. Within this framework, if you want to create a GUI element, you have to provide (fill in) a dedicated datastructure for it; if you want to manipulate the element, you have to use a function designed for the particular action and type of element.

1. The object-oriented framework (traditionally called BOOPSI: Basic Object-Oriented Programming System for Intuition) is the more modern API. Within this framework, if you want to create a GUI element, you have to model an object upon a particular element type (called class); all objects are manipulated through a small set of generic functions (called methods).

As a programmer, you are free to choose which of the two frameworks you’ll use to design your application’s user interface. However, the object-oriented framework (BOOPSI) is preferred for GUI programming in AmigaOS 4.x. You’ll likely find it easier to use, and much more powerful than the original API.

GUI toolkits

The Intuition library itself does not provide all the necessary tools for user interface programming. Much of the GUI-related functionality is provided through various extensions, or toolkits. The following toolkits are installed by default in AmigaOS:

GadTools

The original Intuition only provided a fixed set of GUI elements limited in functionality and with practically no standardized look. To remedy this, GadTools was introduced in AmigaOS 2.x as a ready-made toolkit for easier, faster and more consistent GUI design. GadTools extended the original Intuition set with fancy new controls such as the cycle gadget, the radiobutton, or the listview. The gadgets shared similar imagery, thus giving Amiga GUIs a more uniform, standardized look. Apart from improving the gadget set, GadTools also greatly simplified the creation of menus.

GadTools is a datastructure-based toolkit. It is implemented as a single library, and is not extensible.

ASL

ASL, for Amiga Standard Library, is a toolkit designed to ease the programming of requesters. There are three types of requester created through ASL: the file requester, the font requester, and the screenmode requester.

ASL is a datastructure-based toolkit. It is implemented as a single library, and is not extensible.

ReAction

ReAction is a comprehensive toolkit for application GUI design. It covers all the functionality of GadTools and ASL, and extends the original BOOPSI class set as provided by Intuition. Originally a third-party product, ReAction is now part of AmigaOS and is considered the standard Amiga GUI toolkit.

ReAction is an object-oriented toolkit based on the BOOPSI philosophy. It is implemented as a set of classes. It is extensible: new classes can be written according to the BOOPSI specification.

MUI

MUI, for Magic User Interface, is a comprehensive third-party toolkit for application GUI design.

MUI is an object-oriented toolkit based on the BOOPSI philosophy, with proprietary extensions. It is implemented as a set of classes and support libraries. It is extensible: new classes can be written according to the BOOPSI/MUI specification.

The use of the toolkits

• Choose the toolkit that works best for your application and your end customers.

• Remember that GadTools provides no automatic layouting system. Gadgets are not scalable: they are programmed to specific dimensions and positions. You’ll need to implement your own layouting mechanism to account for different window sizes, user-configured fonts and variant languages. If this sounds like too much work, go the object-oriented way and use either ReAction or MUI.

• Do not mix datastructure-oriented and object-oriented GUI programming (unless there is no other way). GadTools gadgets cannot be placed inside ReAction or MUI layouts. You can use ASL together with the BOOPSI-based toolkits but there is no need, as both ReAction and MUI already cover the functionality of ASL.

• Despite both being based on BOOPSI, MUI and ReAction classes are not interchangeable. You cannot extend the functionality of ReAction with MUI classes, and vice versa.

• If you intend to make your program available for AmigaOS as well as for its clones, MUI is the better choice. Unlike ReAction, an implementation of MUI is available in all Amiga-like systems.