The three widgets over the game world view each cached a rect handed to them by
MainWindow's resize, then re-placed themselves from it. But the build button bar
re-centers on a building unlock and the controls panel re-fits on a 50 ms timer,
neither of which goes through MainWindow, so the rects the others held went
stale -- and each widget re-implemented its own avoidance against them.
They now implement FloatingPanel and are placed in one ordered pass: the bar
takes what it wants, the controls panel steps around the bar, and the selection
panel keeps clear of both. A widget that changed size or visibility publishes
FloatingLayoutInvalidatedEvent instead of moving itself, because what it may
take depends on the widgets placed before it.
The rule they step around each other by is one function in lib, where it can be
tested without a display -- the only way any of this geometry gets automated
cover, screen capture of the world view being blank here.
The selection panel keeps its right edge and its vertical centering, but the
space it centers in is now what its own column has left free rather than the
full-width strip the bar used to reserve. It therefore sits lower than before
where the centered bar does not reach it, and it now clears the controls panel,
which it previously ignored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
The panel was anchored to the view's right edge and centered in the band above
the build button bar. Requiring it beside the selection instead splits its
placement inputs in two: the anchor rectangle and the side are frozen when the
selection starts, so the panel neither chases a scrolling view nor moves as the
selection grows, while its geometry is re-solved from them whenever its own size
changes.
Two neighbouring requirements described the old placement and had to follow:
the build bar's "the panel confines itself to the band above the bar", and the
controls panel's claim that the two panels sit on opposite sides of the view --
a selection in the lower left now puts them in the same corner, and keeping them
apart is the selection panel's job.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
The panel is sized to its card, so anything that changes the card's width drags
the panel with it. The status caption changes as a building works -- "producing"
is shorter than "missing input", which is shorter than "output full" -- and the
panel twitched every time it did. On a Smelter it also changed height, because a
narrower card wraps its item chips differently.
The pill now reserves room for the widest caption it can ever show, so the
header keeps one width whatever the state is. The captions were spelled out in
the switch that chose them, which left no way to ask for the set; they come from
one function now, and the set is what the reservation is built from.
Ship cards do the same with the behaviour names (REQ-UI-SHIP-BEHAVIOR), which
change just as often while a ship fights.
Miner card, sampled every tick for 900 ticks across two different-length
captions: one distinct width, one distinct height. The reservation is what does
it -- the same run without it sits at 138px, with it at 155px, the width of the
longest caption.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
Six things the player reported, five of them about where things sit and what is
listed:
- HP goes to the top of the runtime group, above everything else a card shows.
Only the HQ had it elsewhere; the ship and station cards already led with it.
- A construction site's progress moves out of the runtime group's place and
directly under the header, so how far along the site is reads before what it
is configured to become.
- The production bar moves between the input and output buffers, so a producing
building reads in the direction its materials flow: what goes in, what is
being made of it, what has come out. BufferSection held both buffer sections
and so could not be split around it; the two sections and the production
section are now the card's own, in that order.
- Locked items are left out of the buffers. An auto-recipe building's buffers
are sized over every recipe of its type, so a Smelter carried an input for
quartz -- which the player cannot mine yet -- and an output for the silicon it
would smelt into. Both are dropped now, as everywhere else that hides what is
not unlocked.
- An idle auto-recipe building lists what it handles rather than nothing. It has
no selected recipe to name, so a Reprocessing Plant between cycles showed no
output buffer at all. Its sections now list the unlocked items of every recipe
of its type -- the union its buffers were sized over -- without a per-cycle
denominator, since no one recipe is in force.
The sixth was the bars vanishing whenever the window lost focus, to a modal
dialog or to another application. They were filled with the palette's current
highlight, and the palette follows the window's focus: the inactive group's
highlight sits close enough to the card's background to read as gone. They ask
for the active group by name now.
Measured on a freshly built Smelter, which is the case that showed three of
these at once:
INPUT BUFFERS 0 Copper Ore | 0 Iron Ore | 0 Scrap
PRODUCTION idle
OUTPUT BUFFER 0/2 Copper Ingot | 0/2 Iron Ingot
Quartz and silicon filtered out, production between the buffers, and an idle
building still saying what it handles.
Requirements updated for the ordering, the locked-item rule and the idle
auto-recipe listing (REQ-UI-SELECTION-CARD, REQ-UI-SINGLE-SELECTION,
REQ-UI-PRODUCTION-PROGRESS, REQ-UI-HQ-PANEL).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
Selecting a building after a piece of debris left a scroll bar on a card that
had nothing to scroll.
Two faults, both found by driving the panel through the reported sequences and
printing what it measured itself to:
The bar was Qt's decision. Asked for ScrollBarAsNeeded, the scroll area shows a
bar the moment the card is larger than its viewport -- which is true while the
card is being measured, since measuring means giving it a width -- and does not
take it back when the range turns out to be empty. The panel already works out
whether the card fits its band and widens itself for the bar when it does not,
so it now sets the policy itself: AlwaysOn when it decided to scroll, AlwaysOff
when it did not. The previous commit's resize-to-cap made this visible;
removing that alone traded the phantom bar for a real one, because the card's
height depends on the width it is measured at.
The measurement was also a pass short. A card's width follows from the room it
is given and its height from that width, so refit() measures twice: once at the
cap to learn the width the card wants, once at that width for the height. The
whole thing then runs twice, because parts of a freshly built card report an
unstyled size until the style reaches them during the first round -- that gap
was leaving the panel a few pixels short of what the card turned out to need,
which is a scroll bar over a card that looks like it fits.
Measured before and after, HQ card, roomy band:
before panel=113x114 card wants 111x121 bar visible, range empty
after panel=113x123 card wants 111x121 no bar
And in a 90px band it still scrolls: panel=130x74, range 47, bar shown.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
Clicking something sometimes left the panel collapsed to its scroll bar, most
often for field entities.
Same cause as the controls panel's collapse in d7c6734: a widget created under
an already-visible parent starts hidden, and a layout counts a hidden item as
empty. rebuildContent() built the card, added it to the body layout and
measured immediately, so the body reported nothing but its own margins. A width
of nearly zero makes heightForWidth() on the wrapped labels enormous, that
overflows the band, and refit() then caps the height and widens by the scroll
bar -- leaving the panel exactly one scroll bar wide.
It could not recover on the next tick either, because a word-wrapped label's
size hint follows its current width: once narrow, it keeps reporting narrow and
tall. So refit() now measures the body at the width cap rather than at whatever
width the panel currently has, and invalidates the body layout before reading
it -- cards are built and discarded whole, so its cached hint otherwise
describes the card before this one.
Field entities hit it more often because a field selection publishes twice,
actors then debris, so one click rebuilds the card twice.
The same defect existed one level down, where parts are rebuilt while the card
is already visible: ItemChipRow::rebuildChips() and RecipeSummaryRow::rebuild()
now show what they create. Those were measuring the buffer section and the
recipe line as empty on every recipe change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
The doc's job is the invariants that are easy to break, and this change added
three of them that only existed as comments in the files enforcing them. The
one that matters most is the first: adding a shortcut straight to InputMapper's
switch is the natural next edit, it works, and it silently reintroduces exactly
the drift the action table was built to prevent.
Also records the two distinctions that cost the most to rediscover -- that an
action can be available in a context the panel does not advertise it in, and
that gesture state belongs to the shared mode rather than to an action, because
it decides what other bindings mean.
The ui target's contents were listed without the controls panel too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
REQ-UI-CONTROLS-PANEL said the content scrolls once it outgrows the space
available; only the height cap was implemented, so the surplus rows were simply
cut off. Silent row loss is the one failure this panel must not have, and it
was reachable: the Selection context runs to fifteen rows, and a panel that has
also had to rise above the build button bar can be left with less room than
that.
The rows move into a scroll area. The heading stays outside it, so it remains
visible and remains the collapse control whatever the rows are doing.
The size can no longer come from the panel's own layout -- a scroll area's hint
describes a viewport, not its contents -- so the heading and the rows are
measured directly and the chrome added. Verified against a forced rebuild and
an artificially cramped view:
roomy: heading 56x13 + rows 124x188 -> 142x223, no scrollbar
collapsed: -> 74x31, same bottom edge
cramped: wanted 223, band 124 -> 159x124, +17 for the scrollbar
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
It was confined to the band above the build button bar's strip, borrowing the
selection panel's rule. That rule exists because the selection panel is
full-height on the right, where the bar's strip is genuinely in the way. This
panel is short and in the corner, and the bar is centered and sized to its
buttons, so the corner is normally free -- reserving the whole strip pushed the
panel up for a collision that was not happening.
It now sits in the bottom-left corner and shares the view's bottom edge with
the bar, rising only when the panel's rectangle would actually intersect the
bar's, in which case it clears the bar's top by the usual margin and caps its
height at what is left. So it moves for a wide bar and a wide panel, and drops
back into the corner as soon as they no longer meet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The label was painted palette(bright-text), which is not a destructive color at
all: Qt has no such role, and bright-text is white by design, meant for text
over dark highlights. On this panel's light chrome it was white on grey.
The chips carry the warning now and the label keeps the ordinary text color, so
the row stays legible whatever the palette and only the binding is marked --
which is what REQ-UI-CONTROLS-CARD asked for in the first place, and what the
mockup shows. The red is a literal because no palette role means it, chosen to
read on a light and a dark background alike, and it is widget chrome, so like
the rest of this stylesheet it is deliberately not a visuals.toml color.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
A widget created under an already-visible parent starts hidden, and a layout
counts a hidden item as empty -- it adds nothing to the size hint. Nothing
showed the freshly built rows until the event loop next ran, long after the
panel had measured itself, so every rebuild measured an empty card.
That one fact explains both symptoms. Originally refit() read a stale cached
hint, which described the previous context and so drew the card one rebuild
behind. Invalidating that cache to fix it replaced a plausible wrong answer
with the true one for a card whose rows were all still hidden, which is why the
panel then collapsed to its heading on every mode change.
Measured on a forced rebuild, with the rows shown and without:
shown: rowItems=10 hidden=0 rowsHint=188 needed=140x221
hidden: rowItems=10 hidden=10 rowsHint=6 needed=72x39
39px being heading plus margins -- the collapsed card exactly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The previous fix went too far: it activated the panel's own layout before
resizing, which lays the heading and the rows out inside the geometry left over
from the previous context. The panel then took that stale frame as its answer
and collapsed to almost nothing whenever the mode changed.
Only the rows layout is activated now -- that part was right, and is what makes
freshly added rows visible and so measurable. The size comes from
layout()->totalSizeHint(), which says how big the content needs to be without
reference to how big the panel currently is; setGeometry re-runs the outer
layout afterwards on its own.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The card was drawn one rebuild behind: selecting something for the first time
sized it for the context before it, and the next selection sized it for that
one. refit() activated the panel's outer layout but never the rows layout
underneath it, so it read a size hint describing rows that were no longer
there, while the freshly added ones were not yet shown and so counted for
nothing. Both layouts are now invalidated and re-run innermost first, and the
rows are polished before being measured -- the badge chips carry border and
padding, which a label reports only once the stylesheet has reached it.
Also drops letter-spacing from the stylesheet. Qt has no such property and
warned once per widget it was applied to, which was most of the console. The
heading and the caption set it on their QFont, where it works.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
Ctrl+click works with an empty selection -- it picks the object under the
cursor much as a plain click does -- so leaving it out of the General card is
an omission rather than a claim the panel declines to make. The catalog already
implied that by listing it under Selection only; the accuracy rule now says so
outright, alongside the three omissions it already named.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The General card was the one that ran its context rows and the global ones
together as a flat list. That made it the exception a player has to notice: the
same six rows sit under a caption everywhere else, so leaving them uncaptioned
here asks the reader to work out that they are the same six.
Requirement wording corrected with it -- it claimed the always-available rows
were the General context's entire content, which was never true. General has
Select, Select area and Deconstruct mode of its own above the divider, exactly
like the other contexts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The panel decides nothing about what the controls are: it asks the same
resolver the key handling and the mouse dispatch ask, and renders each badge
from the binding that resolver matches. A chip cannot claim a key that does
nothing, and a label cannot describe a click that does something else, because
neither is written here.
Display text is the one part that is not shared -- lib/core says what is
available and what triggers it, ControlActionText.cpp says what it is called.
That split is why the table can stay free of UI strings and still be the single
source of the pairing.
It refreshes on a timer rather than by subscribing. Two things that change a
row -- a belt drag starting, the ghost crossing a transfer target -- happen on
mouse movement and publish nothing, and they must still show while the game is
paused, so there is no event and no tick to hang it on. Resolving is comparing
two vectors of enums, and the rebuild is skipped unless they differ.
Left edge, bottom-aligned in the same band the selection panel is confined to,
so it clears the build bar's strip and never meets the panel on the opposite
edge. Clicking the heading collapses it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The panel has to say what the left button does right now -- "Place" or "Apply
settings", "Select" or "Toggle deconstruct" -- and that answer lived in the
if-chain at the top of mousePressEvent, where the panel could not reach it.
So the chain becomes a switch on the resolved action, and the panel will read
the same resolver. Which branch runs is now decided in one place; what each
branch does is untouched, drag state machines and all.
Right-click gets the clearest win: cancel-the-drag versus leave-the-mode was
two nested conditions inspecting belt state, and is now the two actions the
table already distinguishes for the panel's sake.
Ctrl variants fall back to the plain gesture wherever nothing claims them,
which is what keeps Ctrl+click placing a building in builder mode and Ctrl+drag
deconstructing an area -- the modifier means something only where an action
says it does, rather than every handler re-deciding whether to ignore it.
Behaviour is unchanged. Full suite passes; the app runs clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The controls panel needs to say what each key does right now, and a panel that
keeps its own list of that is a list that goes stale. So the list moves into
lib/core/ControlAction.h: which actions exist, what each is bound to, and when
each does something. InputMapper stops deciding that and switches on the
resolved action instead, so the panel and the key handling cannot disagree
about what Q means -- there is only one place that says.
The table declares; it never performs. It holds no simulation access, fires no
events, and names nothing: display strings live in the ui target, which formats
the bindings this hands it, so a badge is rendered from the real binding rather
than typed beside it. What an action *does* stays exactly where it was.
ControlContext is the snapshot the rules read, which is what keeps this
testable without a world. Two of its facts come from BlueprintLibrary, which is
built after the world view and so arrives by setter; one comes from the new
hovered-transfer flag on BuildModeController, resolved once on mouse-move
through the same classifier the click and the ghost colour already use.
Behaviour is unchanged, deliberately. Ctrl still separates the chords and every
other modifier is still ignored, so Shift+A pans as before; matching modifiers
exactly would have silently swallowed those presses. Build hotkeys and F3/F4
stay outside the table -- the first are advertised on the build buttons and
already derive their badges from the handler's own table, the second are
development controls the panel must never offer.
The tests are the point of putting this in lib: every row's bindings must
resolve back to that row's action in that same context, which fails the moment
a shown row and its handler part ways.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
Adds REQ-UI-CONTROLS-PANEL/-CARD/-CONTENT/-ACCURACY: a left-anchored panel,
bottom-aligned within the same band the selection panel uses, collapsed and
expanded by clicking its header. Five control contexts derived from the build
mode and the selection, each with its own rows above a shared always-available
block.
The accuracy rule is the load-bearing part: a row must have the effect its
label names, or not be shown -- no greyed rows. That makes four rows
conditional on more than the context (C/Ctrl+C on the selection holding a
placeable building, the belt-drag row on the builder type, the RMB/Q split on a
drag being in progress, and Place vs Apply settings on the hovered ghost
resolving to a configuration transfer), and it makes the context-to-rows
mapping testable against the real bindings.
Also names the panel in the layout diagram, REQ-UI-WORLD-SIZE, and
REQ-UI-MODAL-DIM, and records in REQ-UI-HOTKEYS that the panel and the build
button badges display bindings rather than define them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG
The cards were assembled from plain labels carrying whole blocks of text.
Replace those with the widget vocabulary the requirements describe, so a part
means the same thing wherever it appears and a card is a list of parts rather
than a string builder.
The parts, all free of Simulation and GameConfig -- they take prepared values,
and the contents work out what those are:
- StatRow, BarRow, SectionBox: label/value line, captioned fill bar, captioned
group. The bar is one part for three things: construction progress,
production progress, and HP.
- ItemChip / ItemChipRow: buffered items as icon, count and sub-line
(REQ-UI-SINGLE-SELECTION). An input chip carries its per-cycle amount, an
output chip its count against the buffer capacity. The chips are rebuilt only
when the set of items changes, so a 30 Hz refresh moves numbers rather than
widgets.
- RecipeSummaryRow: inputs, arrow, outputs, cycle time (REQ-UI-RECIPE-SUMMARY),
which is now the panel's only display of the cycle time.
- CountRow, StatusPill, EmptyNote.
Behaviour that changed with them:
- The station card shows damage, range and fire rate as the requirement asks
(REQ-UI-STATION-STATS-PANEL) rather than the combined DPS it showed before.
- A ship's behaviour moves from a stats row into the card header
(REQ-UI-SHIP-BEHAVIOR). ShipStatsPanel keeps setBehavior for the balancing
tool's inspect window, which has no header to put it in.
- A construction site's card shows a progress bar and the "no buffers until
built" note (REQ-UI-SELECTION-CARD), and now also its recipe summary, since
that is configuration and a site carries it (REQ-BLD-SITE-CONFIG). Costing a
shipyard site's schematic needed computeShipyardRequiredMaterials to take a
stored configuration as well as a live building -- one overload, so the
module sum still exists once.
ShipStatsPanel is rebuilt on StatRow, BarRow and SectionBox, so the selection
card, the layout dialog's design preview and the balancing tool read alike.
Those three parts are compiled into the balancing target, which does not link
the ui library; keeping them sim-free is what makes that possible, and the
build enforces it.
Build clean, 541 tests pass, app and balancing tool both run with no Qt
warnings. Visual check pending.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
The panel rendered every selection out of a single pool of member widgets,
hidden and shown per branch, so each build path had to remember to hide the
other branches' widgets. That coupling produced the two defects fixed in
668ce0f, and the per-type detail the requirements now ask for would only add
more of it.
The pool is gone. SelectionPanel keeps the category arbitration, the float and
the hide-when-empty behaviour, and hosts exactly one SelectionContent at a
time; SelectionContentFactory picks which one from the selection alone. Each
card is one row of the catalog in REQ-UI-SELECTION-CONTENT and owns only its
own widgets.
The card structure (REQ-UI-SELECTION-CARD) lives in the base class: a header
with an identity symbol, a name and one right slot, then a configuration group
and a runtime group. A construction site keeps its configuration and has its
whole runtime group replaced by the construction progress, decided once there
rather than in every card (REQ-BLD-SITE-CONFIG).
Also implemented here:
- REQ-UI-SELECTION-STATUS: the header status dot, taken from the simulation's
own getProductionStatus() so the panel and the world's status light cannot
disagree.
- REQ-UI-SELECTION-AGGREGATE: belt-subsystem tiles and debris-only selections
collapse into one card with a count instead of a count summary.
- REQ-UI-HQ-PANEL: the HQ shows the global block stock and its HP, neither of
which is a buffer.
- BuildingIconCache, extracted from BuildButtonBar's file-local chip loading so
the card headers and the build buttons rasterize the same SVGs once.
FieldSelectionPanel is deleted: ships, stations, debris and the field count
summary are four more cards in the same factory, so the two-panel arbitration
collapses into one decision.
The card parts are still today's labels and buttons; the item chips, bars,
recipe summary and stat rows follow.
Build clean, 541 tests pass, app runs with no Qt warnings. Visual check
pending.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
The panel's content requirements described one panel that changes shape.
Restate them as one card structure plus a catalog of contents picked by
what is selected, so each selection has a named content and the parts
mean the same thing wherever they appear.
New:
- REQ-UI-SELECTION-CARD: header (symbol, name, one optional right slot),
configuration group, runtime group. A construction site replaces the
whole runtime group with a Construction bar and keeps its configuration
group, per REQ-BLD-SITE-CONFIG.
- REQ-UI-SELECTION-CONTENT: the catalog table.
- REQ-UI-SELECTION-STATUS: the header status dot, derived from
REQ-UI-STATUS-LIGHT's evaluation rather than a second definition.
- REQ-UI-SELECTION-AGGREGATE: a homogeneous multi-selection collapses into
one content with a count, but only where every part aggregates -- belt
subsystem tiles and debris. Splitters mixed with belts and several
production buildings fall back to the count summary.
- REQ-UI-RECIPE-SUMMARY: the inputs -> outputs, duration line, including a
shipyard's module contributions.
- REQ-UI-HQ-PANEL: global block stock plus HP, because blocks bypass the
buffers into the global stock (REQ-HQ-BELT-INPUT).
Rewritten: REQ-UI-SINGLE-SELECTION (item chips; an output chip's
denominator is now the buffer capacity, not the per-cycle amount),
REQ-UI-PRODUCTION-PROGRESS (bar, and no longer the cycle time's home),
REQ-UI-MULTI-SELECTION (count rows and a total cost row), REQ-UI-BELT-CLEAR,
REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL, REQ-UI-SHIP-BEHAVIOR
(moves into the header slot), REQ-UI-FIELD-MULTI-SELECTION and
REQ-UI-DEBRIS-PANEL (debris-only selections now aggregate).
Requirements only; no code changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
Implements REQ-UI-SELECTION-PANEL and the full-width REQ-UI-WORLD-SIZE /
REQ-UI-HEADER: MainWindow drops the 25% side column and its 75/25 math, so
the header bar and world view span the window, and the panel joins the
build button bar as a widget floating over the world.
The panel follows the bar's pattern -- an opaque sibling built after the
world view, so it sits above the vignettes, below the dim overlay, and
swallows the mouse events that would otherwise reach the world. It sizes
itself to its content within a band the window hands it (the world view
less the bar's strip, so the bar never has to move for it), right-aligned
and centered in that band, and scrolls once the content outgrows it. Its
content moved into a scroll area for that; the width is capped at 320 px
because the wrapped labels and the splitter filter lists have no natural
width of their own. With nothing selected the panel now hides entirely
rather than showing an empty box (REQ-UI-EMPTY-SELECTION).
Two defects that content sizing exposed: buildEmpty() left the selected
ids behind when the building vanished under the panel, which would have
held an empty panel on screen, and buildMulti() let a shipyard's layout
preview survive from a previous single selection (REQ-UI-MULTI-SELECTION).
Renames SelectedBuildingPanel to SelectionPanel throughout, matching the
requirements: the panel has long shown ships, stations, and debris too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
Remove the 25% side panel column: the header bar and game world view now
span the full window width, and the selection panel floats over the world
at its right edge, content-sized and shown only while something is
selected.
REQ-UI-PANEL-COLUMN is replaced by REQ-UI-SELECTION-PANEL, which defines
the panel's geometry, visibility, overlay, and input rules. The panel is
centered within the view height less its margins and the build button
bar's strip, so the bar never has to move out of its way. Rename the
"selected building panel" to "selection panel" throughout, since it has
long shown ships, stations, and debris too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
