Add a XAML Theming spec

[zadjii-msft]

Summary of the Pull Request

This PR aims to outline my vision for what "XAML theming" might mean for the Windows Terminal in v2.0 and beyond. Now that #3789 has merged into master, I figured it was time to discuss what customizing other elements of the UI might look like as well. I've tried to include as many configurable elements of the UI as I could, referencing a ton of threads across the repo.

References

• Add comprehensive XAML "theming" functionality #3327 - the original theming thread
• Add support for setting a tab's color at runtime w/ context menu #3789 - Added support for the tab color picker

PR Checklist

• Specs Add comprehensive XAML "theming" functionality #3327
• I work here
• Is documentation

Detailed Description of the Pull Request / Additional comments

read the spec

TODO

• What style syntax should we have for theme members? element.property or elementProperty?
• This is the worst "Future Considerations" section I've ever written, so it might need some elaborating upon.
• For future considerations: Should we allow the "set tab color" action to set the tab color to the terminal background? What value would that be?
• How do we describe acrylic brushes? (I want the titlebar to be acrylic, 50% opacity, hue #ff00ff)? What about other potential materials? (vintage opacity?)
• Does the user have to manually specify the color for the titlebar, and the find dialog BG, and the command palette BG, and the .... or is there some way they can just set all at once?

[mdtauk]

Can there be support for the Accent Color brushes, so if I were to set my cursor or selction to my Accent Color, as it changes, that change will be reflected in Windows Terminal?

[zadjii-msft]

Can there be support for the Accent Color brushes, so if I were to set my cursor or selction to my Accent Color, as it changes, that change will be reflected in Windows Terminal?

So that might need to be it's own separate feature request. The cursor and the selection are drawn in DirectX down in TermControl, so they work differently than a lot of the things in this spec (which are all XAML elements).

For those, we'd need to accept something like "cursorColor": "accent". When we did that, CascadiaSettings would know that the string isn't a "#rrggbb" color, so it could look up the color when we're building the TerminalSettings to pass to the TermControl. However, after that point, if the user changes their accent color, that wouldn't be reflected dynamically in the Terminal, until the user manually refreshes their settings.

It's not a horrible idea, but probably something we should move to it's own thread for discussion, since I don't think it really fits in with a lot of the other things in this spec.

[mdtauk]

@zadjii-msft I just assumed the ability to specify Xaml resources, would include the app getting the Accent Color resource to use for the UI. I do see that with the console rendering being a separate system, passing any Xaml brushes through, would be a different issue.

[carlos-zamora]

I personally like the <element>.<property> representation more. I think it's more clear.

I'm probably in the minority here but I also love nested objects too. So, is there any consideration for...

<element>: 
{
  <property1>: <value1>,
  <property2>: <value2>
}

[zadjii-msft]

ew, I hate the nested objects so much that I didn't even put them in here 😝 My preference is definitely leaning towards element.property

[carlos-zamora]

Why key:SomeXamlKey as opposed to SomeXamlKey directly? We can just add valid enums. Then extensions can add more enums too. Maybe I'm just not understanding this part.

[zadjii-msft]

I'm missing the thread it was mentioned in now, but someone once suggested using "xaml:SomeXamlKey", and I really like that.

I think the "object" notation for looking up a key like this made it easier for us to say "this is an object, it's definitely not a string value". You're right though, these are just enums, so we can manually make sure that xaml: isn't used as a prefix for any of them.

[carlos-zamora]

This alone could get its own spec hahaha. I think following the active terminal instance is good for now. I'm thinking of some weird behaviors we could do that I think just isn't worth dealing with in v1:

Scenario	Behavior
vertical stack of panes	(1) inherit top color
horizontal stack of panes	(1) blend colors touching titlebar, (2) blend at pane separator

[carlos-zamora]

(Maybe worth mentioning in future considerations over v1) Should we consider a "defaults/list" structure like we did with profiles.defaults? For now, I'm guessing themes won't be too big, but over time that could become an issue (maybe)

[zadjii-msft]

See, I don't think we need a "defaults" for themes. People will only ever have one theme active at a time, for the entire window, so we don't really need to abstract that away.

The only reason I've got a whole list of themes is so:

• In the future, people can use extensions to install multiple themes, and just pick one they like
• People can iterate on ideas they like, and keep around old "themes" they create, even if they're using something else currently.

I think it's fine for each theme to be it's own atomic object, not composed of a (user theme defaults)+(changes to the user theme defaults)

[carlos-zamora]

I think that's where the defaults matter most (I'm guessing that's a conversation we'll have at some point too)

[zadjii-msft]

Hey something else we should consider - someone might want an acrylic titlebar, that's not the terminal BG color. This spec doesn't cover that case quite yet.

maybe "property": { "color": "#rrggbb", "opacity": .5 }?

[michael-hawker]

🦙 The Tab width behavior would fit in here as well (Compact, Equal, SizeToContent).

[zadjii-msft]

Oh, that's a good point. We'll need to come up with a way of handling what happens when the user has it set in both the theme and directly in the global settings - probably makes sense to just use the global value to override the theme value, right?

[michael-hawker]

@zadjii-msft or does it make sense to just move the setting itself into the theme (and have some default value if the theme doesn't provide one)? Or use the 'global' setting as the fallback value if the theme doesn't contain one?

[mdtauk]

I posted this in the UI Mega Thread, but was trying to trackdown the current issue handling Acrylic and Titlebars, so I am posting this here also...

Ignoring the Rounded Window Border (that will probably come to Windows with the new "Sun Valley" UI refresh) Here is how I would imagine a more immersive Terminal could look.

Edit:

Example with scrolled content

So the Titlebar uses the Console background - the Tabs blend in with an active tab standing out - and the Window Controls adapting their colour to contrast well.

[Shomnipotence]

As discussed in the following issue, there are too many ideas to achieve, including but not limited to the title bar, the current label, the hover label, the background color, and the different settings for the title bar. There is no doubt that it will eventually Import to build a theme system. My confusion lies in whether such a "grand" personalized setting system is needed for WindowsTerminal? I think I can sort out which parts can be prioritized (although Microsoft may not be interested in this).
＃1963，＃1337，＃3061 / ＃3062，＃2994

The Fluent Design System is constantly evolving, it is always in development, and less than 1/3 of the system applications adopt them, so Windows will never have a unified user interface, because the speed of applications using the latest design language will never keep up The speed of design updates. Moreover, before the release of WinUI3, I am afraid that all Win32 applications will not have much design changes-this is because Microsoft seems to be hesitant on whether to use XAML to build new applications.

Based on this, we discuss the design of Windows Terminal to minimize design changes and be compatible with existing designs as much as possible.

Windows Terminal allows you to set the background, but when the background uses acrylic, you will encounter an extremely ugly title bar (tab page bar), so the first consideration is to extend the acrylic effect to the title bar (tab page bar).

image

Here is a question, how to deal with the current label color, I personally think that the label color and the background of the current page can be consistent. If the current background color is a picture, the theme color will be automatically extracted from the picture.
If you do this, you only need to specify two colors:

Title bar color
Window background color (=label color)

There is another solution here, which I saw in the Files App, using a completely floating tab design.

In this case, the color of the title bar (tab page bar) is the same as the background color of the window. If a picture is used, the picture is tiled or full in the current window. Add a rounded rectangle background to the current label to show the selection, as shown in the figure.

I think these adjustments will not increase too much workload and are in harmony with Fluent Design. I want Microsoft to work as quickly as possible. I really look forward to Sun Valley, but so far, I think the biggest changes may be the "alarm and clock app" and the news flow of the taskbar.

[Stanzilla]

@Shomnipotence love your first solution, that is pretty much perfect.

[ghost]

There should be a tab.backgroundMode that sets when should the color be visible (all the time, hover+selection, selection).

[orcmid]

When there are two tabs, my eye goes to the prominent unselected tab. Determination of the foreground tab is too subtle in that case. If there were 3 tabs it might be more obvious about what tab is in the foreground. I suspect my eye can be trained, but that is worrisome.

Is there a way out of this that isn't complexifying?

Oh: If the rest of the tab bar (and other unselected tabs) were also the same as the shown unselected tab, I would have no doubt about which tab is in the foreground. Maybe distinguished with or without acryic.

[zadjii-msft]

I'm closing this for now. There's been no movement for a while, and we're not planning on landing this inside 2.0 anymore. Plus, #10509 definitely complicates the design a bit. Might as well not leave this stale PR open for so long. I'll come back to it in the future.

[PuruVJ]

Hi is this implemented yet? 😅

[zadjii-msft]

@PuruVJ Nope. This was a proposal for how we might want to do this in the future, but I've temporarily closed this out because

1. the team won't have enough time to give it a proper review anytime soon
2. it needs a little reworking for Mica (Add support for the Mica material #10509).

This is my pet project for 3.0, but alas, it didn't end up making the cut for 2.0.

[PuruVJ]

Thanks!! Makes sense