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
Even though we *usually* want these hotkeys for next/prev, sometimes we
don't, and the damage of forgetting to add them to a new pager is less
than the damage done if we forget to remove them and clobber something
important like the speedup/slowdown controls.
This was all done by search/replace, and should not affect
functionality.
Goals:
- be consistent with the figma terminology.
- consistently order:
"btn_{solid|outline|plain}_{dark|light}_{text|image|dropdown|back|etc}"
In case I have to revisit, here's the regex I used:
Btn::text_bg2\(([^)]*)\)*.build_def\(ctx, ([^()]*)\)
ctx.style().btn_primary_dark_text($1).hotkey($2).build_def(ctx)
And something like this for the "no hotkey" case
Btn::text_bg2\(([^)]*)\)*.build_def\(ctx, None\)
ctx.style().btn_primary_dark_text($1).build_def(ctx)
- Simple -- one OpenGL call and feeding to the awesome image crate
- Faster -- seemingly don't need the sleep() for whatever vsync problems
- Portable -- doesn't use the Linux scrot tool
- I can switch windows and wiggle the cursor with impunity while this runs
One disadvantage: screencaps in S3 are now slightly larger PNGs, because
for some reason, the image/gif feature is super slow, even in release
mode.
For now, this makes the process of screenshot diffing map changes
easier. But it also might help with producing raster tiles for Leaflet. #440
Also, had to regenerate lakeslice because of the previous change --
it had an old adaptive signal baked in.
widgetry, geom, and abstutil may wind up on crates.io in some form to
let other projects use widgetry. abstio has A/B Street-specific tricks
for reading data on native/web. Note widgetry still depends on abstio,
will figure out how to clean that up next.
data/ directory, because they're statically bundled; they're not
actually read from the filesystem. #253
Two SVGs get duplicated between widgetry and abst assets -- dont_walk
and arrow_drop_down.
struct. Whatever choices we make next about naming cities hierarchially
or not can be managed in just one place. #326
This is a pretty huge change, but the compiler gives reasonable
confidence it's correct. More bugs are likely to crop up in the next
step, when filenames start being namespaced by the city too.
recreated while we drag.
But there's still something wrong, because in the OSM viewer with a huge
list of buttons, scrolling is incredibly laggy while dragging, but not
when using the scroll wheel.
