Conversation
https://stackoverflow.com/questions/64694722/changing-themeresources-dynamically-in-uwp That post looked SUPER promising. Problem is though, I CANNOT for the life of me get that to work. Like, I can't get anything to `{Binding Brush, Mode=TwoWay, Source={StaticResource TerminalBackground}}` to the `TerminalBackground` thing I made there. I thought that was so clever. I wanted an easy way to just change the value of a resource and have it update the Titlebar, but since the Titlebar isn't a child of the TerminalPage, and this binding thing didn't work, I think I'm at a dead end.
…dev/migrie/fhl/theming-2022-prototype
…ses are NOT optional
…to be sub-properties of the Theme
This comment was marked as resolved.
This comment was marked as resolved.
|
shhh bot, I was cleaning up pee all of last week |
carlos-zamora
left a comment
There was a problem hiding this comment.
YOLO. Best to get this in at the beginning of the cycle and start selfhosting this. :)
| } | ||
|
|
||
| const auto theme = _settings.GlobalSettings().CurrentTheme(); | ||
| auto requestedTheme{ theme.RequestedTheme() }; |
There was a problem hiding this comment.
| auto requestedTheme{ theme.RequestedTheme() }; | |
| const auto requestedTheme{ theme.RequestedTheme() }; |
I think?
|
|
||
| til::color bgColor = backgroundSolidBrush.Color(); | ||
|
|
||
| if (_settings.GlobalSettings().UseAcrylicInTabRow()) |
There was a problem hiding this comment.
Long-term, should we move useAcrylicInTabRow to be a part of the theme itself? If that's the case, (in a follow up) we should probably add deserialization logic to take this setting and write it as a part of themes (kinda like we did with the font object change).
There was a problem hiding this comment.
FWIW if we do that, we need some way to emit a completely new theme for the user, because they are not allowed to edit the system themes
| else if (theme.TabRow() && theme.TabRow().Background()) | ||
| { | ||
| const auto tabRowBg = theme.TabRow().Background(); | ||
| const auto terminalBrush = [this]() -> Media::Brush { |
There was a problem hiding this comment.
General question: when should we capture this vs &?
There was a problem hiding this comment.
typically I've found it best to try and capture as little as possible. There's a lot going on in this method, but the only thing we really need is this. If there were a bunch of other locals we needed in here too, then just go for &. That's not really based on any specific insight, just my own preference.
In anything that's gonna happen async, both this and & are bad.
## Summary of the Pull Request Adds support for the `tab.background` property to themes. This is also a ThemeColor, so it accepts, colors, `accent`, and `terminalBackground`, just like everything else. ## References * See #3327 *⚠️ targets #12992⚠️ ## PR Checklist * [x] Closes #702 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated - YUP ## Detailed Description of the Pull Request / Additional comments I apparently left behing an optional color in TerminalTab for theme colors some time ago, just never used it. Crazy, huh? ## Validation Steps Performed gifs below
Adds `tabRow.unfocusedBackground` to the theme properties.
When provided, the window will use this ThemeColor as the color of the tab row when the window is inactive.
When omitted, the window will fall back to the default tab row color, `{"key": "TabViewBackground"}` from our App.xaml.
* [ ] tests added.
* [x] Closes #4862
* [ ] Needs a whole pile of docs updates, which we'll do at the end here.
This actually helped validate #12992 quite a bit. I found a bunch of bugs concerning null colors, null objects. Json parsing is hard 😛
| rStr = std::string(&str.at(1), 2); | ||
| gStr = std::string(&str.at(3), 2); | ||
| bStr = std::string(&str.at(5), 2); | ||
| aStr = "ff"; |
There was a problem hiding this comment.
I don't love that we force a string parser to parse ff just to get 255... ;P
| ThemeColorType ColorType; | ||
|
|
||
| static Microsoft.Terminal.Core.Color ColorFromBrush(Windows.UI.Xaml.Media.Brush brush); | ||
| Windows.UI.Xaml.Media.Brush Evaluate(Windows.UI.Xaml.ResourceDictionary res, |
There was a problem hiding this comment.
XAML in the settings model -- this will cause trouble for a consumer like the shell extension in the future.
| }; | ||
|
|
||
| #undef THEME_SETTINGS_INITIALIZE | ||
| #undef THEME_SETTINGS_COPY |
There was a problem hiding this comment.
do we need to undef COPY_THEME...?
|
|
||
| std::string TypeDescription() const | ||
| { | ||
| return "ThemeColor (#rrggbb, #rgb, #aarrggbb, accent, terminalBackground)"; |
| return nullptr; | ||
| } | ||
| const auto string{ Detail::GetStringView(json) }; | ||
| if (string == "accent") |
There was a problem hiding this comment.
nit: prefer declaring these magic constant values in the class body and referencing them later
|
|
||
| if (_settings.GlobalSettings().UseAcrylicInTabRow()) | ||
| { | ||
| const til::color backgroundColor = backgroundSolidBrush.Color(); |
There was a problem hiding this comment.
You marked it as resolved... but the line of code is still here.
| _activated = activated; | ||
| _updateTabRowColors(); | ||
| } |
There was a problem hiding this comment.
ah, this guy snuck into the parent branch. It was used in the unfocused titlebar branch.
| return val; | ||
| } | ||
|
|
||
| static til::color _getAccentColorForTitlebar() |
There was a problem hiding this comment.
do we reload this when the accent color changes?
| \ | ||
| std::string TypeDescription() const \ | ||
| { \ | ||
| return "name (You should never see this)"; \ |
There was a problem hiding this comment.
lol this will actually say the word "name" since it's not in a macro-stringify expression
| { | ||
| auto result = winrt::make_self<Theme>(); | ||
|
|
||
| if (json.isString()) |
There was a problem hiding this comment.
we control the entire themes array, from its inception to its death. Who would put a string in it?
The main fix here is for the caption button colors. If you had a dark OS/app theme, and a light titlebar, we'd end up with light glyphs, so the caption buttons would be impossible to find. There's also a pile of nits from #12992 in here. Probably enough to close #13456 out, but I'll let Dustin be the judge. Filing today, to get in for 1.16 selfhost (@DHowett)
|
🎉 Handy links: |
Summary of the Pull Request
Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties:
These represent the most important asks of theming in the Terminal. The properties added in this PR are:
"#rrggbb"or"#aarrggbb""accent""terminalBackground"tabRow.background: accepts a ThemeColor (above)window.applicationTheme: accepts one of{"system", "light", "dark"}window.useMica: accepts a boolean, defaults to false.References
PR Checklist
Detailed Description of the Pull Request / Additional comments
--> GO READ #12530 <--
Seriously.
These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there.
They don't layer. You'll need to define your own themes.
Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0.
The sub objects have some gnarly macros to generate a lot of the serialization code for you.
TODOs
terminalBackground& the SUI result in something sensibleterminalBackground. One time, they didn't.printf "\x1b]11;rgb:ff/00/ff\x07"Validation Steps Performed
This is the blob I've been testing with:
Details