Allow to configure title bar information

[alexdresko]

It would be great if we could configure the information that gets displayed in the title bar. I use ManicTime a lot, and it's hard to auto tag my activities when the title bar basically only displays the file name and root folder name. Having the full path to the file and the git branch name would be super helpful.

For some other ideas, this VS plugin is super rad and affords complete control over what gets displayed in the title bar. https://visualstudiogallery.msdn.microsoft.com/2e8ebfe4-023f-4c4d-9b7a-d05bbc5cb239

[alexdresko]

@bpasero By assigning this to yourself, does that mean it might happen? If so, please let me know if you would like some help, even if it's just for feedback.

[bpasero]

This issue is currently assigned to the backlog. Every sprint we pick items from the backlog to plan for the current iteration. Please see https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning

[jamietre]

+1. The more I use VS Code on bigger projects, it's becoming frustrating to be unable to distinguish between open windows. I wish I could configure the title to just show [Root Folder] - [File], since it's hard to distinguish between open projects when the file name is shown first. But some simple templating system would probably solve everyone's problem.

[bpasero]

#12625 for the issue to show the full path in the title bar. This might resolve many (but not all) concerns of this issue.

[jamietre]

@bpasero i do appreciate the effort but actually this still does not address the issue (at least as far as Windows) is concerned. It may actually make it worse (though since it's an option that's not an issue).

The problem is that in Windows, the taskbar shows a preview of all windows for a given application, and there is only limited space to show the title. Showing the full path would give me exactly the opposite problem I have now: I'd just see the part of the path, starting with the root, that fits in the display. So with this enabled, I'd most likely have no information at all about which window was which, since they likely all share a common root path.

What is really needed is the ability to show project-root/../filename or project-root * filename. The parent folder is nearly always the identifying feature for a project. I don't even care if the filename gets cut off- because I really just want to be able to determine which project is open from the title bar.

In the example below the only one I can tell which project is open is iter8 because the file name happens to be very short. But even when it's visible, it's hard to visually parse because it's not aligned to anything. I want the project root folder on the left (instead of after the filename) so it is always visible.

[bpasero]

@jamietre we can still tweak this experience and I welcome the problem description you gave, though I am not sure how to best solve it.

Here is how your scenario looks like without the new option enabled:

And here with the option turned on:

This makes it hard to see the currently opened file but you can easily see the full path when you compare the 2 window titles in full (not from this experience).

I think this feature request is still valid for that particular scenario because you could then really compose the title you want, I am not sure we should change the experience by default with the new option.

I am open for suggestions though if the default experience when this new option is turned on should be changed.

[jamietre]

Thanks for all the feedback, it's very appreciated.

In my case almost all my code is under a single heirarchy like d:/users/jtreworgy/code/... -- so if I were lucky I might get a few characters of the root folder. But I also work in subfolders with groups of projects, too, so it would be quite realistic for there to be nothing unique at all. I could try to keep everything under shallow heirarchies but I guess I'd rather not have to design my file system architecture around accomodating VS Code ;)

The perfect world for me would be the ability to pass a template like "{rootFolder} - {fileName}" instead of boolean options for predefined templates. Just having rootFolder, fileName and fullPath as available parameters would accomodate everything that's been discussed here as well as the current state.

Even more perfect world, the ability to invoke a javascript function that I wrote to return my title given the path as input :) but then I've written a plugin haven't I..

[bpasero]

@jamietre but how is root folder solving it when you have 2 workspaces with the same name in different hierarchies?

"{rootFolder} - {fileName}" isn't that what we are showing today without the full path option enabled?

[jamietre]

I wasn't considering that possibility - I would never have two workspaces with the same name open (or at least, it's not particularly likely, maybe if I was trying to deep dive some comparison between two branches?). But that's not my problem generally... if that is an issue for some people, perhaps a possible solution is to also display a numerical index identifying which was opened first? Can VS code instances know anything about each other?

But anyway -- right now the problem is the root folder appears last, e.g. {fileName} - {rootFolder} so it is cut off for long file names (which are pretty common in our projects). And it's hard to parse them even if they are visible when they aren't left-aligned.

[bpasero]

Oh yeah, that is true. I was not thinking about the fact that the file name comes first. We cannot change that without making it hard for users that want to quickly glance at the file name in that scenario so I guess no matter what it boils down to making it configurable if any.

I still think the setting to show a full path is a good one, so I will keep it as is for now and we leave this one here open.

[ghost]

I would really love to hve an option/config to at least show {rootFolder} first. event if its just that (don't really see the point of having the filename in the title bar. For me the next most useful information would be the git branch name: "{rootFolder} - {branchName}"

[jamietre]

@Cedric-Venet agreed. If VS Code allowed you to drag a file out to start a new window, I could see how that might be useful to some. But you can't -- so it just doesn't seem likely that's what many people are looking for a file name when trying to discriminate between open instances.

I looked at the code that creates the window title invs/workbench/services/history/browser/history.ts... it seems straightforward and I am sure I could handle the change to support user-provided templates if this change would be accepted. @bpasero would you be interested in a PR? I have no idea what the overhead is in getting set up to create vs code builds - if you can convince me it's not too bad I'm willing to take a shot :)

[alexdresko]

@jamietre Dunno if this exactly deals with one of your use cases, but there's a plugin called "Open Folder Context Menus for VS Code" that "Quickly opens a new instance of VS Code from the Explorer". Works pretty well for me.

[jamietre]

@alexdresko the problem isn't opening VSCode, it's finding the correct instance among a bunch of already opened ones.

[saborrie]

I often have multiple windows of VSCode open. Until I found this issue I'd had a different thought on how to solve it: setting a workspace/folder colour.

I commonly have one window using the integrated debugging feature for a backend written in NodeJs. The bottom bar goes orange when debugging, and I've been using that help distinguish which is which.

You can see this in a picture already posted in this thread:

I tend to switch between full-screen windows using the keyboard, rather than hovering on the taskbar to select a window. But even when flicking between full-screen windows, it's not always clear where you've switched to. And while being able to customise the title of the window would give me somewhere to glance at, I think that colourising some part of the window would allow for even quicker discerning of which instance has been focused.

Although the title of this issue is "Allow to configure title bar information" I figured that my suggestion probably belonged here at first rather than in it's own issue, since the other comments here have equated this issue to "Allow to configure easy distinction between open windows". But I can create a new issue if others agree with my suggestion but don't want to lump the two together.

[paulX7]

+1. I frequently work on multiple sub-projects of a large project at the same time. {filename} - {root folder} doesn't help because, for other reasons, all of my root folders are 'src' in VSCode for each of my projects.

[gilboa23]

The ability to configure the window title to show "{rootFolder} - {fileName}" or even better just "{rootFolder}" instead of "{fileName} - {rootFolder}" is critical for us. We're working in a multiple project setup in Windows and it is currently impossible to distinguish open vscode windows on the taskbar.

This seems to be a rather trivial configuration option to implement, but it adds tremendous usability value.

[bpasero]

I settled on the following solution: there is a new setting window.title (the previous window.showFullPath is no longer supported) that allows to configure the title based on some variables.

Variables are declared using ${} syntax and the following are available:

• ${activeEditorName}: e.g. myFile.txt
• ${activeFilePath}: e.g. /Users/Development/myProject/myFile.txt
• ${rootName}: e.g. myProject
• ${rootPath}: e.g. /Users/Development/myProject
• ${appName}: e.g. VS Code
• ${dirty}: a dirty indicator if the active editor is dirty
• ${separator}: a conditional separator (" - ") that only shows when surrounded by variables with values

Default values on the various OS:

macOS:
${activeEditorName}${separator}${rootName}

Linux/Windows:
${dirty}${activeEditorName}${separator}${rootName}${separator}${appName}

Since the original request asks also to see the git branch information in the title, I extracted #20016 to follow up.

[alexdresko]

Is this in the latest insiders build?

[bpasero]

@alexdresko it will be tomorrow.

I did a slight update to let the variables be ${} instead of $().

Happy for everyones feedback once this is out.

[jamietre]

w00t! THANK YOU!!

I am 99.5% happy with this. The last .5% is that (of course) it would be nice to be able to use a Javascript function that gets called with these arguments, instead of just a string template, so i could do fancy things like include the last 2 segments of the path... handle certain types of things differently (e.g. modules vs. apps), etc.

But this is definitely just being greedy, and probably everyone has better things to do now. :) This absolutely solves the problem for me, I can figure out at a glance which window I'm looking for. Best Tuesday ever!

[bpasero]

Yeah, I can see how a scripted solution would be better, but let's see how far we get with this approach for now.

[jamietre]

It would be a more universal solution to this kind of thing, generally, but I assume it involves some kind of infrastructure change or new convention, since config is json & not js.

Really just threw that out there for long-term consideration. I'm very happy with the way this is working.

[bpasero]

Actually I wonder if ${separator} should be dropped, it seems there is really only one usecase for it: to separate between 2 variables if (and only if) both variables are present:

${foo}{separator}${bar}

Why not just automatically add a separator if there is ${foo}${bar}? Makes it easier to read and gets rid of a complicated and confusing variable.

[jamietre]

You might not always want it, e.g. ${dirty}${foo}

[bpasero]

Hm yeah 💩

[gilboa23]

Thanks, I've been waiting for this for long time. Small changes sometime make a big difference :)

…

On Tue, Feb 7, 2017 at 7:16 PM, Benjamin Pasero ***@***.***> wrote: Hm yeah 💩 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1723 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARwKKPmdVfRcuBt8wcpa48vJriFMafleks5raKcEgaJpZM4G9Nhu> .

[tommck]

I really like it. Thank you for this update.

You might want to think about allowing people to add parsing logic (too much?)

In my case, our code is laid out like:

/path/to/project/[Branch Name]

So, using {rootPath} is nice, but I'd like to trim "[Branch Name]" off most of the time.

It might be a bit much to support this though

[tommck]

UPDATE: Ignore this - not a problem

This doesn't seem to be working for me. I'm not seeing the file name first.. just seeing

"C:\Path\To\Project - Visual Studio Code - Insiders"

"window.title": "${dirty}${activeEditorName}${separator}${rootPath}${separator}${appName}",

I restarted the app and opened various files.

Also, does it require a restart to work? Kind of hard to test what you're doing that way

[alexdresko]

Pro tip: You won't see the setting changes when editing the settings file. You have to switch to another file in your workspace to see the changes you've made in the settings. Not sure why that is exactly.

And it does not require a restart.

[tommck]

The tooltip help for it isn't formatting properly either :)
Should I open a bug?

[tommck]

Huh.. I think it's actually updating, but taking a LONG time to do so on this machine. So, I think my problem with the title bar is not a problem.

[tommck]

Hmm.. now we just need this feature for the "recent window" list, which just shows the folder name for me, which isn't specific enough (lots of "main" listed in there)

[bpasero]

Small update, I added ${activeFilePathRelative} to be able to show a shorter path to the active opened file if the file is from within the workspace opened. E.g. instead of /Users/Development/myProject/myFolder/myFile.txt showing myFolder/myFile.txt if myFolder is opened. Together with ${rootName} this allows to show a file path as myProject/myFolder/myFile.txt if desired.

[bpasero]

Another update after feedback from testing during this week from the team: ${activeFilePath} and ${activeFilePathRelative} are working only if a file is opened, making the configuration of the window.title hard when non-file editors are opened.

I decided to revisit the variables around file paths and change them because things are getting complicated when an editor is not showing a file.

Here is my new solution:

• ${activeEditorLong}: e.g. /Users/Development/myProject/myFolder/myFile.txt
• ${activeEditorMedium}: e.g. myFolder/myFile.txt
• ${activeEditorShort}: e.g. myFile.txt

If there is no long editor label, the medium one will be used. And the same is true for medium and short.

Basically:

• replace ${activeFilePath} with ${activeEditorLong}
• replace ${activeFilePathRelative} with ${activeEditorMedium}

I hope this works for everyone, should be available in today's insider build.

[nfour]

@bpasero is there a way to remove the [Unsupported] suffix in the title, when vscode has a modified installation (I'm using custom CSS)?

Looks like MyFancyProject [Unsupported] in the title bar.

[bpasero]

No, we strongly advice against using extensions that modify our bits so it is in the best interest to show this not only to you as a user but also to us when we have to investigate bugs which are caused by extensions that patch our bits.

[VojtechVitek]

@bpasero "window.title" is a neat addition, thanks. Can we have something similar for tabs?

I'd love to see the last directory name as a prefix to the filename on all tabs.

Vim tabs are very smart about tab names btw.

[bpasero]

Yeah this was reported already as feature request.

[nileshp87]

I made a quick extension for setting the title for the workspace: https://marketplace.visualstudio.com/items?itemName=nilpatel.title

Those who find this thread may find it useful.

[VojtechVitek]

@nileshp87 works great, thank you!