* Import screen UI fixups
- even out the spacing a bit
- use underline style for "Alternate Instructions" web link
- left/right switch is more intuitive than right/left
- disambiguate label from toggle id
The GenericTable machinery lost a lot of it's utility now that we have
proper tabs. I've left a couple of free functions to be shared, and
inlined the remaining simple functionality.
TODO:
- tooltips (or is that just a responsibility of the button builder?)
- widgetry color scheme should use day-theme
- pick nice tab colors
- start applying!
- jump in time
- info panel
- "more data"
- fix width to match widest? Or maybe width modes?
- Increase day mode panel opacity to 95% to help text legibility
- Combine the time/speed panels, and remove the sunrise/sunset icons
- 4 mode colors matching actdev, also changing night mode residential
buildings
variable timing, but currently you have to remember to toggle it; the
two extra spinners get ignored otherwise. The new version is still
confusing, but I think it's an improvement.
call-sites. #253
To make some of these work, changed Label to store a String. Ultimately
it gets transformed into Text, so we need to allocate eventually.
- Always draw traffic signal stage numbers as white, even in day mode
- Always draw loading screen text as white, in any theme
- Double the scrollbar thickness from 4px to 8px (still way thinner than
the original design)
[rebuild] [release]
We had a lot of constants sprinkled around. This consolidates the
constants and packages the outline thickness and color into a tuple,
making for a (usually) cleaner callsite.
The main button API only allows re-writing one color of the image.
Since we need to rewrite multiple colors for the switch, I introduced a
`image_batch` for buttons which lets you do all kinds of manual
fanciness, and pass the result into the button API.
* cargo fmt
* rename ButtonStyle to ButtonTheme to avoid ambiguity
widgetry::styles::button:ButtonStyle -> ButtonTheme is a collection of
colors
vs. widgetry::widgets::button::ButtonStyle which is a per-state styling
(hover vs. disabled etc.)
* Collapse button styles to be theme specified (no visible changes).
Button colors are now determined by the color scheme, but for now all
schemes are hardcoded to use the same "night" button colors. Read on for
rationale...
Previously, which button colors to use (dark/light) was specified inline
while building the UI.
Eventually we want to live in a world where color scheme determines:
- panel colors
- button colors
- text colors
The theme could already choose panel colors easily enough, but because
the buttons and text were not determined by theme, choosing anything
other than a black or dark grey panel color makes the buttons and text
unreadable.
This PR tackled the themeable "button colors" portion, but all themes
continue to use the "night" colors for now, because using the actual
"day" colors would still make the text unreadable.
next up: themeable text!
The one intentional regression is within the pregame tutorial,
which has always been styled differently from the rest of the app. An
expeditious hack has caused the prev/next/continue buttons to lose their
visible hover state. I'll restore this upon completing the day theme
work.
* rethink rename... keep Style.ButtonStyle, rename button::ButtonStyle->ButtonStateStyle
* btn_solid_panel is the same as btn_solid
Button colors are now determined by the color scheme, but for now all
schemes are hardcoded to use the same "night" button colors. Read on for
rationale...
Previously, which button colors to use (dark/light) was specified inline
while building the UI.
Eventually we want to live in a world where color scheme determines:
- panel colors
- button colors
- text colors
The theme could already choose panel colors easily enough, but because
the buttons and text were not determined by theme, choosing anything
other than a black or dark grey panel color makes the buttons and text
unreadable.
This PR tackled the themeable "button colors" portion, but all themes
continue to use the "night" colors for now, because using the actual
"day" colors would still make the text unreadable.
next up: themeable text!
The one intentional regression is within the pregame tutorial,
which has always been styled differently from the rest of the app. An
expeditious hack has caused the prev/next/continue buttons to lose their
visible hover state. I'll restore this upon completing the day theme
work.
widgetry::styles::button:ButtonStyle -> ButtonTheme is a collection of
colors
vs. widgetry::widgets::button::ButtonStyle which is a per-state styling
(hover vs. disabled etc.)
It was my intention when introducing the cached vs uncached flavors that
we'd prefer the cached flavor for anything referencing bytes from a
file, like icons and UI glyphs, and that we'd only use the uncached
flavor for dynamic things like "face" generation.
The Xi'an map isn't being regularly used, and it has some issues
(boundary is too large, OSM is missing buildings in most of the area).
The zcool font enables Chinese characters to render, but costs 6MB in
the binary files, slowing down wasm loading time. Eventually, we can
support async loading fonts and passing them to widgetry when loading a
map requiring them. For now, cutting down wasm size is a bigger
priority.
game wasm from 18MB to 12MB. Not bad!
* introduce "pill" to be explicit about fully rounded, vs a "None" radius
* no-op transition to CornerRadii
* popup button to spec
* restore "fully rounded" layout behavior
* use plain light to better show highlight
* persistent split to spec (for day theme anyway)
* remove night-theme colors for speed panel
* fixup docs for pill
* CR: remove unnecessary `row`
* CR: remove outdated doc
* import order
