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

Feature Request: allow to pick the color of the tabs #4178

New Issue
Closed
opened 2026-01-30 23:40:13 +00:00 by claunia · 30 comments
claunia commented 2026-01-30 23:40:13 +00:00
Owner
Copy Link

Originally created by @gbaychev on GitHub (Sep 30, 2019).

Description of the new feature/enhancement

Hello everybody, I think it is a good idea to give the user the possibility to pick colors of the currently opened tabs. The use case is the following: I use command line git and I work on multiple projects in parallel. This means that I have multiple tabs, each for a different git repo.

I want to be able to differentiate at a quick glance which tab is for which folder/repo/project/whatever and a tab color (if I can set one) is very strong visual cue.

For example, Visual Studio Code has the Peacock extension, which gives you the possibility to color your editors differently, according to the project you are currently working on.

Visual Studio has similarly SolutionColor

Proposed technical implementation details (optional)

What I imagine is that, if the user does a right click on a tab, a menu is shown, with an element called 'Choose a color' or something similar. When the element is clicked, a simple color picker (ala OneNote) is displayed:

color_picker

Then there are two possibilities:

  • the simple one is that the tabs are colored in the selected color and after the application is closed, this information is lost
  • the more complex one: the application takes note of the current working dir of the shell, belonging to the tab and as long as the shell remains in this folder or a subfolder, the tab is colored in the chosen color. If this is even possible, one can store the folder/chosen color list in the settings and restore the tab colors, after the application is restarted.

If this is interesting to you, I would like to try to implement it. What are your thoughts?

Regards

Originally created by @gbaychev on GitHub (Sep 30, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement Hello everybody, I think it is a good idea to give the user the possibility to pick colors of the currently opened tabs. The use case is the following: I use command line git and I work on multiple projects in parallel. This means that I have multiple tabs, each for a different git repo. I want to be able to differentiate at a quick glance which tab is for which folder/repo/project/whatever and a tab color (if I can set one) is very strong visual cue. For example, Visual Studio Code has the [Peacock extension](https://marketplace.visualstudio.com/items?itemName=johnpapa.vscode-peacock), which gives you the possibility to color your editors differently, according to the project you are currently working on. Visual Studio has similarly [SolutionColor](https://marketplace.visualstudio.com/items?itemName=Wumpf.SolutionColor) # Proposed technical implementation details (optional) What I imagine is that, if the user does a right click on a tab, a menu is shown, with an element called 'Choose a color' or something similar. When the element is clicked, a simple color picker (ala OneNote) is displayed: ![color_picker](https://user-images.githubusercontent.com/3358056/65906648-36db9980-e3c3-11e9-8496-8012f68d1117.png) Then there are two possibilities: - the simple one is that the tabs are colored in the selected color and after the application is closed, this information is lost - the more complex one: the application takes note of the current working dir of the shell, belonging to the tab and as long as the shell remains in this folder or a subfolder, the tab is colored in the chosen color. If this is even possible, one can store the folder/chosen color list in the settings and restore the tab colors, after the application is restarted. If this is interesting to you, I would like to try to implement it. What are your thoughts? Regards
claunia commented 2026-01-30 23:40:14 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (Sep 30, 2019):

If the Tabs are to be given Context Menus #1912 with Close, Rename options etc - this could be a Sub Menu Flyout

@mdtauk commented on GitHub (Sep 30, 2019): If the Tabs are to be given Context Menus #1912 with **Close**, **Rename** options etc - this could be a Sub Menu Flyout
claunia commented 2026-01-30 23:40:14 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 30, 2019):

I really like this idea. I'd note that doing this based on the working directory of the child process might just be impossible, but just setting the color isn't a bad idea.

I'm also wary of doing anything to write the settings file currently, so I'd definitely lean towards an initial implementation only setting the color at runtime, and not persisting it. Sure, we'll be back in the business of writing the settings file when we have a proper Settings UI (#1564), but lets just avoid that for now. Maybe later we could add an optional "make this change temporary" checkbox that lets the user persist the changes.

I'd also add that personally, I'd reject any PR if it didn't also include a "choose my own color" option. I hate when I have to pick from an application's palette of colors. It's 2019. There are 16.7 million colors to chose from, not 16. 16 colors can be a good suggestion, but sometimes I just want more than 3 blues 😝

Related:

  • #1079 - this deals with setting a (temporary) title at runtime through a similar UI
  • #702 - another request for styling the tab, though not at runtime

I do feel however that this might be something that's better suited for an inevitable extensibility model. Maybe we could incorporate it directly temporarily, then later move to an external extension. It certainly seems to hit on a few good extension requirements:

  • adding an element (the menu flyout item) to an existing UI element (the tab right-click MenuFlyout)
  • Changing the styling of an existing UI element (changing the BG of the TabViewItem)
  • displaying its own UI (the color picker)
  • possibly writing a setting? We don't really have a design for Theme settings quite yet, but this seems to fall into that category.

It would certainly be a good case study IMO. I'm going to tag it up for that purpose.

@zadjii-msft commented on GitHub (Sep 30, 2019): I really like this idea. I'd note that doing this based on the working directory of the child process might just be impossible, but just setting the color isn't a bad idea. I'm also wary of doing anything to write the settings file currently, so I'd definitely lean towards an initial implementation only setting the color at runtime, and not persisting it. Sure, we'll be back in the business of writing the settings file when we have a proper Settings UI (#1564), but lets just avoid that for now. Maybe later we could add an optional "make this change temporary" checkbox that lets the user persist the changes. I'd also add that _personally_, I'd reject any PR if it didn't also include a "choose my own color" option. I **hate** when I have to pick from an application's palette of colors. It's 2019. There are 16.7 million colors to chose from, not 16. 16 colors can be a good suggestion, but sometimes I just want more than 3 blues 😝 Related: * #1079 - this deals with setting a (temporary) title at runtime through a similar UI * #702 - another request for styling the tab, though not at runtime I do feel however that this might be something that's better suited for an inevitable extensibility model. Maybe we could incorporate it directly _temporarily_, then later move to an external extension. It certainly seems to hit on a few good extension requirements: * adding an element (the menu flyout item) to an existing UI element (the tab right-click MenuFlyout) * Changing the styling of an existing UI element (changing the BG of the TabViewItem) * displaying its own UI (the color picker) * possibly writing a setting? We don't really have a design for Theme settings quite yet, but this seems to fall into that category. It would certainly be a good case study IMO. I'm going to tag it up for that purpose.
claunia commented 2026-01-30 23:40:15 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Sep 30, 2019):

This is largely similar to #1337, which had another issue about right-clicking a tab to set its color duped into it, but it puzzlingly has no mention of that functionality.

@DHowett-MSFT commented on GitHub (Sep 30, 2019): This is largely similar to #1337, which had another issue about right-clicking a tab to set its color duped into it, but it puzzlingly has no mention of that functionality.
claunia commented 2026-01-30 23:40:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 30, 2019):

Yea I see that. Considering we left "add a setting to change the tab title" and "add a menu to change the tab title at runtime" as separate issues, I felt this could stand on its own as well.

@zadjii-msft commented on GitHub (Sep 30, 2019): Yea I see that. Considering we left "add a setting to change the tab title" and "add a menu to change the tab title at runtime" as separate issues, I felt this could stand on its own as well.
claunia commented 2026-01-30 23:40:15 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Oct 1, 2019):

Also slightly related: #1868.

@egmontkob commented on GitHub (Oct 1, 2019): Also slightly related: #1868.
claunia commented 2026-01-30 23:40:15 +00:00
Author
Owner
Copy Link

@gbaychev commented on GitHub (Oct 1, 2019):

Hello folks,
thank you very much for the comments.

@zadjii-msft Yes, I'm going to implement the simple scenario. I haven't looked at the code, but I assumed that is quite likely that the terminal is not aware where or what the shell, which it is hosting, is doing. No settings involved, you can simply set the color for the session and that is.
Considering that you've mentioned

an inevitable extensibility model

I take it that you currently do not have a plugin or similar system in place, correct?

Also, agreed - there must be an option to pick your own color (maybe you can talk to the OneNote guys about this - this is where the screenshot comes from 😉 )

@DHowett-MSFT I searched for
is:issue is:open tab colors
and not for
is:issue is:open tab color
This is why I did not see #1337, sorry 🤦‍♂ .

I'm going to try to drop you a PR next week, it is Hactoberfest and all :)

Regards

@gbaychev commented on GitHub (Oct 1, 2019): Hello folks, thank you very much for the comments. @zadjii-msft Yes, I'm going to implement the simple scenario. I haven't looked at the code, but I assumed that is quite likely that the terminal is not aware where or what the shell, which it is hosting, is doing. No settings involved, you can simply set the color for the session and that is. Considering that you've mentioned > an inevitable extensibility model I take it that you currently do not have a plugin or similar system in place, correct? Also, agreed - there must be an option to pick your own color (maybe you can talk to the OneNote guys about this - this is where the screenshot comes from 😉 ) @DHowett-MSFT I searched for `is:issue is:open tab colors` and not for `is:issue is:open tab color` This is why I did not see #1337, sorry 🤦‍♂ . I'm going to try to drop you a PR next week, it is Hactoberfest and all :) Regards
claunia commented 2026-01-30 23:40:15 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (Oct 1, 2019):

WinUI includes a colour picking control, you would have to handle opening a dialog with the control in for any custom colour.

@mdtauk commented on GitHub (Oct 1, 2019): WinUI includes a colour picking control, you would have to handle opening a dialog with the control in for any custom colour.
claunia commented 2026-01-30 23:40:16 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Oct 2, 2019):

Just wondering: Do you guys think it makes sense for the 16 initially offered colors to be the configured palette colors of the given terminal?

This is probably by far not the best set of 16 colors per se, but gives a more consistent overall appearance, and are colors that users can mentally connect to existing contexts within the terminal. They would also auto-follow the user's preference regarding the color palette, including more exotic ones such as Solarized, on a per-tab basis.

To second zadjii, I agree that there should be a way to pick any of the 16M colors. Probably even offer a shorthand for several LRU ones.

@egmontkob commented on GitHub (Oct 2, 2019): Just wondering: Do you guys think it makes sense for the 16 initially offered colors to be the configured palette colors of the given terminal? This is probably by far not the best set of 16 colors per se, but gives a more consistent overall appearance, and are colors that users can mentally connect to existing contexts within the terminal. They would also auto-follow the user's preference regarding the color palette, including more exotic ones such as Solarized, on a per-tab basis. To second zadjii, I agree that there should be a way to pick any of the 16M colors. Probably even offer a shorthand for several LRU ones.
claunia commented 2026-01-30 23:40:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 2, 2019):

@egmontkob That's certainly where I'd start with this feature, though I'm not really qualified to be a UX designer 😜

@zadjii-msft commented on GitHub (Oct 2, 2019): @egmontkob That's certainly where I'd start with this feature, though I'm not really qualified to be a UX designer 😜
claunia commented 2026-01-30 23:40:16 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Oct 2, 2019):

Me neither 😜

@egmontkob commented on GitHub (Oct 2, 2019): Me neither :stuck_out_tongue_winking_eye:
claunia commented 2026-01-30 23:40:16 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (Oct 2, 2019):

@egmontkob I think eventually you want the Tab colour to be stored in the settings, but they want to implement it first without making it persist.

I don't think you need to store more than the one colour, so adding 16 colours to every profile's settings, is probably overkill, and not useful

@mdtauk commented on GitHub (Oct 2, 2019): @egmontkob I think eventually you want the Tab colour to be stored in the settings, but they want to implement it first without making it persist. I don't think you need to store more than the one colour, so adding 16 colours to every profile's settings, is probably overkill, and not useful
claunia commented 2026-01-30 23:40:16 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Oct 2, 2019):

I think eventually you want the Tab colour to be stored in the settings, but they want to implement it first without making it persist.

It's unclear to me how this could be stored in settings. As far as I understand, the whole point is to make individual terminals (that otherwise probably use the same profile) more easy to distinguish via a quick user action. The settings define the look and behavior of profiles, not individual terminals of the same profile.

adding 16 colours to every profile's settings, is probably overkill, and not useful

That's not what I meant; I meant to offer the 16 colors that are already defined for a profile as its basic colors (either explicitly, or by using the defaults). I agree that defining 16 colors purely for a tabcolor chooser would be an overkill.

@egmontkob commented on GitHub (Oct 2, 2019): > I think eventually you want the Tab colour to be stored in the settings, but they want to implement it first without making it persist. It's unclear to me how this could be stored in settings. As far as I understand, the whole point is to make individual terminals (that otherwise probably use the same profile) more easy to distinguish via a quick user action. The settings define the look and behavior of profiles, not individual terminals of the same profile. > adding 16 colours to every profile's settings, is probably overkill, and not useful That's not what I meant; I meant to offer the 16 colors that are already defined for a profile as its basic colors (either explicitly, or by using the defaults). I agree that defining 16 colors purely for a tabcolor chooser would be an overkill.
claunia commented 2026-01-30 23:40:17 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (Oct 2, 2019):

@egmontkob Ok I get you know. You want the default colours offered to be pulled from the profile.

@mdtauk commented on GitHub (Oct 2, 2019): @egmontkob Ok I get you know. You want the default colours offered to be pulled from the profile.
claunia commented 2026-01-30 23:40:17 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Oct 2, 2019):

I don't want it, I threw this in as an idea :)

@egmontkob commented on GitHub (Oct 2, 2019): I don't _want_ it, I threw this in as an idea :)
claunia commented 2026-01-30 23:40:17 +00:00
Author
Owner
Copy Link

@gbaychev commented on GitHub (Oct 14, 2019):

Hi everybody,
so I'm working on this at a glacial pace, but I've ran into a problem. I've created a menu flyout and I set it as as a context flyout of the tab as follows:
_tabViewItem.ContextFlyout(tabContextFlyout)

If I try to right click the tab or click the split button to choose a tab profile, if I'm debugging, I'm getting the following exception:

Exception thrown at 0x00007FFADCEDA839 (KernelBase.dll) in WindowsTerminal.exe: WinRT originate error - 0x80070490 : 'Element not found.'.

Exception thrown at 0x00007FFADCEDA839 in WindowsTerminal.exe: Microsoft C++ exception: winrt::hresult_error at memory location 0x000000ED0594B380.

But if I try to run the program without the debugger, I can see the menu flyouts displayed properly. Do you have any tips whether or not this exceptions could be avoided, when I start the program from within Visual Studio?

Overall I have terrible experience building and running the project :(

@gbaychev commented on GitHub (Oct 14, 2019): Hi everybody, so I'm working on this at a glacial pace, but I've ran into a problem. I've created a menu flyout and I set it as as a context flyout of the tab as follows: `_tabViewItem.ContextFlyout(tabContextFlyout)` If I try to right click the tab or click the split button to choose a tab profile, if I'm debugging, I'm getting the following exception: `Exception thrown at 0x00007FFADCEDA839 (KernelBase.dll) in WindowsTerminal.exe: WinRT originate error - 0x80070490 : 'Element not found.'.` `Exception thrown at 0x00007FFADCEDA839 in WindowsTerminal.exe: Microsoft C++ exception: winrt::hresult_error at memory location 0x000000ED0594B380.` But if I try to run the program without the debugger, I can see the menu flyouts displayed properly. Do you have any tips whether or not this exceptions could be avoided, when I start the program from within Visual Studio? Overall I have terrible experience building and running the project :(
claunia commented 2026-01-30 23:40:17 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Oct 14, 2019):

Ugh, that one drives us crazy. We haven't figured out what causes it, but it may be helped by #1896 (in PR at #3027.)

@DHowett-MSFT commented on GitHub (Oct 14, 2019): Ugh, that one drives us crazy. We haven't figured out what causes it, but it may be helped by #1896 (in PR at #3027.)
claunia commented 2026-01-30 23:40:18 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Oct 15, 2019):

It turns out that #3027 didn't fix this, so I'll see if we can't get a followup filed on the MUX team.

@DHowett-MSFT commented on GitHub (Oct 15, 2019): It turns out that #3027 didn't fix this, so I'll see if we can't get a followup filed on the MUX team.
claunia commented 2026-01-30 23:40:18 +00:00
Author
Owner
Copy Link

@gbaychev commented on GitHub (Oct 17, 2019):

Alright @DHowett-MSFT thank you very much for reponding and checking :)

@gbaychev commented on GitHub (Oct 17, 2019): Alright @DHowett-MSFT thank you very much for reponding and checking :)
claunia commented 2026-01-30 23:40:18 +00:00
Author
Owner
Copy Link

@gbaychev commented on GitHub (Oct 26, 2019):

Hello again @DHowett-MSFT,
so I was quietly working on this and did some progress:

ps

But now I've noticed that you've mentioned the issue in #3327 . The first question I have is: how does the work I did align with #3327 ? Should I drop everything, or put it on hold or simply continue?

If you want me to continue I would like to get some help/directions :)

  • If you have multiple colored tabs, I'm not sure how to signify which is the selected one. I cannot set the other tabs to transparent, since I want to see the colors on a cursory glance. I've played with the idea to make the selected tab bigger via RenderTransform, but I think it looks kinda ugly.
    For now I've set the transparency to the unselected tabs to very high, but this has some issues as well

  • Ideally I would put the 'Choose a color'/'Clear Color' menu items in a single sub-menu item. The problem is that if I do that, the app crashes randomly when I open the tab menu and since I cannot open the menu flyout in the debugger anyway, I have no idea what is going on. Is the current menu structure ok for you?

  • there is some weird behavior when I set the color of a tab (the first tab is an exception) and I add new tabs, see for yourself:

weird_ps

Any idea what this is maybe?

  • the one thing that is currently completely open is the picking of a custom color, but this should not be that difficult.

Regards

@gbaychev commented on GitHub (Oct 26, 2019): Hello again @DHowett-MSFT, so I was quietly working on this and did some progress: ![ps](https://user-images.githubusercontent.com/3358056/67625673-5c808500-f841-11e9-8c94-eedce3e2c409.gif) But now I've noticed that you've mentioned the issue in #3327 . The first question I have is: how does the work I did align with #3327 ? Should I drop everything, or put it on hold or simply continue? If you want me to continue I would like to get some help/directions :) - If you have multiple colored tabs, I'm not sure how to signify which is the selected one. I cannot set the other tabs to transparent, since I want to see the colors on a cursory glance. I've played with the idea to make the selected tab bigger via RenderTransform, but I think it looks kinda ugly. For now I've set the transparency to the unselected tabs to very high, but this has some issues as well - Ideally I would put the 'Choose a color'/'Clear Color' menu items in a single sub-menu item. The problem is that if I do that, the app crashes randomly when I open the tab menu and since I cannot open the menu flyout in the debugger anyway, I have no idea what is going on. Is the current menu structure ok for you? - there is some weird behavior when I set the color of a tab (the first tab is an exception) and I add new tabs, see for yourself: ![weird_ps](https://user-images.githubusercontent.com/3358056/67625749-5a6af600-f842-11e9-9467-b0c334ea1b14.gif) Any idea what this is maybe? - the one thing that is currently completely open is the picking of a custom color, but this should not be that difficult. Regards
claunia commented 2026-01-30 23:40:18 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Oct 30, 2019):

@gbaychev I love this! It looks so nice.

To answer your questions:

  • #3327 is more about theming the application -- I don't think it detracts from your work here.
    A user should be able to have a base theme and then set custom individual tab colors on top of it.
  • Design for selected tabs: I'm interested in seeing what @cinnamon-msft has to say here. I like how it looks in the video.
  • Choose/clear -- perhaps it should be a button/color in the color picker that opens up? Sorry about the crash, and the issue with it eating it during debugging. I can't tell exactly whose fault that one is, but it's somewhere between Microsoft.UI.Xaml (the open-source Xaml) and Windows.UI.Xaml (the Windows internal one)
  • Weird behavior for not-first tabs: I wonder why that is... How are you changing the TabItem?

With a bit of architectural work, you can also close #1912. 😄

Thanks for looking at this! Feel free to submit a draft pull request if you want to get some early feedback on your implementation, by the way: It's a lot easier to talk about code!

@DHowett-MSFT commented on GitHub (Oct 30, 2019): @gbaychev I love this! It looks so nice. To answer your questions: * #3327 is more about theming the _application_ -- I don't think it detracts from your work here. A user should be able to have a base theme and then set custom individual tab colors on top of it. * Design for selected tabs: I'm interested in seeing what @cinnamon-msft has to say here. I like how it looks in the video. * Choose/clear -- perhaps it should be a button/color in the color picker that opens up? Sorry about the crash, and the issue with it eating it during debugging. I can't tell exactly whose fault that one is, but it's somewhere between Microsoft.UI.Xaml (the open-source Xaml) and Windows.UI.Xaml (the Windows internal one) * Weird behavior for not-first tabs: I wonder why that is... How are you changing the TabItem? With a bit of architectural work, you can also close #1912. :smile: Thanks for looking at this! Feel free to submit a draft pull request if you want to get some early feedback on your implementation, by the way: It's a lot easier to talk about code!
claunia commented 2026-01-30 23:40:19 +00:00
Author
Owner
Copy Link

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

Finally getting down my inbox - this is incredible work. I'd be really excited to look through a draft PR for this.

IMO we could probably ship this without having a better solution for the "selected tab"'s appearance. I think with the graying out that the TabRow does already, and the fact that the user has to set this color at runtime, the user already knows what color they think the tab is when it's selected vs when it's not.

I agree with @DHowett-MSFT - let's put the "Clear Color" button on the color picker below the "Select custom color" button.

I'd be happy to take a look into the weirdness surrounding the non-first tabs. I'm really excited about this feature, so I'm happy to help :)

@zadjii-msft commented on GitHub (Nov 11, 2019): Finally getting down my inbox - this is incredible work. I'd be really excited to look through a draft PR for this. IMO we could probably ship this without having a better solution for the "selected tab"'s appearance. I think with the graying out that the TabRow does already, and the fact that the user has to set this color at runtime, the user already knows what color they think the tab is when it's selected vs when it's not. I agree with @DHowett-MSFT - let's put the "Clear Color" button on the color picker below the "Select custom color" button. I'd be happy to take a look into the weirdness surrounding the non-first tabs. I'm really excited about this feature, so I'm happy to help :)
claunia commented 2026-01-30 23:40:19 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (Nov 11, 2019):

The clear colour option could be a swatch with diagonal line(s) in it. This is how clear is represented in other applications from Corel and Adobe.

image

image

image

@mdtauk commented on GitHub (Nov 11, 2019): The clear colour option could be a swatch with diagonal line(s) in it. This is how clear is represented in other applications from Corel and Adobe. ![image](https://user-images.githubusercontent.com/7389110/68608500-fc2d4c80-04aa-11ea-863e-fbfb5558ed1d.png) ![image](https://user-images.githubusercontent.com/7389110/68608586-35fe5300-04ab-11ea-9a42-569f640c471a.png) ![image](https://user-images.githubusercontent.com/7389110/68608711-75c53a80-04ab-11ea-9cee-b83a9c2172b7.png)
claunia commented 2026-01-30 23:40:19 +00:00
Author
Owner
Copy Link

@ShiromMakkad commented on GitHub (Nov 19, 2019):

I agree that it is very hard to signify the current tab with custom tab colors, and it can leave the UI looking pretty ugly. The windows terminal has a great UI, and I wouldn't want that to be ruined.

Here's what I propose:
Screenshot (9)

This is a screenshot of Firefox containers. You can see with the orange bar that you can color specific tabs based on these containers. It's very clear for color coding tabs, and it doesn't interfere with the UI. Additionally, it's clear which tab is currently selected.

@ShiromMakkad commented on GitHub (Nov 19, 2019): I agree that it is very hard to signify the current tab with custom tab colors, and it can leave the UI looking pretty ugly. The windows terminal has a great UI, and I wouldn't want that to be ruined. Here's what I propose: ![Screenshot (9)](https://user-images.githubusercontent.com/13221822/69182805-ab9c9b80-0b09-11ea-8d62-6857faf0c762.png) This is a screenshot of Firefox containers. You can see with the orange bar that you can color specific tabs based on these containers. It's very clear for color coding tabs, and it doesn't interfere with the UI. Additionally, it's clear which tab is currently selected.
claunia commented 2026-01-30 23:40:19 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (Nov 19, 2019):

image

@mdtauk commented on GitHub (Nov 19, 2019): ![image](https://user-images.githubusercontent.com/7389110/69184977-b9542000-0b0d-11ea-810a-389ff5a966e3.png)
claunia commented 2026-01-30 23:40:20 +00:00
Author
Owner
Copy Link

@ShiromMakkad commented on GitHub (Nov 19, 2019):

That looks even better! It also looks a lot more Windows-esque which makes sense for this terminal.

@ShiromMakkad commented on GitHub (Nov 19, 2019): That looks even better! It also looks a lot more Windows-esque which makes sense for this terminal.
claunia commented 2026-01-30 23:40:20 +00:00
Author
Owner
Copy Link

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

This looks really promising! I just raised a feature-request (https://github.com/microsoft/terminal/issues/3687) that suggested using the theme mechanism for this (so as to have a better chance of ending up with consistent text/background colors) but I'd be very happy with this as a start!

@NeilMacMullen commented on GitHub (Nov 24, 2019): This looks really promising! I just raised a feature-request (https://github.com/microsoft/terminal/issues/3687) that suggested using the theme mechanism for this (so as to have a better chance of ending up with consistent text/background colors) but I'd be very happy with this as a start!
claunia commented 2026-01-30 23:40:20 +00:00
Author
Owner
Copy Link

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

Hello folks,

thank you very much for the kind feedback and suggestions.

I just want to give you a heads up that - no, I'm not dead and I did not give up on this feature. But I have my job and private stuff I need to take care of, so I think you understand.

I'm going to try to submit a work in progress PR next week, so that you can take a look at.

What is the current situation:

  • I need to move the clear color menu element to the color selection flyout
  • I need to implement the selection of the custom color

I've already thought about the Firefox way of highlighting the selected tab, as @ShiromMakkad suggested, but the problem is I'm not sure how to implement it.
If I try to create a custom TabViewItem, the midl compiler throws its hands in the air, because there are some attributes in the TabViewIteml.idl (called MUX_*), which are defined in a header, which I have no access to (see here). I have no idea what happens if I simply redefine them.

I also tried to use a Gradient Brush with a very sharp gradient to emulate this effect, but it looks terrible.

Maybe a solution would be to paint the frame of the whole window in the tab's color, see for example the tabs of the stash in Path of Exile:
tabs. Do you notice how the frame of the stash is also painted green as the current tab?

As for the question of @DHowett-MSFT (how do I change the tab item) - I simply push some colors in the resource dictionary of the TabViewItem (e.g. TabViewItemHeaderBackground) and switch the visual state using the VisualStateManager, so that the changes are reflected immediately. Even if I remove the visual state code, the weird issue persists.

Another question, the branch of my repo is based on your master branch. Is this correct, or I should've taken another branch?

I think this is all for now.

Best regards

@gbaychev commented on GitHub (Nov 24, 2019): Hello folks, thank you very much for the kind feedback and suggestions. I just want to give you a heads up that - no, I'm not dead and I did not give up on this feature. But I have my job and private stuff I need to take care of, so I think you understand. I'm going to try to submit a work in progress PR next week, so that you can take a look at. What is the current situation: - I need to move the clear color menu element to the color selection flyout - I need to implement the selection of the custom color I've already thought about the Firefox way of highlighting the selected tab, as @ShiromMakkad suggested, but the problem is I'm not sure how to implement it. If I try to create a custom TabViewItem, the midl compiler throws its hands in the air, because there are some attributes in the TabViewIteml.idl (called MUX_*), which are defined in a header, which I have no access to (see [here](https://github.com/microsoft/microsoft-ui-xaml/blob/4dd6b16cfdabe75d9c46c5aa37ebcf4162415499/dev/TabView/TabView.idl#L129)). I have no idea what happens if I simply redefine them. I also tried to use a Gradient Brush with a very sharp gradient to emulate this effect, but it looks terrible. Maybe a solution would be to paint the frame of the whole window in the tab's color, see for example the tabs of the stash in Path of Exile: ![tabs](https://user-images.githubusercontent.com/3358056/69500909-eb93c200-0eff-11ea-8d86-28cf2c803e00.jpg). Do you notice how the frame of the stash is also painted green as the current tab? As for the question of @DHowett-MSFT (how do I change the tab item) - I simply push some colors in the resource dictionary of the TabViewItem (e.g. TabViewItemHeaderBackground) and switch the visual state using the VisualStateManager, so that the changes are reflected immediately. Even if I remove the visual state code, the weird issue persists. Another question, the branch of my repo is based on your master branch. Is this correct, or I should've taken another branch? I think this is all for now. Best regards
claunia commented 2026-01-30 23:40:20 +00:00
Author
Owner
Copy Link

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

Glad to hear you're not dead 😜

So, in my opinion, it's probably better to get this checked-in in it's current state, and continue to iterate on the design in future releases. We can work with @teap and other XAML folks to help us style it as an underline/overline on the tab later, but it's probably best to get the fundamentals there now.

@zadjii-msft commented on GitHub (Nov 25, 2019): Glad to hear you're not dead 😜 So, in my opinion, it's probably better to get this checked-in in it's current state, and continue to iterate on the design in future releases. We can work with @teap and other XAML folks to help us style it as an underline/overline on the tab later, but it's probably best to get the fundamentals there now.
claunia commented 2026-01-30 23:40:21 +00:00
Author
Owner
Copy Link

@gbaychev commented on GitHub (Nov 30, 2019):

PR is dropped, as promised.

@gbaychev commented on GitHub (Nov 30, 2019): PR is dropped, as promised.
claunia commented 2026-01-30 23:40:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jun 18, 2020):

:tada:This issue was addressed in #3789, which has now been successfully released as Windows Terminal Preview v1.1.1671.0.🎉

Handy links:

@ghost commented on GitHub (Jun 18, 2020): :tada:This issue was addressed in #3789, which has now been successfully released as `Windows Terminal Preview v1.1.1671.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.1.1671.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
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-Extensibility Help Wanted Issue-Feature Product-Terminal Resolution-Fix-Committed
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#4178
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?