akgl_ControlMap.mouseid, .penid and the axis fields are dead, deliberately #35

New Issue

tachikoma · 2026-08-02T18:33:19-04:00

tachikoma commented

2026-08-02 18:33:19 -04:00

Source: TODO.md, "Carried over", item 3 (at bbb7b8f)

akgl_ControlMap.mouseid and .penid are declared and never read. So are
.axis, .axis_range_min and .axis_range_max -- akgl_controller_handle_event
has never consulted them.

This is a recorded decision, not an oversight, and the issue exists so the
trigger is written down rather than rediscovered.

The UI subsystem (0.9.0) brought the mouse into the library and it would have been
natural to wire these up on the way. It did not, on purpose: control maps
translate device events into actor handler calls, and the UI wants absolute
pointer state per event. Those are different consumers, and building
gameplay-mouse machinery into src/controller.c with no game asking for it is the
abstract-before-the-second-consumer mistake.

The mouse path lives in src/ui.c (akgl_ui_handle_event).

The trigger: when a game wants mouse-driven actors, that is the consumer
these fields were declared for, and the work lands in src/controller.c then.
Until then, closing this means deleting the fields -- which is also a legitimate
answer, and an ABI break.

Files: include/akgl/controller.h, src/controller.c, src/ui.c

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

**Source:** TODO.md, "Carried over", item 3 (at bbb7b8f) `akgl_ControlMap.mouseid` and `.penid` are declared and never read. So are `.axis`, `.axis_range_min` and `.axis_range_max` -- `akgl_controller_handle_event` has never consulted them. **This is a recorded decision, not an oversight, and the issue exists so the trigger is written down rather than rediscovered.** The UI subsystem (0.9.0) brought the mouse into the library and it would have been natural to wire these up on the way. It did not, on purpose: control maps translate device events into *actor handler calls*, and the UI wants absolute pointer state per event. Those are different consumers, and building gameplay-mouse machinery into `src/controller.c` with no game asking for it is the abstract-before-the-second-consumer mistake. The mouse path lives in `src/ui.c` (`akgl_ui_handle_event`). **The trigger:** when a game wants mouse-driven *actors*, that is the consumer these fields were declared for, and the work lands in `src/controller.c` then. Until then, closing this means deleting the fields -- which is also a legitimate answer, and an ABI break. **Files:** `include/akgl/controller.h`, `src/controller.c`, `src/ui.c` --- Filed by Tachikoma (Claude Code, Opus 5, 1M context)

tachikoma added this to the Unscheduled milestone 2026-08-02 18:33:19 -04:00

tachikoma added the design-decision blast-radius:low labels 2026-08-02 18:33:19 -04:00

tachikoma added the status::grooming label 2026-08-02 18:49:18 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: andrew/libakgl#35

akgl_ControlMap.mouseid, .penid and the axis fields are dead, deliberately #35

`akgl_ControlMap.mouseid`, `.penid` and the axis fields are dead, deliberately #35