Activities, Select keys, and the System Menu in Symbolics Genera

Evidence and rights boundary

The source and extracted Help artifacts below came from licensed Open Genera media and remain untracked. This page retains portable identities and original analysis, not the proprietary source or decoded Help text.

The public manuals describe Genera 8; the local world identifies as 8.5. Exact live registries and menus below therefore come from the 8.5 runtime rather than being silently copied from an earlier reference table.

What an activity represents

The source describes an activity in operational terms: something connected to a Select key, the System Menu, or Select Activity. That intentionally broad contract supports several implementations:

User interfaces pass an activity-name string and resolve it through the registry when selected. They do not have to retain the original activity object. That indirection allows a later definition to replace an activity without leaving every menu cell pointing at the old object.

The activity table is a case-insensitive string table with an initial size of 32. Redefinition checks the source file associated with an existing name; patch, site, and explicit clobber paths can replace an installation while accidental unrelated redefinition is diagnosed. This is a live extension mechanism, not merely a compiled constant.

How selection finds or creates a window

Selecting an activity does not always create a new window. The inspected find-frame-for-activity logic searches in this order:

1. give the current activity and its superiors an opportunity to satisfy the selection;
2. consider previously selected windows for that activity;
3. inspect exposed inferiors across the console's screens;
4. if allowed and still necessary, create a new instance.

Options govern whether an already selected instance is acceptable and whether a new instance is forced. If the only suitable instance is already selected and the caller did not allow that result, the system can signal the condition with a beep rather than needlessly making a duplicate. Selection is therefore a policy-mediated search, not a direct constructor call.

Precreate Activities accepts either activity names or Select characters and may start creation in a process. It trades time and memory during initialization for faster first selection later. The distinction between precreation and selection is visible in the API even though both ultimately prepare an activity's window.

Complete live activity registry

A direct evaluation of CLI::*ACTIVITY-TABLE* in a fresh isolated 8.5 world returned these 19 registered names:

This is a runtime registry census, not a claim that every activity's external service was configured. The world explicitly reported an unconfigured site and disabled servers.

Complete live Select-key bindings

The Select table is case-insensitive and normalizes letter characters to uppercase. Its initial source allocation is 20 entries. A “firewall” can enable all registered Select characters or only a chosen subset for a context. The older TV:*SELECT-KEYS* mechanism is marked obsolete in the inspected implementation and is not the table used for these results.

The fresh runtime evaluation returned exactly 12 bindings:

The Select Activity Command Processor command offers completed activity names and accepts a target screen, so an activity need not have a single-character binding to be selectable. The Select Key Selector is itself an activity, reached by Select =, and reports the installed bindings.

The source, installed Help, public handbook, and live registry do not form one timeless list. In particular, the public User's Guide assigns Select F to File System Maintenance, but this live table does not contain F. The handbook also names FEP-Tape and File System Maintenance activities that are absent from the live 8.5 activity table, while the live table includes File Server and Namespace Editor even though the installed selector-help database has no activity record for either. Those are version/install-state differences preserved as evidence, not reconciled by guessing.

System Menu construction

The System Menu is a reusable Dynamic Windows multicolumn momentary menu. Its three headings are Windows, This window, and Programs. Each column has a source-defined base, and loaded systems extend it by registering or replacing named items. Reusing a name updates and reorders that item rather than necessarily adding a duplicate.

This explains why parsing only sysmen.lisp undercounts the screen. The base Programs source contains only Emergency Break, yet the running world displayed 11 program choices after installed systems registered their entries. Split Screen and Hardcopy are similarly installed additions to their live columns.

Windows-column operations

The default Create menu in the directly evaluated world had ten exact entries:

The final row is a generic construction escape hatch. Counting it as a tenth application would confuse a menu operation with the window it may create.

This-window operations

These operations act on a chosen window, normally the one associated with the mouse. Several have right-button variants that first ask which window to affect.

The menu therefore exposes process control and window-stack control beside geometry. Bury, Arrest, and Kill are not synonyms: one changes exposure order, one suspends execution, and one removes the target.

The Hardcopy button triple is a live-world observation, not an inference from two similarly named source wrappers. A read-only registry query printed Left/Middle as TV:SYSTEM-MENU-HARDCOPY-WINDOW and Right as TV:SYSTEM-MENU-HARDCOPY-WINDOW-MENU; it did not invoke either wrapper or submit output. The exact binding and target-routing contract is specified in the D02 reimplementation specification.

Programs-column operations

Most entries select or create their corresponding installed programs. Their presence establishes discoverability in this world, not configuration of every dependency.

The broader Genera software-area catalog keeps these runtime entries distinct from command areas, release systems, optional media, and program-framework definitions.

Split Screen in detail

The inspected source presents Split Screen as an interactive layout builder rather than a fixed “divide this window in two” command. Its supplemental choices are:

Installed window types are added alongside these builder-specific choices. A chosen window can also be wrapped or annotated with a frame, name, or Select key.

For fewer than four requested windows, the automatic layout uses one column and N rows. At four or more, it uses two columns and ceiling(N/2) rows. Windows fill rows from left to right; when the count is odd, the final bottom window extends to the right edge and spans both columns. This small algorithm is a source-visible behavior that a generic description such as “tiles the windows” misses.

Source comments preserve unfinished or troublesome edges: possible disk thrashing, editing saved layouts, a mouse-oriented layout display, and an intermittent choose-variable-values problem. They are not promoted here into observed failures; they show what the implementation's authors still considered problematic at this source revision.

One historical implementation detail is especially easy to miss: source comments say Split Screen was added, somewhat arbitrarily, when Inspect was installed and was used as a development tool. Its presence in the finished System Menu does not mean it originated as a universal primitive of the base menu.

Layouts and persistence boundary

Layouts offers Just Lisp, Save This, and saved names. The saved representation records live window objects together with their edges. It is therefore a snapshot of an arrangement of existing objects, not a portable declarative recipe containing only application names and dimensions.

Source inspection did not establish a separate serialized layout-file format. A saved layout might survive as part of a saved Lisp world, but that possibility was not tested and should not be conflated with a user-facing persistent layout file. Runtime save/restore of a named layout remains a TODO for a future isolated session.

Findings not evident from a menu list

• Activity selection searches current, prior, and exposed windows before creation. “Select launches an application” is incomplete and often wrong.
• Program-choice activities defer the choice of concrete program until selection time. One activity name can adapt to screen or runtime conditions.
• Menu cells resolve primary-name strings through the activity table. This makes activity redefinition meaningful to already constructed interfaces.
• The Select table has a contextual firewall. A registered global gesture need not be enabled in every interaction environment.
• The System Menu is assembled by registrations from loaded systems. Its source base and its live displayed contents are different evidence sets.
• Split Screen's base installation is coupled to Inspect in this source revision, and its comments identify it as a development tool. Its polished menu position hides that lineage.
• Save This retains live window identities. It is semantically different from a modern desktop layout file that recreates applications from names after restart.
• Emergency Break bypasses ordinary application selection and uses the cold-load stream. It belongs in the menu for recovery, not because it is an application.

Runtime observation in Genera 8.5

A fresh isolated session named core-dossiers-20260718, generation 1, opened the System Menu and later exercised the Listener, Inspector, and Peek.

The VLM ran in separate user, mount, network, PID, IPC, and hostname namespaces. It had no external route or guest-visible host file service, and Xvfb did not advertise MIT-SHM. The exact X compatibility substitutions and local RFC 868 exchange were observed and validated; the responder exited zero. Bubblewrap exposed only the read-only Guix store, exact read-only helpers and X socket, and writable private runtime needed for the run. This is process reach reduction, not a claim of complete kernel isolation.

At 04:00:48 EDT, holding Shift and the right mouse button over the client displayed the three-column System Menu enumerated above. The pointer action was recorded as an intent before XTEST delivery and a linked successful outcome afterward. The menu was then dismissed before Select I and Select P opened the Inspector and Peek; Select L later returned to the Listener.

Scope limits and open questions

• The exact activity and menu lists describe one inspected 8.5 world. Loading or unloading systems, applying patches, or changing site code can alter them through the documented registration interfaces.
• The current runtime session opened the System Menu and used three Select gestures; it did not execute every potentially destructive or service-dependent menu item.
• Named-layout save and restore, screen editing, and Split Screen's odd-window automatic layout should be exercised in a future isolated session. Until then, their descriptions remain source- and manual-grounded rather than runtime claims.
• The isolated world was deliberately not configured as a Symbolics site. Menu presence does not establish working mail, namespace, hardcopy, distribution, or network services.

Sources

• Symbolics, Genera User's Guide, Genera 8, activities, Select keys, windows, and System Menu sections; verified 2026-07-18.
• Symbolics, Genera Workbook, Genera 8, Select Activity and System Menu exercises; verified 2026-07-18.
• Symbolics, Programming the User Interface, Genera 8, window-system and interaction architecture; verified 2026-07-18.
• Licensed local Genera 8.5 source and extracted Document Examiner help, identities recorded above; inspected 2026-07-18.
• Fresh core-dossiers-20260718 Genera Xvfb session, generation 1, input, image, and shutdown evidence recorded above; observed 2026-07-18.
• Fresh d01-hardcopy-item-probe-g85-20260719 Genera Xvfb session, generation 1, read-only registry, image, unchanged-world, and shutdown evidence recorded above; observed 2026-07-19.