Skip to content

Run a transaction's follow-up work as effects ordered by what they read - #197

Merged
pragmatrix merged 3 commits into
masterfrom
effect-scheduler
Nov 13, 2026
Merged

pragmatrix merged 3 commits into
masterfrom
effect-scheduler

Conversation

@pragmatrix

Copy link
Copy Markdown
Owner

Why

The work that follows a desktop transaction's changes (layout, column counts, MCP indicators, selection, camera, hover, persistence) was spread over three places: the fields of ChangeSurface, a hand-ordered enum of effect phases, and a fixed sequence of steps at the end of transact. None of them said what a step depends on, so a new step had to be placed by hand in each of them, and a wrong phase only showed up as a panic at runtime.

Summary

ADR 0043 records the decision and lists every feature of the new scheduler with the case that needs it.

  • All follow-up work of a transaction is now an effect: a value without data, such as Measure(target), that names work still to do. The glossary defines effect, system effect, mark, rank, and rank batch.
  • Code marks an effect through a task-local that transact installs for one transaction. Marking only appends, and a mark outside a transaction panics.
  • Each effect kind declares the kinds whose results it reads. That declaration is the only source of the order: the kinds are sorted topologically once, and a cycle panics at startup.
  • The scheduler handles one rank batch at a time and drops duplicate marks, so Measure climbs bottom-up and Place descends top-down without a hand-written phase.
  • Kinds without a subject, such as UpdateHover and SynchronizeCamera, are marked automatically after a kind they read was handled, so they run only when something they depend on changed.
  • ChangeSurface and the steps at the end of transact are gone. The host effects (persisting the configuration, MCP root changes, the window's fullscreen state) are effects too. Fullscreen is now requested as a state instead of a toggle.

Details

These behaviors change, as the ADR's consequences list:

  • A focus that moves away and back within one transaction now counts as a change, so it collapses the selection and shows the zoom level indicator.
  • The desired camera is resolved again after any measure or placement, including measures that only a refreshed column count or MCP indicator caused.
  • The zoom level indicator is laid out at the window size after a resize, not before it.

Validation

  • All massive-desktop tests pass, including six new tests of the scheduler core and a new system test for the camera catching up after a gesture. That test caught a regression during the port: a release that changed nothing left the camera where the press had frozen it.
  • To check by hand before merging, since no test renders: the hover outline follows the pointer and the keyboard focus, layout changes still animate, and toggling the window's fullscreen state works.

Note

This was created with AI assistance.

@pragmatrix
pragmatrix merged commit a2c6ed5 into master Nov 13, 2026
2 checks passed
@pragmatrix
pragmatrix deleted the effect-scheduler branch November 13, 2026 11:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant