One toast overlay per window, kept below that window's chrome — the toast-host window-feature (§ACW-2 slice 4). More...
| Header: | #include <WindowToastHost> |
| Inherits: | QObject |
Notification-system §NS-6 asks for ONE toast host per top-level window. The host renders live toasts and the bell's history panel, so without one the bell toggles ToastManager's history flag with nothing listening.
Two copies of this job existed until 2026-10-08. NodeWindow created the overlay and anchored it below its header from its own event filter. StandaloneToastHost in libstandalone did the same for standalone windows from a content-top callback. The two had diverged. The standalone copy watched the HOST for Resize and Show, and the history toggle. The node-window copy watched the HEADER for Resize, Move, Show and Hide.
This class is the union. A header that hides must drop the inset to 0, and one that moves must carry the overlay with it. Neither is a Resize or a Show. The history view must open below the chrome, so a history toggle re-pulls the anchor too.
It lives in libwidgets, beside ToastHostOverlay, and not in the libwindow leaf. §ACW-7.4 records why the leaf cannot hold it: it needs the overlay, and libwindow does not reach libwidgets. Both hosts already reach libwidgets, so the feature needs no new library edge. That is the 09-10 ruling's own rule: each piece where its dependents already are.
The overlay itself is a Qt child of the host, so the host owns it.