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

• #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.

[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 :stuck_out_tongue_winking_eye:

[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 again @DHowett-MSFT,
so I was quietly working on this and did some progress:

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:

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

[DHowett-MSFT]

@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!

[zadjii-msft]

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

[mdtauk]

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.

[ShiromMakkad]

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:

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.

[mdtauk]

[ShiromMakkad]

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

[NeilMacMullen]

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!

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

[msftbot[bot]]

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