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.
remote trip goes between two locations off-map, specified just by a GPS
coordinate. The trips aren't simulated at all. They were originally
added to support Orestis's pandemic model, to handle transmission
off-map in shared buildings. This work has died off, there are no other
anticipated use cases for remote trips, and they complicate bigger
refactorings. #258
This also has the nice side effect of substantially reducing scenario
size -- huge_seattle from 177MB to 147MB. That unused metadata was
expensive!
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.
Nothing about it is specific to A/B Street, and other apps built with
widgetry could organize themselves as a stack of states. This is also a
first step towards sharing more common code between A/B Street and a
future OSM viewer.
Mostly mechanical change. Some more cleanup / documentation coming up
next.
* Initial storing of intersection delays
* Initial highlighting of delays on route
* Added label of delay
* Info overlay works
* Added supoprt for pedestrian delays (only intersection delay currently)
Bike also works, but is treated as a car, so the avg speed is flagged as very slow (Needs fix)
* Capitalised describe trip phase
Now uses min of (speed limit and vehicle max speed) for the maximum speed check
Added trip blocked time query
Lots of work on tool tips
Icons are broke
* Nearly complete, just fmting and a crash to fix
Color assertion?
* Fixed text font colour crash
Added new custom TextSpan size function
* Cargo +nightly fmt
* Cargo +nightly fmt
* Clion auto import formatting
Doesn't quite match the existing "changes"
* Fixing merge issues
* Fixing icon placement issues
* Requested changes (Part 1)
* Requested changes (Part 2)
Co-authored-by: Sam <a>
Co-authored-by: Dustin Carlino <dabreegster@gmail.com>
When I added web support in February, it was easier to get started with
stdweb, since it has the nice cargo web tool. However, stdweb is
unmaintained, winit is deprecating support for it, and the next steps
for web (downloading maps dynamically) have better support for web-sys.
With Alvin's guidance, I got
https://github.com/dabreegster/minimal_websys_winit_glow_demo working
first. This PR cuts A/B Street over too.
I tested abst and the widgetry demo in both native and web. The only
major regression from stdweb is the canvas placement and size. I
attempted some fixes, but at this point, I'll leave it as a smaller
followup instead.
* match unfork to fork
TBH I don't know of problem currently being caused by this, but it
seemed wrong to unfork without a matching fork.
* variable rename (no behavior change)
"c" was holdover from when panels were called composites
* resize container dims when window resizes
* make panel.top_level private
* Show/Hide scrollbars as window is resized
* alignment demo
* Fix scrollbar positioning
* separate out scrollbar work so we can profile it easier
* mem::replace is more concise than mem::swap
* fixup size of MaxPercent
* restore scroll position after redrawing scroll bars
* Fixed ui being able to select traffic light times that are shorter than the time it takes to walk across the crosswalk
* Fixing operands and renaming
* Fixed spinner out of bounds issue
Traffic light generation now, ensures that there is enough time to cross the crosswalk
And enforces the minimum time duration
* Cargo +nightly fmt
* Request fixes: https://github.com/dabreegster/abstreet/pull/346
Still need some things to clarify:
Spinner checks on increment/decrement
Calling enforce_minimum_crosswalk_time inside get_possible_policies, requires the removal or modification of the validation function
* Moved enforce_minimum_crosswalk_time inside get_possible_policies
Now runs stage_time_validation at the end of get_possible_policies and removes invalid policies
Could do the same with the validation function as well?
* Fixing import order
* Fixed ui being able to select traffic light times that are shorter than the time it takes to walk across the crosswalk
* Fixing operands and renaming
* Fixed spinner out of bounds issue
Traffic light generation now, ensures that there is enough time to cross the crosswalk
And enforces the minimum time duration
* Cargo +nightly fmt
* Request fixes: https://github.com/dabreegster/abstreet/pull/346
Still need some things to clarify:
Spinner checks on increment/decrement
Calling enforce_minimum_crosswalk_time inside get_possible_policies, requires the removal or modification of the validation function
* Moved enforce_minimum_crosswalk_time inside get_possible_policies
Now runs stage_time_validation at the end of get_possible_policies and removes invalid policies
Could do the same with the validation function as well?
* Fixing import order
* Moving stage validation inside validation function
Co-authored-by: Sam <a>
We were drawing "pop-up" style buttons in several places, using
copy/pasted logic - which was simple enough when using a unicode glyph.
But we want to use a different glyph which isn't in our font. Further,
using an svg like this gives us finer grained control around the layout
around the button "handle" than we could get with just space characters.
Just a few changes to make usvg not depend on Rustybuzz (which is still
in the middle of becoming a pure Rust library). It probably only works
with English fonts, but for the moment, it moves us forward.
