Feature Request: allow to pick the color of the tabs

[gbaychev]

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:

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

[mdtauk]

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

[zadjii-msft]

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:

• Ability to rename Tab title at runtime #1079 - this deals with setting a (temporary) title at runtime through a similar UI
• UI Suggestion: Visually link tab to console view #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.

[DHowett-MSFT]

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.

[zadjii-msft]

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.

[egmontkob]

Also slightly related: #1868.

[gbaychev]

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

[mdtauk]

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

[egmontkob]

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.

[zadjii-msft]

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

[egmontkob]

Me neither 😜

[mdtauk]

@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

[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.

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.

[mdtauk]

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

[egmontkob]

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

[gbaychev]

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 :(

[DHowett-MSFT]

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]

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.

[gbaychev]

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

[gbaychev]

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:
. 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

[zadjii-msft]

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.

[gbaychev]

PR is dropped, as promised.

[ghost]

🎉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
• Store Download