* 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
Also split out some common code to a plots module. Fan charts and
scatter plots are still hardcoded to use Time as the X-axis and
duplicate lots of code, but this is a step towards refactoring
everything.
* Import screen UI fixups
- even out the spacing a bit
- use underline style for "Alternate Instructions" web link
- left/right switch is more intuitive than right/left
- disambiguate label from toggle id
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?
- Increase day mode panel opacity to 95% to help text legibility
- Combine the time/speed panels, and remove the sunrise/sunset icons
- 4 mode colors matching actdev, also changing night mode residential
buildings
variable timing, but currently you have to remember to toggle it; the
two extra spinners get ignored otherwise. The new version is still
confusing, but I think it's an improvement.
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.
- Always draw traffic signal stage numbers as white, even in day mode
- Always draw loading screen text as white, in any theme
- Double the scrollbar thickness from 4px to 8px (still way thinner than
the original design)
[rebuild] [release]
We had a lot of constants sprinkled around. This consolidates the
constants and packages the outline thickness and color into a tuple,
making for a (usually) cleaner callsite.
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.
