starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Converge theme.tab.background=terminal with DECAC 2 #17980

New Issue
Closed
opened 2026-01-31 06:00:14 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 06:00:14 +00:00
Owner
Copy Link

Originally created by @DHowett on GitHub (Jul 20, 2022).

DECAC 2 lets you configure at runtime the tab background color by assigning it to any color alias index.

Setting the background to alias index 262 switches the tab background to the terminal background!

Originally created by @DHowett on GitHub (Jul 20, 2022). `DECAC 2` lets you configure _at runtime_ the tab background color by assigning it to any color alias index. Setting the background to alias index `262` switches the tab background to the terminal background!
claunia commented 2026-01-31 06:00:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 29, 2022):

Wait hol up I'm not sure what else there is to converge here.

layer
3 Runtime color (picker)
2 profile.tabColor, Color table index 261 (alias-able by `DECAC2`)
1 theme.tab.background
0 default color

All this seems to work as expected.

# set the tab to index 3 (yellow)
printf "\x1b[2;0;3,|"

# set the tab to "terminal bg"
printf "\x1b[2;0;3,|"

# change the terminal bg to #ff00ff
printf "\x1b]11;rgb:ff/00/ff\x1b\\"

# change index 264 to #00ffff (this won't do anything w/o DECAC(2;;264))
printf "\x1b]4;264;rgb:00/ff/ff\x1b\\"

Am I missing anything, or is this acceptable diligence/?

@zadjii-msft commented on GitHub (Aug 29, 2022): Wait hol up I'm not sure what else there is to converge here. <table> <th> layer <tr> <td>3 <td> Runtime color (picker) <tr> <td>2 <td> profile.tabColor, Color table index 261 (alias-able by `DECAC2`) <tr> <td>1 <td> theme.tab.background <tr> <td>0 <td> default color </table> All this seems to work as expected. ```bash # set the tab to index 3 (yellow) printf "\x1b[2;0;3,|" # set the tab to "terminal bg" printf "\x1b[2;0;3,|" # change the terminal bg to #ff00ff printf "\x1b]11;rgb:ff/00/ff\x1b\\" # change index 264 to #00ffff (this won't do anything w/o DECAC(2;;264)) printf "\x1b]4;264;rgb:00/ff/ff\x1b\\" ``` Am I missing anything, or is this acceptable diligence/?
claunia commented 2026-01-31 06:00:16 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 29, 2022):

Sort of. There's one critical, if not strictly internal, difference.

The background of the tab is supposed to be set in 264.
Eventually, somebody might be able to request or save/restore the value of color 264 (possibly, I know, we've been resistant). That's fine, and I think that we're ok on that front.

However, there's a unique state where the alias for FrameBackground has been reassigned to color index 262 (DEFAULT_BACKGROUND)

I don't believe setting the theme.tab.background reassigns the alias FrameBackground to point to the index DEFAULT_BACKGROUND. I'm concerned that this leaves multiple entrypoints to the same feature ("the tab background is the terminal background"), and when you have multiple entrypoints you risk having multiple outcomes.

@DHowett commented on GitHub (Aug 29, 2022): Sort of. There's one critical, if not strictly _internal_, difference. The background of the tab is supposed to be set in `264`. Eventually, somebody might be able to request or save/restore the value of color 264 (possibly, I know, we've been resistant). That's fine, and I think that we're ok on that front. However, there's a _unique state_ where the alias for `FrameBackground` has been reassigned to color index `262` (`DEFAULT_BACKGROUND`) I don't believe setting the `theme.tab.background` reassigns the alias `FrameBackground` to point to the index `DEFAULT_BACKGROUND`. I'm concerned that this leaves multiple entrypoints to the same feature ("the tab background is the terminal background"), and when you have multiple entrypoints you risk having multiple outcomes.
claunia commented 2026-01-31 06:00:16 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 29, 2022):

I'm going to try to document this with a diagram. Wish me, uh, luck?

@DHowett commented on GitHub (Aug 29, 2022): I'm going to try to document this with a diagram. Wish me, uh, luck?
claunia commented 2026-01-31 06:00:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 29, 2022):

glhf. Make sure to include setting the tab color with the color picker, cause I'm sure that wouldn't get down to the control layer either. Basically, seems to me like VT only ever has access to whatever is in layer 2 above. profile.tabColor can initialize it to a value, otherwise it's all internal to the control itself.

@zadjii-msft commented on GitHub (Aug 29, 2022): glhf. Make sure to include setting the tab color with the color picker, cause I'm sure that wouldn't get down to the control layer either. Basically, seems to me like VT only ever has access to whatever is in layer 2 above. `profile.tabColor` can initialize it to a value, otherwise it's all internal to the control itself.
claunia commented 2026-01-31 06:00:16 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 29, 2022):

It is almost too confusing to diagram, even!

I'm trying to show a table instead.

Layer Source Notes
0 default bg/fg Unchangeable
1 theme.tab.background from theme
2 profile.tabColor from profile
3 VT-assigned color defaults to INVALID_COLOR (index 264) promoted to nullopt
4 runtime color from picker defaults to nullopt

bottom-most valid value wins

VT only has access to layer 3 in this model. It can change it in TWO ways:

  1. reassigning alias FrameBackground to a new index (VT -> VT)
    1. One of the indices it can set it to is 262 (DEFAULT_BACKGROUND)
  2. changing the color 264 to any RGB value (VT -> any color at all)

Here's the problem, though. We have two implementations of tab.background = terminalBackground. One of them is in layer 1, up in App. The other one is in layer 3 bulletpoint 1.i.

They can easily drift out of sync:

  • the "default background" can be reassigned (change the DefaultBackground alias to an index that is not 262 (!)
  • the "frame background" can be reassigned to a different index
  • the application's view of what the Terminal's background is could be broken or wrong or whatever

I'm concerned about what is lost in the middle between "layer 1 pulls Terminal's background" and "layer 3 pushes Terminal's background." Why are there two entrypoints to the same outcome? What happens when their equivalence breaks down?

FOOTNOTE: I just realized one other instance where all of these features fail us: "cleared to new background color". \e[40m\e[H\e[2J makes the entire terminal black, except for the gutters and tab. Will that look weird in, say, vim?

@DHowett commented on GitHub (Aug 29, 2022): It is almost too confusing to diagram, even! I'm trying to show a table instead. |Layer|Source|Notes| |-|-|-| |0|default bg/fg|Unchangeable| |1|theme.tab.background|from theme |2|profile.tabColor|from profile |3|VT-assigned color|defaults to `INVALID_COLOR` (index 264) promoted to `nullopt` |4|runtime color from picker|defaults to `nullopt` _bottom-most valid value wins_ VT only has access to layer 3 in this model. It can change it in TWO ways: 1. reassigning alias `FrameBackground` to a new index (VT -> VT) 1. One of the _indices_ it can set it to is `262` (`DEFAULT_BACKGROUND`) 3. changing the color `264` to any RGB value (VT -> any color at all) Here's the problem, though. We have two implementations of `tab.background = terminalBackground`. One of them is in layer 1, up in App. The other one is in layer 3 bulletpoint 1.i. They can easily drift out of sync: * the "default background" can be reassigned (change the `DefaultBackground` alias to an index that is not `262` (!) * the "frame background" can be reassigned to a different index * the application's view of what the Terminal's background is could be broken or wrong or whatever I'm concerned about what is lost in the middle between "layer 1 _pulls_ Terminal's background" and "layer 3 _pushes_ Terminal's background." Why are there two entrypoints to the same outcome? What happens when their equivalence breaks down? **FOOTNOTE**: I just realized one other instance where _all_ of these features fail us: "cleared to new background color". `\e[40m\e[H\e[2J` makes the entire terminal black, except for the gutters and tab. Will that look weird in, say, _vim_?
claunia commented 2026-01-31 06:00:17 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 29, 2022):

(We discussed this. It's correct, but not worth worrying about.)

@DHowett commented on GitHub (Aug 29, 2022): (We discussed this. It's correct, but not worth worrying about.)
claunia commented 2026-01-31 06:00:17 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 29, 2022):

For the record, my expectation was that the VT alias would ideally reflect the tab.background = terminalBackground state when set via the UI. That way an application that changes those aliases would also be able to restore them correctly afterwards. That's not an issue now, since we can't query the state yet, but hopefully that will be supported one day.

@j4james commented on GitHub (Aug 29, 2022): For the record, my expectation was that the VT alias would ideally reflect the `tab.background = terminalBackground` state when set via the UI. That way an application that changes those aliases would also be able to restore them correctly afterwards. That's not an issue now, since we can't query the state yet, but hopefully that will be supported one day.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-CodeHealth Issue-Task Needs-Tag-Fix Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17980
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?