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 table summarizes the building blocks (GUI elements) that are provided by Intuition and its various extensions:

GUI element types	Description	System component or toolkit providing this functionality
screens	Virtual desktops on which windows are opened.	Intuition Library
windows	Rectangular areas containing an interface through which a program communicates with the user, and vice versa.	Intuition Library
menus	Programmable sets of commands displayed as a pull-down list of options.	Intuition Library, GadTools Library
gadgets	Various-purpose GUI controls (buttons, toolbars, gauges, text fields...) with a standardized look and behaviour. Often called “widgets” in other operating systems.	Intuition Library, GadTools Library, ReAction, MUI
images	Non-selectable elements showing graphics or text.	Intuition Library, ReAction, MUI
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.	Intuition Library, ASL Library, ReAction, MUI
alerts	A method of emergency communication (such as system errors).	Exec Library, Intuition Library
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.	Application Library
IntuiText	Formatted text to be placed at a specific position inside an Intuition element (screen, window, menu, gadget or requester).	Intuition Library
borders	Graphical structures made of lines that connect a series of defined points..	Intuition Library

The Two Frameworks

GUI programming in AmigaOS does not have to done within a single framework or API. This fact can be confusing to newcomers. There are two frameworks in Intuition representing fundamentally different approaches to GUI programming:

1. The data structure-oriented framework is the original Intuition API. Within this framework, if you want to create a GUI element, you have to provide dedicated data structures 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 (called BOOPSI: Basic Object-Oriented Programming System for Intuition) is the extendable API. Within this framework, if you want to create a GUI element, you have to instantiate an object based upon a particular class. Objects are manipulated through a small set of methods which are really just functions.

Modern AmigaOS programmers generally do not directly use either of these frameworks. Although it is still possible to do so it also requires a lot more code to achieve even a simple GUI.

Instead, programmers are encouraged to use one or more of the various toolkits provided.

GUI toolkits

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

GadTools

GadTools is a datastructure-based toolkit. It is implemented as a single library and is not easily extensible. What is most useful about GadTools is the Intuition menu building functionality. Most of the other toolkits still use the menu build aspect of Gadtools.

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.

ASL

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

The Amiga Standard Library (ASL) is a toolkit designed to ease the programming of common requesters. There are currently three types of requester available: file requester, font requester and screenmode requester.

ReAction

ReAction is an object-oriented toolkit based on BOOPSI which is highly extensible.

ReAction is a more modern toolkit which hides much of the complexity. It covers all the functionality of GadTools and ASL and uses and extends the original BOOPSI class set built into Intuition Library. ReAction is considered to be the standard Amiga GUI toolkit.

MUI

MUI is an object-oriented toolkit based on BOOPSI which is highly extensible.

The Magic User Interface (MUI) is a comprehensive third-party toolkit for application GUI design which can also incorporate GadTools menus and ASL.

Qt, REBOL/View and Others

Third party toolkits may also be used on AmigaOS just as well as the built-in toolkits listed above.

Such toolkits generally work by opening an Intuition Screen and then rendering directly into that screen to create the GUI environment. Toolkits may also incorporate Intuition Windows and use them as a basic element. Native Intuition Menus may or may not be used as well.

With the use of skinning, 3rd party GUIs can look and feel a lot like Amiga native GUIs. However, they can suffer from reduced speed due to the more intensive use of the CPU. Much of the speed problem can be alleviated through the use of hardware acceleration (e.g. compositing).

Choosing Toolkits

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

• Note that GadTools provides no automatic layout system. Gadgets are not scalable and are at fixed positions and dimensions. GadTools is not recommended with the exception of the menu layout system.

• The original BOOPSI set built in Intuition is usable but somewhat limited. Some BOOPSI objects are actually wrappers for ReAction objects.

• Prefer not to mix datastructure-oriented and object-oriented GUI programming. GadTools gadgets are incompatible with all others. The ASL toolkit is utilized by ReAction and MUI.

• 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.