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.
mapper. Closes#482
The X buttons are confusingly no-ops on the web, and redundant on
native, since people know how to close a window.
Also fix up a few button styles in the smaller tools.
* 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
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)
Start refactoring a common UI pattern: recalculate some value only when
a key changes.
It's quite verbose right now for some widgetry States to determine if
the mouse is over a particular type of object, check if that object has
changed since the last time, and calculate something based on it. This
introduces a new helper for expressing the pattern a little more
clearly.
