allow dynamic switching of color theme per-tab (did we regress ColorTool?) #5155

@NeilMacMullen commented on GitHub (Nov 24, 2019):

@j4james yes - agreed although again I think my suggestion goes further in that #1337 appears to be suggesting that the color of the tab-header should be changed whereas I'm suggesting that the entire contents of the window (background and font color/style) should be selectable.

@NeilMacMullen commented on GitHub (Nov 24, 2019): @j4james yes - agreed although again I think my suggestion goes further in that #1337 appears to be suggesting that the color of the tab-header should be changed whereas I'm suggesting that the entire contents of the window (background and font color/style) should be selectable.

claunia commented

@j4james commented on GitHub (Nov 24, 2019):

It's not like that proposal is inherently limited to tab color though. A number of the comments were suggesting changing the background color or the background image as part of the scheme. In fact the original proposal even mentioned extending the concept for other properties:

This concept could be expanded later to use other foreground and background identifiers such as images.

It's up to you, but if that issue can meet your needs with just minor enhancements (e.g. supporting additional properties, like font styles and colors) then I would have thought a comment there might be more productive.

@j4james commented on GitHub (Nov 24, 2019): It's not like that proposal is inherently limited to tab color though. A number of the comments were suggesting changing the background color or the background image as part of the scheme. In fact the original proposal even mentioned extending the concept for other properties: > This concept could be expanded later to use other foreground and background identifiers such as images. It's up to you, but if that issue can meet your needs with just minor enhancements (e.g. supporting additional properties, like font styles and colors) then I would have thought a comment there might be more productive.

claunia commented

@NeilMacMullen commented on GitHub (Nov 24, 2019):

I didn't see it as "that vs this" - I was just pointing out that the suggestions so far seemed to be less flexible and actually involved introducing more complication whereas reusing the theme mechanism seems to be a nice consolidation of existing mechanisms. :-) Anyway, I've added a comment to that item as you suggest.

@NeilMacMullen commented on GitHub (Nov 24, 2019): I didn't see it as "that vs this" - I was just pointing out that the suggestions so far seemed to be less flexible and actually involved introducing *more* complication whereas reusing the theme mechanism seems to be a nice consolidation of existing mechanisms. :-) Anyway, I've added a comment to that item as you suggest.

claunia commented

@egmontkob commented on GitHub (Nov 24, 2019):

I can't see a way to change the profile of a tab runtime. Is this really not possible?

It would be a convenient, user-friendly approach to allow switching between profiles, as done in many terminals (e.g. gnome-terminal).

Of course not every property of a profile could be changed. Things like commandline, startingDirectory would be ignored, but colors, font etc. would be adjusted.

@egmontkob commented on GitHub (Nov 24, 2019): I can't see a way to change the profile of a tab runtime. Is this really not possible? It would be a convenient, user-friendly approach to allow switching between profiles, as done in many terminals (e.g. gnome-terminal). Of course not every property of a profile could be changed. Things like commandline, startingDirectory would be ignored, but colors, font etc. would be adjusted.

claunia commented

@egmontkob commented on GitHub (Nov 24, 2019):

Another possibility is to add support for runtime alteration of the palette and default fg+bg colors, using the standard OSC 4, 10, 11 (and their +100 counterparts) escape sequences. This would give great flexibility to users, e.g. even picking a random background color from their shell startup files.

Technical note: In VTE + GNOME Terminal we figured out the best is if the OSC sequences have precedence over the UI / config file settings. That is, for each color slot, if its value is defined via OSC 4, 10, 11 then that one is used and the one in the settings is ignored. If a value hasn't been defined via OSC, or has been reset via OSC 104, 110, 111 then the value specified in the terminal emulator's settings is used. This way re-applying the same settings is an idempotent operation. (Previously the two sources were fighting with each other, both overwriting the value in the same slot. That way re-applying the user config (e.g. "altering" a color to the same value) would invalidate a previous OSC, which was bad.)

@egmontkob commented on GitHub (Nov 24, 2019): Another possibility is to add support for runtime alteration of the palette and default fg+bg colors, using the standard OSC 4, 10, 11 (and their +100 counterparts) escape sequences. This would give great flexibility to users, e.g. even picking a random background color from their shell startup files. Technical note: In VTE + GNOME Terminal we figured out the best is if the OSC sequences have precedence over the UI / config file settings. That is, for each color slot, if its value is defined via OSC 4, 10, 11 then that one is used and the one in the settings is ignored. If a value hasn't been defined via OSC, or has been reset via OSC 104, 110, 111 then the value specified in the terminal emulator's settings is used. This way re-applying the same settings is an idempotent operation. (Previously the two sources were fighting with each other, both overwriting the value in the same slot. That way re-applying the user config (e.g. "altering" a color to the same value) would invalidate a previous OSC, which was bad.)

claunia commented

@j4james commented on GitHub (Nov 24, 2019):

@egmontkob I'd encourage you to comment on #1337 to avoid splitting the discussion across multiple issues. The idea of altering settings via OSC has already been suggested there, although not in any great detail. And we do already support OSC 4, 10, and 11 - I think the +100 counterparts are in the backlog.

@j4james commented on GitHub (Nov 24, 2019): @egmontkob I'd encourage you to comment on #1337 to avoid splitting the discussion across multiple issues. The idea of altering settings via OSC has already been suggested there, although not in any great detail. And we do already support OSC 4, 10, and 11 - I think the +100 counterparts are in the backlog.

claunia commented

@zadjii-msft commented on GitHub (Nov 25, 2019):

Correct me if I'm wrong, but isn't this almost exactly the problem colortool is trying to solve? Setting the color palette at runtime? With colortool, you can simply do colortool -x "SpaceGray Eighties" to set the color scheme to "SpaceGray Eighties".

Sure, this doesn't use the schemes that are built into the settings of the Terminal. Maybe there's a way to have colortool parse colorschemes from the Terminal to expose them as possible schemes as well.

@zadjii-msft commented on GitHub (Nov 25, 2019): Correct me if I'm wrong, but isn't this almost exactly the problem [`colortool`](https://github.com/Microsoft/Terminal/tree/master/src/tools/ColorTool) is trying to solve? Setting the color palette at runtime? With colortool, you can simply do `colortool -x "SpaceGray Eighties"` to set the color scheme to ["SpaceGray Eighties"](https://github.com/mbadolato/iTerm2-Color-Schemes#spacegray-eighties). Sure, this doesn't use the schemes that are built into the settings of the Terminal. Maybe there's a way to have colortool parse colorschemes from the Terminal to expose them as possible schemes as well.

claunia commented

@NeilMacMullen commented on GitHub (Nov 25, 2019):

@zadjii-msft Hmm - that would be great it if worked but colortool -x just prints out the color table for me - it doesn't seem to affect the foreground/background colors of an subsequent text. (I tried in using both powershell and cmd tabs.)

@NeilMacMullen commented on GitHub (Nov 25, 2019): @zadjii-msft Hmm - that would be great it if worked but **colortool -x** just prints out the color table for me - it doesn't seem to affect the foreground/background colors of an subsequent text. (I tried in using both powershell and cmd tabs.)

claunia commented

@zadjii-msft commented on GitHub (Nov 25, 2019):

@NeilMacMullen Yea, that's expected. You need to actually pass a color scheme parameter to set it to.

Try colortool -x cmd-legacy or colortool -x solarized_dark

@zadjii-msft commented on GitHub (Nov 25, 2019): @NeilMacMullen Yea, that's expected. You need to actually pass a color scheme parameter to set it to. Try `colortool -x cmd-legacy` or `colortool -x solarized_dark`

claunia commented

@NeilMacMullen commented on GitHub (Nov 25, 2019):

@zadjii-msft I did pass a theme name otherwise I wouldn't even have got the color-table. ;-) Just to be clear using colortool -x "c64.itermcolors" prints out the color table but doesn't change any actual colors. I also tried using the json files from the windowsterminal folder of https://github.com/mbadolato/iTerm2-Color-Schemes but colortool doesn't even recognise those. Probably I'm doing something wrong but it's not immediately obvious. Windows version is sufficiently high to that it should work according to the documentation. Note that it DOES work in a standard powershell window - just not in Terminal :-) (That's actually a significant learning for me so thanks!)

@NeilMacMullen commented on GitHub (Nov 25, 2019): @zadjii-msft I did pass a theme name otherwise I wouldn't even have got the color-table. ;-) Just to be clear using **colortool -x "c64.itermcolors"** prints out the color table but doesn't change any actual colors. I also tried using the json files from the windowsterminal folder of https://github.com/mbadolato/iTerm2-Color-Schemes but colortool doesn't even recognise those. Probably I'm doing something wrong but it's not immediately obvious. Windows version is sufficiently high to that it should work according to the documentation. Note that it DOES work in a standard powershell window - just not in Terminal :-) (That's actually a significant learning for me so thanks!)

claunia commented

@j4james commented on GitHub (Nov 26, 2019):

FWIW, it mostly works for me. It just doesn't set the default/black background color correctly in Windows Terminal, but I thought that was a known WT issue - possibly #293.

@j4james commented on GitHub (Nov 26, 2019): FWIW, it mostly works for me. It just doesn't set the default/black background color correctly in Windows Terminal, but I thought that was a known WT issue - possibly #293.

claunia commented

@Jackbennett commented on GitHub (May 1, 2020):

If settings.json "profiles":{} had a sessions array or perhaps if "list": {"guid": <guid>} could also find the tabs by WT_SESSION variable GUID I was going to write powershell to add the colour directly to settings.json object for me.

If you added a sessions list of objects inside profiles that could also be a space Windows Terminal cleans up itself when you close the tab. Plus it wouldn't show up in the drop down GUI. Though closing a tab and recovering with ctrl+shift+t has a new session GUID, if you did this and didn't restore the ID you'll get new issues for saving per tab settings.

@Jackbennett commented on GitHub (May 1, 2020): If settings.json `"profiles":{}` had a sessions array or perhaps if `"list": {"guid": <guid>}` could also find the tabs by `WT_SESSION` variable GUID I was going to write powershell to add the colour directly to settings.json object for me. If you added a sessions list of objects inside `profiles` that could also be a space Windows Terminal cleans up itself when you close the tab. Plus it wouldn't show up in the drop down GUI. Though closing a tab and recovering with `ctrl+shift+t` has a new session GUID, if you did this and didn't restore the ID you'll get new issues for saving per tab settings.

claunia commented

@ccmattr commented on GitHub (Aug 31, 2021):

Some place I can edit a JSON file with the session GUIDs as a list would be perfect for me. Being able to use something simple as the basis of automation:

jq --arg s $WT_SESSION '.sessions[$s].tabColour = "Green"' settings.json

My (very simple) use case is I want to be able to dynamically change the tab colour when I access servers/DBs for a particular environment. Red for production, orange for staging etc. It makes it much clearer on how careful I need to be in each place. This is something i could do with Cygwin when I was using that daily.

@ccmattr commented on GitHub (Aug 31, 2021): Some place I can edit a JSON file with the session GUIDs as a list would be perfect for me. Being able to use something simple as the basis of automation: ``` jq --arg s $WT_SESSION '.sessions[$s].tabColour = "Green"' settings.json ``` My (very simple) use case is I want to be able to dynamically change the tab colour when I access servers/DBs for a particular environment. Red for production, orange for staging etc. It makes it much clearer on how careful I need to be in each place. This is something i could do with Cygwin when I was using that daily.

claunia commented

@zadjii-msft commented on GitHub (Aug 31, 2021):

@ccmattr You could much more easily add setTabColor actions to your actions, then use the command palette to pick those tab colors at runtime. Much much easier than trying to hack on top of the absolutely random WT_SESSION variable 😄

@zadjii-msft commented on GitHub (Aug 31, 2021): @ccmattr You could much more easily add [`setTabColor`](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#change-tab-color) actions to your `actions`, then use the [command palette](https://docs.microsoft.com/en-us/windows/terminal/command-palette) to pick those tab colors at runtime. Much much easier than trying to hack on top of the absolutely random `WT_SESSION` variable 😄

claunia commented

@zadjii-msft commented on GitHub (Aug 31, 2021):

Wait also, I don't think we need to leave this open any more?

Looks like colortool is working in the Terminal to me. We've also added (in the nearly 2 years since this was opened!) a setColorScheme action that's usable directly from the command palette (#https://github.com/microsoft/terminal/pull/9794)

Which is really the final form of what I dreamed of for colortool more that 5 years ago:

@zadjii-msft commented on GitHub (Aug 31, 2021): Wait also, I don't think we need to leave this open any more? ![image](https://user-images.githubusercontent.com/18356694/131534073-8ceb5588-a85c-41ea-8fe4-c13498df9f05.png) Looks like colortool is working in the Terminal to me. We've also added (in the nearly 2 years since this was opened!) a [`setColorScheme`](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#set-the-color-scheme) action that's usable directly from the command palette (#https://github.com/microsoft/terminal/pull/9794) ![img](https://user-images.githubusercontent.com/18356694/114557761-9a3cbd80-9c2f-11eb-987f-eb0c89ee1fa6.gif) Which is really the final form of what I dreamed of for colortool more that 5 years ago: ![image](https://user-images.githubusercontent.com/18356694/131534676-6ffd7dfd-95f2-47b9-bb0c-07179554825e.png)

claunia commented

@NeilMacMullen commented on GitHub (Aug 31, 2021):

Wowo - this is really nice! Great work :-)

@NeilMacMullen commented on GitHub (Aug 31, 2021): Wowo - this is really nice! Great work :-)

claunia commented

@ccmattr commented on GitHub (Aug 31, 2021):

@zadjii-msft The command palette is great, but it still requires me to remember to perform the actions when I perform the command. Is there a way to switch the colour scheme or tab colour via a script or command in the (e.g. WSL) shell?

I don't mind using a randomly generated ID if its a unique identifier to the tab session. It actually makes life significantly easier that its available already in the environment.

@ccmattr commented on GitHub (Aug 31, 2021): @zadjii-msft The command palette is great, but it still requires me to remember to perform the actions when I perform the command. Is there a way to switch the colour scheme or tab colour via a script or command in the (e.g. WSL) shell? I don't mind using a randomly generated ID if its a unique identifier to the tab session. It actually makes life significantly easier that its available already in the environment.

claunia commented

@zadjii-msft commented on GitHub (Aug 31, 2021):

@ccmattr No, there's no good VT sequence for setting the tab color yet. We designed the feature expecting that at some point we might add one. #6574 is kinda tracking that work (#1868 is its twin but for the tab icon instead).

We're pretty reluctant to encouraging anyone to try building on top of WT_SESSION. WT_PROFILE_ID will get you the GUID of the profile that's running in the Terminal, though that'll be the same across different tabs, so trying to use that to edit the tabColor of the current profile would just change multiple tabs all at once.

Honestly, I think the best option for your scenario would be different profiles for different scenarios, until #6574 lands.

@zadjii-msft commented on GitHub (Aug 31, 2021): @ccmattr No, there's no good VT sequence for setting the tab color yet. We designed the feature expecting that at some point we might add one. #6574 is kinda tracking that work (#1868 is its twin but for the tab _icon_ instead). We're pretty reluctant to encouraging anyone to try building on top of `WT_SESSION`. `WT_PROFILE_ID` will get you the GUID of the profile that's running in the Terminal, though that'll be the same across different tabs, so trying to use that to edit the `tabColor` of the current profile would just change multiple tabs all at once. Honestly, I think the best option for your scenario would be different profiles for different scenarios, until #6574 lands.

claunia commented

@ccmattr commented on GitHub (Sep 1, 2021):

Oh, awesome I'll switch to tracking #6574.

Is there a reason you are reluctant for anyone to use WT_SESSION and WT_PROFILE_ID, besides the randomness? It seems like they're really useful pieces of metadata info that could be used for some quite complex automations with the right API.

@ccmattr commented on GitHub (Sep 1, 2021): Oh, awesome I'll switch to tracking #6574. Is there a reason you are reluctant for anyone to use `WT_SESSION` and `WT_PROFILE_ID`, besides the randomness? It seems like they're really useful pieces of metadata info that could be used for some quite complex automations with the right API.

claunia commented