Intuition and C — Chapter Overview

This article is a structured overview of Chapter 3 ("Intuition and C") of Amiga C for Advanced Programmers by Bleek, Jennrich, Schulz (Abacus / Data Becker, ~1991). Chapter 3 is the longest in the book (~300 pages) and covers the Intuition library programming API — screens, windows, gadgets, requesters, menus, IDCMP event handling, the console device, and user-defined keyboard tables.

The chapter is structured as a tutorial: a single complex example (a text editor) is built up section by section, and each section adds one or more Intuition subsystems. This overview maps the sections and identifies the OS-programming concepts each one introduces.

Editorial note: page numbers in this article refer to the PDF page index in the raw OCR source. The chapter has 11 numbered sections (3.1–3.11) but the section numbering does not match the simpler "screens → windows → gadgets" mental model that the table of contents suggests.

Chapter 3 section map

Section PDF page range Topic
3.0 (intro) 93 What "system programming" means; Intuition's role
3.1 94–132 Windows: NewWindow structure, OpenWindow flags, IDCMP, refresh, gadgets, system gadgets
3.2 133–152 Screens: NewScreen, OpenScreen, screen types, public screens, screen-to-front/back
3.3 153–186 Graphics primitives: drawing primitives layered onto a RastPort (lines, rectangles, text, fill)
3.4 187–238 Gadgets: classic Intuition gadgets (boolean, string, integer, proportional, custom)
3.5 239–260 Requesters: EasyRequester, AutoRequest, custom requesters, IDCMP_REQSET/REQCLEAR
3.6 261–272 Alerts: DisplayAlert, Alert(), AN_/AG_/AO_* constants, recovering from dead-ends
3.7 273–292 IDCMP event handling: configuration and reception (IDCMP flags, IntuiMessage structure)
3.8 293–346 Menus: MenuItem, Menu structures, sub-menus, GA_Extra, custom menu items
3.9 347–370 Console device: Window→Console routing, console handlers, RAW: and CON: device names
3.10 371–378 User-defined keyboard tables: raw-key mappings, Qualifier mapping, keymap conversion
3.11 379–end Memory management: AllocMem, FreeMem, MEMF_CHIP vs MEMF_PUBLIC, memory pools

Note: section 3.1 ("Windows") is presented before section 3.2 ("Screen Fundamentals") in the chapter, even though screens logically precede windows. The book chose to start with windows (the more visible component) and then back-fill screens as a foundation.

What "system programming" means in this chapter (page 93)

The chapter opens with a definition:

"This chapter concerns programming the Amiga operating system, especially system programming using Intuition. ... How do I tell my Amiga operating system that I want to use a certain graphic mode? How can I tell the system that the user has made some inputs (with the mouse or with the keyboard)? These are two questions which come under the topic 'system programming.'"

This framing — driving Intuition from C rather than writing assembly — is the central premise of the rest of the book. The Modern equivalent lives in:

The layered programming model

Throughout Chapter 3, the author uses a consistent layered model:

  1. exec.library — task scheduling, memory, signals (chapters 1, 2)
  2. Intuition — the GUI framework on top of exec (chapter 3)
  3. graphics.library — drawing primitives below Intuition (chapter 3.3)
  4. layers.library — the compositor that handles clipping and refresh (chapter 3.1 internals)
  5. Devices — keyboard, mouse, console via input.device, console.device, etc.

The book has no separate chapter on graphics.library or layers.library; instead they are introduced as Chapter 3 needs them. The modern NDK has dedicated autodocs for each library — see library-reference/graphics-library.md (166 functions) and library-reference/layers-library.md (38 functions).

Key concepts from the chapter

3.1 — Windows: NewWindow and OpenWindow

  • struct NewWindow is the declarative descriptor you fill in before opening a window.
  • OpenWindow() returns struct Window * (NULL on failure) and triggers IDCMP events.
  • The IDCMP event loop pattern (WaitPort() → GetMsg() → ReplyMsg() → process) is established here.

3.2 — Screens: NewScreen and OpenScreen

  • A screen is a virtual display that owns a RastPort, a ViewPort, and a BitMap.
  • OpenScreen() allocates these and lets intuition.library manage them.
  • PubScreenStatus() plus LockPubScreen() make a screen "public" (shareable between programs).

3.4 — Gadgets: classic Intuition gadgets

  • A gadget is a sub-area of a window that handles input.
  • Classic gadgets are NOT BOOPSI — they're filled in a struct Gadget and chained off NewWindow.Gadgets.
  • gadtools.library (21 functions) and BOOPSI classes came later; the book treats both in detail.

3.5 — Requesters: modal dialogs

  • EasyRequester is the high-level API for simple OK/Cancel dialogs.
  • AutoRequest is the simpler variant.
  • Custom requesters are windows with WFLG_REQACTIVE flag.
  • For deeper coverage, see debugging/alerts-and-gurus.md (which describes alert requesters).

3.6 — Alerts and dead-ends

  • Alert() triggers a system alert (red box on early boot, yellow box on later boot).
  • Constants like AN_StartupMsg, AN_IOError, AG_NoMemory describe what triggered the alert.
  • See debugging/alerts-and-gurus.md for the modern reference.

3.7 — IDCMP event handling

  • IDCMP flag bits (IDCMP_CLOSEWINDOW, IDCMP_MOUSEBUTTONS, etc.) tell Intuition which events the program wants.
  • The IntuiMessage structure is the wire format for events.
  • Some programs use WindowUserData() to attach state to a window.

3.8 — Menus: Menu and MenuItem

  • A Menu is a top-level entry in the menu strip.
  • A MenuItem is a single line item.
  • Sub-items make nested menus.
  • GA_Extra + IME_SELECTED are covered.
  • Menus send IDCMP_MENUPICK events; use MenuNumber() to decode.

3.9 — The Console device

  • The console device is a runtime alias for a window — Open("*", MODE_OLDFILE) returns the current console.
  • CON: opens a new console window.
  • The console handler interprets window specifiers like CON:10/10/640/200/Title.

3.10 — Keyboard tables

3.11 — Memory management

  • AllocMem(size, MEMF_CHIP | MEMF_PUBLIC) allocates memory. CHIP memory must be in the first 512 KB + 512 KB; PUBLIC can be anywhere.
  • Bitmap data, audio data, sprite data MUST be in CHIP memory.
  • Use MEMF_CLEAR for zero-initialised allocations.
  • The book covers the basics; for pools and OS 4.x compatibility, see exec/memory-pools.md.

What Chapter 3 explicitly does NOT cover

Synthesis articles for this chapter

This overview is one of several pages summarising Chapter 3 of the book:

Additional synthesis articles for sections 3.5 (requesters), 3.7 (IDCMP), 3.8 (menus), and 3.11 (memory) are planned but not yet written.

Sources

The section ordering in this article is taken from the actual chapter content (sections 3.1–3.11 numbered top-to-bottom), not from the simplified table-of-contents listing of "Screens, Windows, Gadgets".