Problem
MUIREXX (server/src/muirexx.c) is a real, honest passthrough to a MUI application's own ARexx port — but MUI's own built-in ARexx support (confirmed live against AmigaOS 3.2's own MUI-Demo, server/README.md's own MUIREXX section) is a small, universal, fixed set: quit/hide/show/activate/deactivate/info/help. None of these read or set an individual widget's value/state — genuine per-widget interaction (click a MUI button, read/set a MUI string gadget's text, toggle a MUI checkmark) is currently only possible if the target application itself has added its own custom ARexx commands for that, which MUIREXX can pass through but can't invent.
Combined with #67 (no structural inspection of a MUI app's object tree at all), this means AmiPilot currently has no general-purpose way to act on an individual MUI widget the way it can for GadTools/top-level ReAction gadgets via CLICK/TYPE/GETTEXT — only the app-level 7 commands, or whatever bespoke ARexx verbs a specific app happens to expose.
Proposed scope (research first)
Depends heavily on what #67's research finds about safe external introspection. If a real object-identity mechanism is found (a cooperative port, or some other genuinely-documented external hook), the natural extension is: use that identity to synthesize real input.device events at the widget's own resolved screen coordinates — the same "real input, not BOOPSI method injection" principle this project already holds for every other locator tier (CLICK/TYPE/DRAG all use genuine synthesized input, never DoMethod() poking into another process's live object). MUI's own windows ARE real Intuition windows underneath, so once a widget's real screen rectangle is known, acting on it isn't fundamentally different from acting on any other gadget — the hard part is entirely the identification half (#67), not the action half.
If no safe external mechanism turns out to exist at all, the honest outcome may be documenting this as a permanent Tier 3/4-only limit (matching the project's own "honest limit, not a gap" precedent elsewhere) rather than a solvable gap — to be decided once #67's research lands, not assumed here.
Why file now
Filed per user request as part of a general post-1.0 planning pass, alongside #67 — this is the "management" half of "MUI inspection and management," deliberately scoped as dependent on #67's findings rather than speculatively designed ahead of that research.
Problem
MUIREXX(server/src/muirexx.c) is a real, honest passthrough to a MUI application's own ARexx port — but MUI's own built-in ARexx support (confirmed live against AmigaOS 3.2's own MUI-Demo,server/README.md's own MUIREXX section) is a small, universal, fixed set:quit/hide/show/activate/deactivate/info/help. None of these read or set an individual widget's value/state — genuine per-widget interaction (click a MUI button, read/set a MUI string gadget's text, toggle a MUI checkmark) is currently only possible if the target application itself has added its own custom ARexx commands for that, whichMUIREXXcan pass through but can't invent.Combined with #67 (no structural inspection of a MUI app's object tree at all), this means AmiPilot currently has no general-purpose way to act on an individual MUI widget the way it can for GadTools/top-level ReAction gadgets via
CLICK/TYPE/GETTEXT— only the app-level 7 commands, or whatever bespoke ARexx verbs a specific app happens to expose.Proposed scope (research first)
Depends heavily on what #67's research finds about safe external introspection. If a real object-identity mechanism is found (a cooperative port, or some other genuinely-documented external hook), the natural extension is: use that identity to synthesize real
input.deviceevents at the widget's own resolved screen coordinates — the same "real input, not BOOPSI method injection" principle this project already holds for every other locator tier (CLICK/TYPE/DRAGall use genuine synthesized input, neverDoMethod()poking into another process's live object). MUI's own windows ARE real Intuition windows underneath, so once a widget's real screen rectangle is known, acting on it isn't fundamentally different from acting on any other gadget — the hard part is entirely the identification half (#67), not the action half.If no safe external mechanism turns out to exist at all, the honest outcome may be documenting this as a permanent Tier 3/4-only limit (matching the project's own "honest limit, not a gap" precedent elsewhere) rather than a solvable gap — to be decided once #67's research lands, not assumed here.
Why file now
Filed per user request as part of a general post-1.0 planning pass, alongside #67 — this is the "management" half of "MUI inspection and management," deliberately scoped as dependent on #67's findings rather than speculatively designed ahead of that research.