Malte Langkabel
abe8c8f448
The button leaves the header bar for the world, centered on the columns the next purchase unlocks and panning with them until it leaves the view. Those columns now take a lighter tint than the locked ground behind them, so the boundary between the two says how far one purchase reaches. Nothing in the code reported a scroll: the camera knew it had moved and told only the hover. A ViewScrolledEvent says it now, which is what a widget keeping a place in the world rather than on the screen needs. The panels want none of it -- they are placed against the screen and stay put as the world moves under them -- so the button is placed after their pass and never joins the rectangles they step around. Its face is two lines, "Expand" over the cost. That makes the cost a display of its own, so it carries the building-block tooltip the way every other item value does, on hover alone since the click buys the expansion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
16 lines
690 B
C++
16 lines
690 B
C++
#pragma once
|
|
|
|
#include "Event.h"
|
|
|
|
// Fired when the game world view's scroll position actually moved (REQ-UI-SCROLL), once
|
|
// per frame at most and not at all while the view sits still. Carries no payload: what it
|
|
// says is that the world-to-widget transform has changed, and whoever cares re-reads it.
|
|
//
|
|
// It exists for the widgets that keep a place in the world rather than on the screen --
|
|
// the asteroid expansion button, which stands on the columns it would buy
|
|
// (REQ-UI-EXPAND-BUTTON). The floating panels need nothing of the sort: they are placed
|
|
// against the screen and stay put as the view moves under them (ui/FloatingPanel.h).
|
|
class ViewScrolledEvent : public Event
|
|
{
|
|
};
|