ReadonlyanchorReadonlyclosableReadonlycontentA widget offered actions before the window itself sees them.
Set it to the list or field the window exists to show. Without it, every window
holding a widget has to override handleAction just to forward, which is noise at
best and, done by assigning over the method, a trap.
ReadonlydimsReadonlymodalReadonlyontrue once close() (or destroy()) has run. A closed window is spent: close() freed it
and its contents through Pixi, so the caller's this.someWindow reference must not be
written to any more. Guard with this rather than discovering it as a null-internal throw,
and drop the reference.
the space available inside the frame, which is what contents should lay out against
Announces the close and frees this window and its contents. Idempotent, so a second
close() (a pop() racing a cancel, a closeAll() after a manual close) is a no-op
rather than a second destroy. The instance is spent afterwards; see closed.
Removes all internal references and listeners as well as removes children from the display list.
Do not use a Container after calling destroy.
Optionaloptions: DestroyOptions
Options parameter. A boolean will act as if all options have been set to that value
Offered every action while this window is on top of the stack.
true if the window used it, which stops it going any further down
Offered a click that landed on the blocker, at x, y in this window's own coordinates
(its top-left corner is 0, 0). A click outside the window closes it when it is closable -
the pointer's answer to handleAction('cancel') - and a click on the window itself is
swallowed without closing, so its frame and empty body are never a dismiss button.
The blocker calls this for every click it takes, which is all a game usually needs; it is public because it is also the whole decision, and a headless test can ask it directly.
true when the click closed the window
positions the window in a viewport of the given size, per its anchor
called each frame while this window is the top of the stack
A panel with a frame, a title and a content area.
Windows are the interface: inventory, dialogue, character sheets, confirmations. They live in a
WindowStack, which decides which one has the keyboard.Contents go in
content, whose origin is already inset past the frame and padding, so a child placed at 0,0 sits correctly whatever the theme's border is.The window's own area is not clickable: the frame, the title and any part of the body with no widget in it let a click travel to whatever is underneath, so a window over a map is not by itself a wall.
blockeris the option that makes one, and it is what a window that has to be answered should set.Example