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, ReAction, MUI
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 be 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

While the Intuition Library originally provided a datastructure-based set of basic GUI elements (screens, windows, menus, buttons & string gadgets, etc.) they have been supplanted by more modern tools for user interface programming. Most of the GUI-related functionality is now provided through various extensions to Intuition, 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 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 (GadTools uses standard Intuition menus but provides its own build and layout system for them). On the other hand, there is a very limited support for images in GadTools.

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

Magic User Interface is an object-oriented toolkit based on BOOPSI which is highly extensible.

MUI is a comprehensive third-party toolkit for application GUI design which can also incorporate GadTools menus and ASL. MUI is also available on older AmigaOS systems and various clone systems although the implementation differs so compatibility is not guaranteed.

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.

• GadTools gadgets are incompatible with all others and have their own set of functions to be used with. There is no automatic layout system: GadTools gadgets are not scalable and are at fixed positions and dimensions. Using GadTools for GUI programming is no longer recommended, with the exception of the menu build and layout system.

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

• It you require modern features like scalability, font sensitivity, automatic (re)layouting, or window iconification (the ability to collapse the program window into an icon on the Workbench screen), then use one of the object-oriented toolkits: ReAction or MUI.

• The ASL toolkit is utilized by ReAction and MUI through dedicated classes. There is little need to use ASL directly in object-oriented GUIs.

• Prefer not to mix datastructure-oriented and object-oriented GUI programming. Functions designed for Intuition windows, gadgets or images are not meant to be used on GUI objects created via ReAction. BOOPSI objects must solely be manipulated using BOOPSI functions (methods).

• Many new programmers seem to be confused about window programming. It's fairly easy:
  • ReAction elements (objects) must reside in a ReAction window, that is, a window created through the Window Class, which is part of the toolkit. Such a window is manipulated as any other BOOPSI object.
  • Intuition or GadTools elements must reside in an Intuition window, that is, a window created through functions OpenWindow() or OpenWindowTags(), which are both part of the Intuition Library. Such windows are manipulated using dedicated functions.

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