- when leaving edit mode, still return to actdev mode
- rename "bike network" layer to "cycling activity", to emphasize it
shows where cyclists have been going so far in the simulation and not
everything on the ground
- add tooltip with exact counts to the cycling activity layer, just like
throughput does
- add a "walking activity" button (throughput layer with filters
pre-applied)
attention to which intersection is being destroyed. Fixes#527 --
montlake and phinney both look correct now.
Regenerating everything. Actually, Phinney now runs, so adding a 4th
prebaked map!!! But Rainier regressed -- there's an issue with the
signal heuristics that's now a problem; I'll fix later.
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.)
