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.
I experimented on the Rainier Valley map, which recently started
gridlocking due to too many cars doing this, to tune the value. Got it
running again! The two other maps keep running, with some trips on
average getting a little slower.
* 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
Apparently we had two different ways of styling inner panels - compare
the info panels with the settings panel.
I intentionally consolidated to a single style, since that's where we
want to be but it made the info panel contrast to low. For now I'm
preferring to use the legacy "info-panel" style for inner panels
everywhere, meaning we'll temporarily lose the cute section backgrounds
in the day-theme settings panel, but retain legibility everywhere.
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.)
Added an extra step to classify service roads as running through a
parking lot, to prevent them from being treated as regular roads.
Had to fix up a few prebaked traffic signals. lakeslice falls back into
gridlock; will fix separately -- too much effort behind this change to
stop.
be more careful with nodes representing uber-turns. Even if that vehicle
type doesn't use an uber-turn, we still need to force the nodes to exist
and match up between input graphs.
Although this really only fixes gb/charleville_mezieres/secteur4, it
potentially affects all maps, because the node map changes. So
regenerate everything...
This reverts commit c9cef2ac8c.
I got confused by cyipt/actdev-ui#10, but the web version doesn't ship
data/input or data/player, so no need for the extra nesting.
