Article 12: Intuition, Screens, Windows and Workbench – How the Amiga GUI Works 

In the previous article, we explored how Exec manages multitasking through tasks, processes, signals and message ports. Now we move one level higher in the Amiga architecture and look at the graphical user interface. When you use an Amiga, you normally interact with windows, screens, menus, icons and gadgets. 

Behind much of this graphical environment is one of the most important AmigaOS components:
intuition.library 

Intuition manages the fundamental user-interface concepts of AmigaOS. But Intuition is not the same thing as Workbench, and it is not responsible for drawing every pixel on the screen. 

To understand the Amiga GUI properly, we need to distinguish between:
graphics.library
intuition.library
Screens
Windows
Gadgets
Input events
Workbench

Let's start at the bottom. 

1. The Layers of the Amiga GUI 

A simplified view of the graphical environment looks like this
:
        Applications
             |
     +-------+-------+
     |               |
 Workbench      Other GUI programs
     |               |
     +-------+-------+
             |
             v
     intuition.library
             |
             v
      graphics.library
             |
             v
     Graphics hardware 

This is deliberately simplified, but it illustrates an important point. Workbench sits on top of operating-system services. Workbench is not the Amiga's entire graphical system. Other applications can use Intuition without depending on the Workbench desktop itself. 

2. What Is graphics.library? 

At a lower level we have:
graphics.library 

This library provides fundamental graphics functionality. 

It deals with concepts such as: 
drawing
bitmaps
display structures
graphical operations
text rendering
display modes
regions and clipping

If a program needs graphics operations, graphics.library provides the appropriate low-level operating-system services. But graphics.library does not by itself provide the complete user-interface abstraction that users normally associate with windows and menus. That is where Intuition enters the picture. 

3. What Is Intuition? 

intuition.library is the Amiga's graphical user-interface management system. 

It manages concepts such as:
Screens
Windows
Menus
Gadgets
User input
Window events 

Instead of every application inventing its own window-management system, programs can ask Intuition to provide standardized GUI elements. 

Conceptually:
Application
     |
     | OpenWindow()
     v
Intuition
     |
     v
Window 

The application can then receive information about what the user does with that window. 

4. Intuition Is Not Workbench 

This distinction is one of the most important things to understand. 

It is easy to think:
Intuition = Workbench but that is incorrect. 

A better model is:
Intuition
    |
    +---- Workbench
    |
    +---- Application A
    |
    +---- Application B
    |
    +---- Application C 

Intuition provides graphical user-interface mechanisms. Workbench is a graphical desktop environment that uses operating-system services including Intuition. In other words: Workbench uses the Amiga GUI system. Workbench is not the GUI system itself. This is why an Amiga application can open its own screen or window independently of the Workbench desktop. 

5. What Is an Amiga Screen? 

The word screen has a specific meaning in Intuition. 

A screen is a graphical display surface on which windows can exist. 
#
For example:
Screen
+--------------------------------------+
|                                      |
|    +---------------------+           |
|    | Window              |           |
|    |                     |           |
|    +---------------------+           |
|                                      |
+--------------------------------------+ 

A screen has graphical characteristics such as its dimensions, display mode and other display properties. The familiar Workbench desktop exists on a screen. But applications can also create their own screens. 6. Multiple Screens One of the classic features of the Amiga is its ability to use several screens. 

Conceptually:
Screen 1
Workbench

Screen 2
Paint program

Screen 3
Video application

Screen 4
Game or utility 

These screens can have different purposes and, depending on the hardware and display setup, different graphical characteristics. This was an unusual and powerful capability, particularly in the Amiga's early years. An application did not necessarily have to share the Workbench display environment. It could create a screen suited to its own requirements. 

7. Workbench Screen vs Custom Screen 

There are therefore two useful concepts to distinguish. Workbench screen Many applications simply open a window on the existing Workbench screen. 

Conceptually:
Workbench Screen
    |
    +-- Workbench windows
    |
    +-- Shell window
    |
    +-- Application window 

This provides a convenient shared desktop environment. Custom screen An application can instead open its own screen.

Application
     |
     v
Custom Screen
     |
     +-- Window A
     +-- Window B 

This gives the application greater control over its graphical environment. 

8. Why Would a Program Use Its Own Screen? 

Imagine a paint program. The Workbench screen might use display settings that are not ideal for the artwork being edited. A graphics application might prefer a different display mode or graphical configuration. 

Conceptually:
Workbench
320 or 640 pixel desktop
        |
        | separate screen
        v
Graphics Program

display mode chosen for artwork Games, video software, graphics programs and multimedia applications can similarly benefit from controlling their own display environment. The idea of screens therefore provides another layer of abstraction between applications and the display hardware. 9. Screen Switching Classic Amiga screens can be brought in front of or behind other screens. One of the distinctive visual experiences of the Amiga is the ability to reveal another screen by moving one screen vertically. 

You might see:
+--------------------------+
| Workbench                |
|                          |
|                          |
+--------------------------+
       +--------------------------+
       | Application Screen       |
       |                          |
       +--------------------------+ 

The Amiga hardware architecture makes this kind of behaviour particularly interesting because the display circuitry works with dynamically controlled display data. This is one of those areas where Amiga hardware and AmigaOS complement each other very well. 

10. What Is a Window? 

A window exists on a screen. 

Conceptually:
Screen
 |
 +-- Window 1
 |
 +-- Window 2
 |
 +-- Window 3 

Windows provide applications with rectangular areas in which they can present their user interfaces. 

A window may include elements such as: 
title bar
borders
sizing control
close gadget
depth gadget
application-specific gadgets

The exact appearance depends on the application, system version and window configuration. 

11. Screen vs Window 

This distinction is fundamental. A screen is the larger graphical environment. A window exists inside a screen. 

So:
Screen
   |
   +---- Window
   |
   +---- Window
   |
   +---- Window 

A good mental model is: Screen = workspace
Window = application area within that workspace 

Although simplified, this distinction makes Intuition much easier to understand. 

12. Opening a Window 

From a programmer's perspective, an application can ask Intuition to create a window. Classic Amiga programming uses functions and data structures provided by intuition.library. Once the window exists, the program may receive information about events relating to it. 

For example:
User clicks close gadget
        |
        v
     Intuition
        |
        v
   Event message
        |
        v
   Application 

This leads directly back to the topics from Article 11. The graphical user interface and Exec's message system work closely together. 13. Gadgets In Intuition terminology, interactive graphical controls are commonly called gadgets. 

Examples include controls used for: 
closing a window
changing its size
selecting an option
entering values
scrolling
activating commands

A simplified window might contain:
+--------------------------------+
| My Window                    [X]|
+--------------------------------+
|                                |
|  [ Button ]                    |
|                                |
|  Value: [____________]         |
|                                |
+--------------------------------+ 

The button and input area represent the kind of interactive controls that can be implemented using GUI components. In Amiga terminology, the word gadget is therefore important. 14. System Gadgets Some gadgets are associated with standard window-management functions. 

For example, depending on the window configuration, controls may allow the user to:
Close
Resize
Change depth
Zoom 

These functions give Amiga windows their familiar interactive behaviour. The application specifies which capabilities it requires, while Intuition provides the corresponding mechanisms. 15. Menus Intuition also provides menu handling. Classic Amiga applications often present menus through the screen's menu bar. 

Conceptually:
Project   Edit   Settings
   |
   +-- Open
   +-- Save
   +-- Save As
   +-- Quit 

When the user selects a menu item, the application needs to be informed. Once again, this fits naturally into the event-based architecture.

User selects menu item
        |
        v
     Intuition
        |
        v
      Message
        |
        v
    Application 

16. IDCMP – Receiving Intuition Events 

An important concept in classic Intuition programming is the IDCMP. IDCMP stands for:
Intuition Direct Communications Message Port It allows applications to receive selected Intuition events. An application can specify which kinds of events it is interested in. 

Examples include events associated with:
mouse buttons
keyboard input
menu selections
gadgets
window resizing
window closing 

This prevents applications from having to manually monitor every aspect of the input hardware. 

17. IntuiMessage 

Events can be delivered to the application through structures commonly known as:
IntuiMessage 

Conceptually:
Mouse / Keyboard
       |
       v
    Intuition
       |
       v
  IntuiMessage
       |
       v
Application's IDCMP
       |
       v
  Application 

The message contains information that allows the application to determine what happened. 18. Event-Driven Programming Now we can connect this directly to Article 11. 

An Amiga GUI program does not need to constantly ask:
Did the mouse move?
Was a key pressed?
Was a gadget clicked?
Was the window resized? Instead, it can wait for relevant events. 

Conceptually:
Application
     |
     v
Wait()
     |
     | sleeps
     |
     v
Intuition event
     |
     v
Signal
     |
     v
Application wakes
     |
     v
Get message
     |
     v
Handle event 

This is known as an event-driven architecture. 

19. A Typical GUI Event 

Loop A simplified Amiga application can therefore be imagined as performing the following loop:
Open Screen/Window
       ↓
Wait for event
       ↓
Receive message
       ↓
Determine event type
       ↓
Process event
       ↓
Reply to message
       ↓
Wait for next event This continues until something happens that tells the application to terminate. For example:
Close window selected
        |
        v
Exit event loop
        |
        v
Release resources
        |
        v
Program terminates 

This structure appears in many graphical Amiga applications. 20. Why Replying to Messages Matters The messages delivered by Intuition belong to a message-based communication system. Applications must therefore handle them correctly. 

A typical conceptual operation is:
GetMsg()
   |
   v
Read relevant information
   |
   v
ReplyMsg() 

This reflects a broader rule of Amiga programming: Resources and messages provided by the operating system must be handled according to their defined ownership and lifetime. This becomes increasingly important when we eventually look at actual Amiga programming. 21. The Mouse and Keyboard The application usually does not need to read raw hardware registers to discover what the user is doing. Input passes through operating-system components before becoming useful GUI events. 

A simplified view is:
Mouse / Keyboard
       |
       v
Input system
       |
       v
Intuition
       |
       v
Application event 

This provides abstraction. The application focuses on questions such as:
Which gadget was selected?
Which key was pressed?
Did the user choose a menu item? 

rather than worrying directly about electrical signals from the keyboard or mouse. 

22. Workbench 

We can now place Workbench properly into the architecture. Workbench is the familiar desktop containing: disk icons
drawers
program icons
files
windows

But Workbench does not replace Intuition. Instead, it is an application environment built using AmigaOS services. 

Conceptually:
                User
                  |
                  v
              Workbench
                  |
          +-------+-------+
          |               |
      Intuition        AmigaDOS
          |               |
          +-------+-------+
                  |
                 Exec
                  |
               Hardware 

Again, the real architecture contains more detail, but this mental model is useful. 23. Workbench Icons Workbench uses icons to represent objects graphically. 

You may encounter a pair such as:
MyProgram
MyProgram.info 

The first could be the executable program. The second contains information associated with the Workbench icon. This explains an observation we made earlier in the Shell articles. 

From Workbench, you may visually see:
[ MyProgram icon ] while the Shell reveals files such as:
MyProgram
MyProgram.info 

Workbench provides the graphical representation. AmigaDOS provides access to the filesystem objects underneath. 

24. Tool Types 

Workbench icons also contain information about how an object should behave. 

Classic Workbench commonly distinguishes icon types associated with concepts such as:
Tool
Project
Drawer
Disk 

A Tool generally represents an executable application. A Project represents data intended to be opened by an application. A Drawer represents a directory. This gives Workbench information about how the user can interact with the object. 

25. Tool Types and ToolTypes 

Two terms that can easily cause confusion are:
Tool type and:
ToolTypes 

They are not exactly the same concept. The icon type describes the general kind of Workbench object. ToolTypes, on the other hand, are configuration strings stored with an icon. An application can use ToolTypes to receive configuration information when launched from Workbench. 

Conceptually:
Application icon
       |
       +-- graphical information
       |
       +-- object type
       |
       +-- ToolTypes
                |
                v
         Program settings 

This provides a convenient way for Workbench-launched applications to receive options. 26. Starting Programs from Workbench When you double-click a Tool icon, Workbench can launch the associated program. But the environment differs somewhat from simply entering the program name in a Shell. A Shell program naturally exists within a command-line environment. A Workbench-started application receives startup information appropriate to Workbench. 

Good Amiga programs may support launching from:
Workbench
and:
Shell 

The program may therefore have to recognize which startup environment was used. 

27. Project Icons 

Imagine you have:
Letter
Letter.info 

where Letter contains a document. The .info file can identify that object as a project and associate it with an application. 

Workbench can then provide a graphical relationship similar to:
Document
   |
   | open with
   v
Application 

This makes the desktop much easier for non-technical users than manually entering a Shell command containing both program and filename.

28. Drag and Drop 

Workbench also allows graphical operations such as dragging icons. 

From the user perspective:
Drag file
   |
   v
Drop on drawer 

may correspond to a file-management operation. Again, Workbench provides a graphical layer above functionality that ultimately interacts with the filesystem and operating system. 

This demonstrates the relationship between:
GUI abstraction and:
AmigaDOS resources

29. Workbench and AmigaDOS Are Two Views of the Same System 

This is a particularly important lesson. 

Suppose Workbench displays:
System disk
   |
   +-- Prefs
   +-- Tools
   +-- Utilities The Shell might display the same underlying structure through:
SYS:
SYS:Prefs/
SYS:Tools/
SYS:Utilities/ 

Workbench sees graphical objects. The Shell sees paths and files. They are often different interfaces to the same underlying resources. 30. Public Screens Later AmigaOS versions also formalized the concept of public screens. A public screen can allow multiple cooperating applications to open windows on a named screen rather than every application creating its own private screen. 

Conceptually:
Public Screen
    |
    +-- Application A window
    |
    +-- Application B window
    |
    +-- Application C window 

The Workbench screen is the most familiar example of a shared screen environment. Public screens provide a flexible mechanism for applications that want to share an alternative graphical workspace. 

31. Why Screens Are Different from Modern Desktops 

Modern graphical systems commonly present applications within one large desktop environment. The Amiga's screen concept is somewhat different. An application can have a fairly independent graphical environment with its own screen characteristics. 

Conceptually:
Workbench Screen
-----------------
Normal desktop

Graphics Screen
-----------------
Graphics application

Video Screen
-----------------
Video application 

These are not merely windows positioned on one giant virtual desktop. They are separate Intuition screens. That distinction is fundamental to understanding the classic Amiga GUI. 32. Graphics, Intuition and Workbench We can now summarize the three major graphical layers. graphics.library Think: Drawing and display primitives. intuition.library Think: Screens, windows and interaction. Workbench Think: Graphical desktop and file-oriented user environment. 

In simplified form:
             Workbench
                 |
                 v
             Intuition
                 |
                 v
         graphics.library
                 |
                 v
        Graphics subsystem
                 |
                 v
             Hardware Applications 

do not necessarily have to use every layer. For example, an application can use Intuition without being a Workbench-style file manager. Likewise, lower-level software may use graphics functionality without creating a conventional Intuition GUI. 

33. Intuition and Exec 

Now we can connect this article directly to Article 11. Intuition depends heavily on mechanisms provided by Exec. 

Remember:
Exec provides
 |
 +-- Tasks
 +-- Signals
 +-- Message Ports
 +-- Messages Intuition can build an event-driven GUI system using these mechanisms. Conceptually:
                 Exec
                   |
          Signals + Messages
                   |
                   v
               Intuition
                   |
           IntuiMessages
                   |
                   v
              Application 

This modular layering is extremely characteristic of AmigaOS. 34. Following a Mouse Click Through the System Let's put the pieces together with a simplified example. The user clicks a gadget inside an application. 

At the highest level:
User
 |
 | click
 v
Mouse
 |
 v
Input system
 |
 v
Intuition
 |
 | IntuiMessage
 v
Application's message port
 |
 | signal
 v
Application wakes
 |
 v
GetMsg()
 |
 v
Determine selected gadget
 |
 v
Perform requested action
 |
 v
ReplyMsg()
 |
 v
Wait again 

That one example connects: 
hardware input
operating-system input handling
Intuition
message ports
signals
multitasking
application logic

This is why understanding each layer separately eventually pays off. 35. The Amiga Philosophy Appears Again Throughout this course we have repeatedly encountered the same architectural philosophy. Instead of one giant operating-system component controlling everything, AmigaOS uses cooperating subsystems. 

For the GUI:
graphics.library
        |
        v
    Intuition
        |
        v
   Applications 

For files:
AmigaDOS
    |
    v
Handlers 

For hardware I/O:
Application
    |
    v
.device
    |
    v
Hardware 

And underneath much of this:
Exec
 |
 +-- multitasking
 +-- memory
 +-- signals
 +-- messages 

The more of AmigaOS we examine, the more this modular design becomes visible. 

36. A Useful Mental Model 

For beginners, remember this simplified hierarchy:
Workbench
= Desktop

Intuition
= GUI management

graphics.library
= Graphics services

Exec
= Fundamental OS mechanisms

Custom chips
= Graphics and hardware support 

And within Intuition:
Screen
   |
   +-- Window
          |
          +-- Gadgets
          |
          +-- Menus
          |
          +-- Application content 

Events travel back to the application through the message-based mechanisms we explored in Article 11. Conclusion The Amiga's graphical environment becomes much easier to understand once Workbench, Intuition and graphics.library are treated as separate components. Workbench is the graphical desktop the user sees. 

Intuition provides the higher-level concepts behind graphical applications:
Screens
Windows
Gadgets
Menus
Events 

graphics.library provides lower-level graphical services. And underneath them lies Exec with its multitasking, signals and message-port architecture. The most important distinction to remember is: Workbench is an application environment built on AmigaOS. Intuition is the GUI management system that makes screens, windows and interaction possible. This also explains one of the Amiga's most distinctive characteristics: an application does not necessarily have to live inside the Workbench desktop. It can open its own screen, with its own windows and graphical environment. 

We now have a path through much of the system:
Hardware
   ↓
Exec
   ↓
graphics.library
   ↓
Intuition
   ↓
Workbench / Applications
   ↓
User Next: Article 13 – Amiga Memory Management in Depth The next chapter can bring several earlier subjects together by examining how Exec actually manages memory: memory lists, memory blocks, AllocMem(), Chip RAM versus Fast RAM from the operating system's perspective, memory fragmentation, memory priorities and what really happens when an Amiga program requests memory.