Update colors of our custom NewTab button to match MUX's TabView #6812
Conversation
ghost
added
Area-User Interface
|
I see that the |
That's only when the mouse is over it. The screenshot tool I used above doesn't include the mouse cursor. Here's an example with the mouse cursor:
It looks fine in actual usage.
This is the same as original screenshots, but also with AHCA::None:
Note again that the mouse is actually hovering over the center button, even though my screenshot tool didn't show it. |
|
Thanks so much for doing this. |
|
And, yes, your hunch is correct. We also knew relatively little about XAML when we started. 😄 |
DHowett
changed the title
|
@maftbot merge this in 1 minute |
Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812 (cherry picked from commit 4faa104)
|
🎉 Handy links: |
|
🎉This issue was addressed in #6812, which has now been successfully released as Handy links: |
ghost
mentioned this pull request
|
🎉 Handy links: |
|
🎉This issue was addressed in #6812, which has now been successfully released as Handy links: |
|
🎉 Handy links: |
|
🎉This issue was addressed in #6812, which has now been successfully released as Handy links: |
Update colors of our custom NewTab button to match MUX's TabView button
MUX has a NewTab button, but Terminal uses a homemade lookalike. The
version in Terminal doesn't use the same brush color resources as MUX's
button, so it looks very slightly different. This PR updates Terminal's
button to use the exact same colors that MUX uses. I literally copied
these brush names out of MUX source code.
References
This is the color version of the layout fix #6766
This is a prerequisite for fixing #5360
PR Checklist
Detailed Description of the Pull Request / Additional comments
The real reason that this matters is that once you flip on
ApplicationHighContrastAdjustment::None, the existing colors will notwork at all. The existing brushes are themed to black foreground on a
black background when High Contrast (HC) Black theme is enabled. The
only thing that's saving you is
ApplicationHighContrastAdjustment::Autois automatically backplatingthe glyphs on the buttons, which (by design) hides the fact that the
colors are poor. The backplates are those ugly squares inside the
buttons on the HC themes.
Before I can push a PR that disables automatic backplating (set
ApplicationHighContrastAdjustmenttoNone), we'll need to selectbetter brushes that work in HC mode. MUX has already selected brushes
that work great in all modes, so it just makes sense to use their
brushes.
If you want to hear some unsubstantiated speculation... read on. I
speculate that when this Terminal code was originally written, the MUX
code was incomplete, so it wasn't possible to copy all of MUX's brushes.
It also may not have been obvious that MUX uses an inconsistent mix of
TabViewButtonXxx and TabViewItemHeaderXxx brushes for this widget, since
the latter is hidden in some styling override code.
Validation Steps Performed
Screenshots! Everybody loves screenshots! These show the button in its
hover state (center button) and normal state (right button).
The one very subtle difference here is that, for non-HC themes, the
glyph's foreground has a bit more contrast when the button is in
hovered/pressed states. Again this slight difference hardly matters
now, but using the correct brushes will become critical when we try to
remove the HC backplating.