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.
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)
