OpalChatHost
Owns a window's lazily built OPAL chat overlay and toggles it — the OPAL-surface window-feature (§ACW-2 slice 5).
| Inherits | QObject |
In the namespace octomy::opal::ui. Declared in src/libs/libopal/opal/ui/OpalChatHost.hpp.
Detailed description
Two copies of this job existed until 2026-10-08. NodeWindow::toggleChatOverlay() built the overlay from the node, and StandaloneOpalController::toggleChat() built it from the standalone OPAL context. Both create the overlay on first use, parent it to the window, configure it, give it the status context, and toggle it. They had diverged in what they forwarded back into the status context:
- Both forwarded the overlay's visibility, which drives the chat-open ring on the OPAL button.
- Only the node window forwarded
busyChangedand the two attention signals. Those were the 2026-06-11 fixes: a chat-driven run did not move the button to Working, and a permission request did not reach it. The standalone copy never received them.
This class is the union, so standalone construct now gets both fixes.
What the overlay is configured WITH stays the host's business, through a BackingProvider called once. The batch queue is asked for on every toggle, because a standalone shell publishes its queue after the feature exists.
It lives in libopal, beside the overlay, for the 09-10 rule: each piece where its dependents already are. libnode and libstandalone already reach libopal, so no library gains a dependency.
The button routing stays with each host. A first click on a never-set-up OPAL opens the setup wizard, and the node window and construct decide that differently today. This feature only builds and toggles the chat.