Class ClientWindowVisibility
java.lang.Object
com.trevlar.menukit.window.ClientWindowVisibility
The one client-side gate that folds the engine Why this and not
VISIBILITY behavior into
the panel dispatch — the bridge between "set visibility through the window" and
"the renderer/input loop actually honors it."
Why this and not Panel.isVisible()
Panel.isVisible() (the panel's own field / showWhen supplier) is
called on BOTH sides — a created slot's server-side MKCSlot.isInert reads
it for sync. Engine VISIBILITY is CLIENT-tier and MUST be resolved on the client
only (the engine store is shared client+server in single-player, so resolving it
server-side would let a client hide stop server sync). So the engine resolution
lives here, called ONLY from the client render/input dispatch — never from
Panel.isVisible() or any server path.
Additive
Each method ANDs the existing visibility with the resolvedVisibilityRule.
With no VISIBILITY declared the rule resolves to VisibilityRule.VISIBLE,
so panelShown == panel.isVisible() — zero behavior change until a consumer
sets it. Panel-level VISIBILITY cascades to child elements via the engine's
owner-chain walk, so elementShown(Panel, PanelElement) also reflects a hidden parent panel.-
Method Summary
Modifier and TypeMethodDescriptionstatic booleanelementShown(Panel panel, PanelElement element) Client-side: should this element ofpaneldisplay/interact (own visibility AND engine VISIBILITY)?static booleanpanelOpaque(Panel panel) Client-side: is this panel interaction-opaque (eats clicks over its bounds)? The panel's ownisOpaque()AND the engineOPACITYkey.static booleanpanelShown(Panel panel) Client-side: should this panel display/interact this frame (own visibility AND engine VISIBILITY)?
-
Method Details