WindowStackHost
The stack-host window-feature — §ACM D6's "stack-host mixin first".
| Inherits | QObject |
In the namespace octomy::window. Declared in src/libs/libwindow/window/WindowStackHost.hpp.
Detailed description
`NodeWindow` bundles six slices (§ACW-2) and the stack host is the one D6 names for extraction first: own the `ActivityStack`, place it in the host, give it a loader. That is a small, self-contained responsibility, and it is the same responsibility on both sides of the window axis — which is the whole reason it is a *feature* rather than lines inside a window.
Why this lives in a leaf lib
It was born in `libstandalone`, because §ACW-5 rule 2 forbids de-Node-ing the shared `-Werror` base in place and the node-free side was built first. Leaving it there would have meant pointing `libnode` at `libstandalone` so that `NodeWindow` could compose it — the coupling direction §AC retires. It now lives in `libwindow`, a leaf, on the pattern the owner set for `HeaderBar` and `libheader` (§ACW-7.1): a window-feature is a LIBRARY, not a framework slot, so every host takes it and no host is dragged in.
Two constructors, because placement belongs to the app
A host that has not built a stack asks this class for one. A host that already has a stack — the three node windows each promote a `widgetActivityStack` in their Qt Designer file — hands that one over instead.
§ACW-7 predicted the `NodeWindow` adoption would be "a deletion plus a member". It is not, and the reason is exactly this: the production node windows do not create their stack, they receive it from `.ui`. Inventing one here and deleting the promoted widget would edit four Designer files and all six derived windows in one move, which is the big-bang §ACW-5 rule 1 forbids. Adopting instead follows the owner's 09-10 ruling that **the app owns placement**, and lets each window convert on its own.
Note: §ACF-5 classification: **GLUE**. Host chrome assembled at build time, no lifecycle tier, no start/stop.
Note: This owns nothing that Qt does not already own. The stack is a child widget of the host, so the host destroys it; this class holds it by `QPointer` and reports null once that happens rather than handing out a dangling pointer.