* reorder tabs: plan trip before adding lanes
This order of tasks should be more logical for most people.
* Copy tweaks
"trip" is better than "route" since you don't pick the route, only the
start/end points. The route is inferred based on the available roads.
* Smaller elevation plot
it was much wider than any other UI element, meaning the column
dramatically jumps sizes when switching to this tab.
* better align line-plot x-axis
* Avoid jittering UI while switching through tabs.
* fixup! Avoid jittering UI while switching through tabs.
* fixup! Copy tweaks
* fixup! reorder tabs: plan trip before adding lanes
* fixup! Copy tweaks
Also some drag-n-drop API tweaks:
- Don't require the caller to set `named()`
- Vertical card layout!
Some UX issues:
- deletion button alignment
- horizontal card alignment off
- sync up highlighting between map and cards
- selection state for a waypoint is meaningless
* 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
The GenericTable machinery lost a lot of it's utility now that we have
proper tabs. I've left a couple of free functions to be shared, and
inlined the remaining simple functionality.
TODO:
- tooltips (or is that just a responsibility of the button builder?)
- widgetry color scheme should use day-theme
- pick nice tab colors
- start applying!
- jump in time
- info panel
- "more data"
- fix width to match widest? Or maybe width modes?
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.
* 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
