A dialog the player can dismiss: akgl_ui has no dismiss contract #80

New Issue

tachikoma · 2026-08-02T19:04:58-04:00

tachikoma commented

2026-08-02 19:04:58 -04:00

Source: filed from akbasic's TODO.md §7, which recorded it and deliberately did not file it (at 9151438)

There is no dismiss contract for a dialog. A declarative frame means the visibility flag is
the dialog's existence, so the only way down is for the caller to stop declaring it.

That works when the caller is C code that owns its own state. It does not give a player a way to
dismiss anything: there is no "this dialog was acknowledged" edge for a caller to react to, so
every consumer has to invent one -- read the mouse, hit-test the button, own the flag.

The consumer that hit it: akbasic's DIALOG verb, where "DIALOG with no argument is the only
way down" is the documented behaviour for a BASIC program. A program cannot put up a message box
and wait for OK, which is the single most ordinary thing a dialog is for.

What closing it wants deciding first, and that is why this is a design issue rather than a
patch:

Whether the helper returns an edge (dismissed out-param on the next frame the button was
clicked) or owns a small piece of state itself. The first fits the declarative model; the second
is what a caller keeps writing by hand.
Whether a dismissable dialog implies a modal input capture, which nothing in akgl_ui currently
has.

Recorded rather than designed here: the consumer's requirement is one bit of information per frame,
and anything that supplies it closes this.

Filed by Tachikoma (Claude Code, Opus 5, 1M context)

**Source:** filed from `akbasic`'s TODO.md §7, which recorded it and deliberately did not file it (at 9151438) **There is no dismiss contract for a dialog.** A declarative frame means the visibility flag *is* the dialog's existence, so the only way down is for the caller to stop declaring it. That works when the caller is C code that owns its own state. It does not give a player a way to dismiss anything: there is no "this dialog was acknowledged" edge for a caller to react to, so every consumer has to invent one -- read the mouse, hit-test the button, own the flag. **The consumer that hit it:** `akbasic`'s `DIALOG` verb, where "DIALOG with no argument is the only way down" is the documented behaviour for a BASIC program. A program cannot put up a message box and wait for OK, which is the single most ordinary thing a dialog is for. **What closing it wants deciding first**, and that is why this is a design issue rather than a patch: - Whether the helper returns an edge (`dismissed` out-param on the next frame the button was clicked) or owns a small piece of state itself. The first fits the declarative model; the second is what a caller keeps writing by hand. - Whether a dismissable dialog implies a modal input capture, which nothing in `akgl_ui` currently has. Recorded rather than designed here: the consumer's requirement is one bit of information per frame, and anything that supplies it closes this. --- Filed by Tachikoma (Claude Code, Opus 5, 1M context)

tachikoma added this to the 1.0.0 milestone 2026-08-02 19:04:58 -04:00

tachikoma added the api-gap design-decision blast-radius:medium status::grooming labels 2026-08-02 19:04:58 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: andrew/libakgl#80