to further organize them by purpose, but for the moment, two problems:
1) the city picker UI is getting way too crowded
2) on native, the initial download is up to 145MB
Removing:
- the 3 Aurora maps and Green Lake, added for the ARC workshop, but no
longer the most active of collaborations
- Ballard is now subsumed by central Seattle -- the only advantage would
be keeping its full scenario of walking and transit trips, but the
simulation is horribly gridlocked there anyway
- the Rainier Valley map, originally meant for an SNG traffic light
timing study
- the larger udistrict map
This one is the most complicated, and it's still not done, but it's not
any buggier than the ad-hoc implementation. I still need to figure out
how to merge the two worlds of waypoints and routes.
This one also required a large, but mechanical, refactor to lift
ToggleZoomed and the concept of unzoomed/zoomed from map_gui to
widgetry.
- arrays are now iterable directly
- switch to using BTree{Set,Map}::retain!
- a round of clippy
- regenerate scenarios and prebaked data; not sure why, but there's a
diff
The <dyn ...> syntax is gross, but I don't think there's a way to avoid
this without defining a differently named empty struct and putting the
static method on that
* root element id from Settings, respect element size
* Plumb assets root via settings
* adapt crates to new wasm api
* more FileLoader cleanup
* use tsc bin from node_modules
* avoid spurious unlink errors
GNU Make considers the src/*/wasm_pkg targets as intermediate build
files and attempted to `rm` them. We can stop that my marking them as
`.PRECIOUS`
https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
* `open` doesn't work on Linux
We could do something with xdg-open, but meh, not worth having platform
dependent logic for this.
* fix typo, clarify instructions
* make server compatible with older python install on linux
* revert change - we dont want to include music on web
the leading "-" means exclude a subdir of an included dir.
* better wrap of comments
* fix misfire in copy/pasted comment
* update docs
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.
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.
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.
