Repository navigation
No support for Intuition system Requesters (struct Requester) — CLICK/TREE can't see or act on them #52
Description
Problem
Confirmed via a full source grep (Requester/IDCMP_REQ/AutoRequest/
EasyRequest/SysReq — zero matches anywhere in server/,
intuition-model/, amiinspect/, host/, manifest/, docs/,
userdocs/): AmiPilot has no support at all for Intuition's
Requester mechanism (struct Requester, intuition/intuition.h) —
the modal boxes behind Request()/AutoRequest()/EasyRequest(),
covering both an application's own "Are you sure?" dialogs and
system-wide ones (disk-swap "Please insert volume X", DOS error
requesters, Software Failure/Guru).
This is architecturally distinct from every locator this project
already supports: a Requester's content (its OK/Cancel-style buttons,
its body text) lives in its own ReqGadget list, reached via
window->FirstRequest (window-attached form) — not
window->FirstGadget, which is the only chain
intuition-model/src/walk.c's WalkGadgetList() ever iterates. So
even a window that TREE already finds successfully will show nothing
useful once a Requester opens over it, and CLICK/GETTEXT have no
locator that can reach a Requester's gadgets by any means (GA_ID,
ROLE=, or otherwise) since the walker never sees them.
AutoRequest()'s own autodoc (BuildSysRequest(), which it's built
on) confirms a system-wide requester (no owning window — the
common case for disk-swap/DOS-error/Guru requesters) can come back as
a genuine struct Window of its own, separate from any application
window. That window would currently be findable by AmipFindWindow()
(it walks every screen's window list) — but its actual box/text/gadgets
are still only reachable through that window's FirstRequest chain,
same gap.
Practical impact
- A test driving real, unmodified software (the stock-app-conformance
goal this project already holds itself to) has no way to detect or
dismiss an unexpected requester — a disk-swap prompt, a "file
already exists, overwrite?" dialog, a crash/Guru — viaCLICK. The
automation session likely just stalls waiting on aWAITFOR/TREE
that never sees what's actually blocking the target window. - Reported by @sidick during hardware-adjacent testing setup (a real
Picasso96 3.6 install on theamipilothard drive, uaegfx enabled)
as a real gap worth tracking, with manual click-through as the
interim workaround.
Proposed design (sketch, not yet scoped in detail)
- Discovery: extend
intuition-model's walk to also report a
window'sFirstRequestchain (or the presence of one) — a
Requester's ownLeftEdge/TopEdge/Width/Height/ReqGadget
list is real, walkable structure, the same shape as a window's own
gadget list, just reached differently.TREE's output would need a
way to represent "this window currently has an active requester"
distinctly from its normal gadget tree. - System-wide requesters: since
BuildSysRequest()can produce a
standalone window with no application owner,AmipFindWindow()
already reaching it is necessary but not sufficient — its content
still needs the sameFirstRequestwalk as the window-attached
case. - Action:
CLICK's existingROLE=/INDEX=/GA_IDlocators
would need a way to target a Requester gadget specifically (a new
locator prefix, e.g.REQ=?), sinceGA_IDon a Requester's
ReqGadgetlist could collide with the owning window's own
FirstGadgetIDs. - Detection without acting: a
WAITFOR-style condition
("a requester appeared on window X") would let a test at least
assert on / react to an unexpected requester rather than only
silently timing out, even before full requester-gadget targeting
lands.
Why now
Filed per @sidick's request while setting up real hardware-adjacent
testing (Picasso96 3.6 + uaegfx installed on the amipilot test hard
drive) — noted as a real, currently-unaddressed gap to track rather
than something to silently work around; manual click-through remains
the interim path until this is designed and scoped properly.
Activity
sidick commentedon Aug 8, 2026
Detection-only slice landed in #70:
WAITFOR [SCREEN=<s>] REQUESTER [TIMEOUT=<n>]polls server-side until a genuine Intuition Requester appears, so a test can now assert "a requester appeared" instead of silently stalling. Matching host client support:wait_for("requester").Scope: window-attached Requesters only (the common in-app case:
Request()/AutoRequest()/EasyRequestArgs()called with a real owning window). A system-wide Requester with no owning window (a disk-swap prompt, a DOS error, Guru/Software Failure) is still undetected —BuildSysRequest()'s own autodoc says these can come back as a standalonestruct Window, but reliably telling that apart from an ordinary app window needs more research than this pass covered. That, and full interaction (clicking a Requester's own gadgets — a separateReqGadgetchain fromwindow->FirstGadget, needing its own locator scheme to avoidGA_IDcollisions with the owning window), remain open under this issue.Worth flagging: the detection mechanism ended up different from what the RKRM/NDK autodocs describe. Confirmed live against a real
AutoRequest()call (fixtures/gadtools-app's newAskbutton): on this project's target OS/ROM,AutoRequest()/BuildSysRequest()/EasyRequest()given a real owning window do not populatewindow->FirstRequest(the classicRequest()-based structRequesterchain), and the Positive/Negative gadgets do not carry theGTYP_REQGADGETbitBuildSysRequest()'s own autodoc documents on them either. Instead, per that same autodoc's own text ("a new window is opened in the same screen as the one containing your window"), it's a genuinely separatestruct Window— one that happens to share its owner's exact title text, which no ordinary well-behaved app window does on its own. Detection uses that title collision as the real signal (FirstRequestis still checked first, both because it's free and in case a future genuineRequest()-based interaction path relies on it directly). Full writeup inWaitForRequesterPresent()'s own comment,server/src/amipilotserver/main.c.Add WAITFOR REQUESTER: detection-only slice of issue #52 (#70)
sidick commentedon Aug 9, 2026
Investigated the design sketch above before implementing it, and the premise turned out to be wrong for this project's real target OS/ROM — good news, not a setback.
A window-owned
AutoRequest()/BuildSysRequest()/EasyRequest()requester doesn't attach invisibly to the owning window'sFirstRequest/ReqGadgetchain at all. It opens as a completely ordinary, separatestruct Windowsharing its owner's exact title text (confirmed live viaTREE: while the requester is up, the same window pattern resolves to a different window with a real, directly-walkable gadget list). That means ordinaryCLICK <window-pattern> <gadget-id>already reaches it today — noREQ=locator, no wire protocol change, noTREErepresentation work needed.BuildSysRequest()'s own autodoc documents a fixed, app-independentGadgetIDconvention (TRUE=1 positive,FALSE=0 negative), confirmed live by actually clicking it and watching a realAutoRequest()dismiss — see PR #82.Narrowing this issue's remaining scope to what's genuinely still open:
ReqTextis rendered directly asIntuiText, never exposed as a gadget attribute —GETTEXThas nothing to target.BuildSysRequest(NULL, ...)— the real disk-swap/DOS-error/Guru case — opens on the default public screen with no known title to pattern-match against at all. This is the genuinely harder half or the RKRM-sketch case that motivated filing this issue; still unaddressed.Leaving open for those two.
Confirm requester body text is a permanent limit, not open work (#52)
sidick commentedon Aug 9, 2026
Follow-up on the body-text question flagged in my previous comment: settled it, live, as a confirmed permanent limit, not open work.
struct Requester->ReqText(astruct IntuiText *, perBuildSysRequest()'s own autodoc) would be the obvious field to read a requester's body text ("Are you sure?") back from — but a temporary diagnostic (dumpingFirstRequest/ReqCountfor every open window while a realAutoRequest()was up) showed both NULL/0 on both the owning window (genuinely blocked insideAutoRequest()at the time) and the requester's own separate window (the one PR #82 confirmedCLICKcan already dismiss). Nostruct Requesterexists anywhere reachable in this scenario on this project's real target OS/ROM — the body text is rendered directly into the requester window's own bitmap at open time, with nothing structural retaining it for later readback.GETTEXTneeds a live field to query, and there genuinely isn't one here — the same shape as this project's other confirmed structural-reading limits (aPLACETEXT_INbutton's baked-in label,layout.gadget's invisible children). Documented in PR #82.Remaining scope for this issue is now just the one item from my last comment: system-wide requesters with no owning window (disk-swap/DOS-error/Guru) are still detection-only.
Detect and dismiss system-wide Requesters too, closing #52 fully
CLICK now handles both window-owned AND system-wide Requesters, closing