Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: suppress VT title and prefer profile name (or something else) #608

Closed
Tracked by #1375
DHowett-MSFT opened this issue May 9, 2019 · 48 comments · Fixed by #1358
Closed
Tracked by #1375
Assignees
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@DHowett-MSFT
Copy link
Contributor

"Is it also possible to shown a short title instead of the whole path?"

Originally posted by @wahid in #491 (comment)

@DHowett-MSFT DHowett-MSFT added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label May 9, 2019
@DHowett-MSFT DHowett-MSFT changed the title Feature: suppress VT title and prefer profile name (or something else) Feature request: suppress VT title and prefer profile name (or something else) May 9, 2019
@zadjii-msft zadjii-msft added this to the Windows Terminal v1.0 milestone May 9, 2019
@zadjii-msft
Copy link
Member

We do have a setting ("showTerminalTitleInTitlebar":bool) that suppresses the title changing. Now we just need a setting for what to display instead of just "Windows Terminal"

@zadjii-msft zadjii-msft added the Help Wanted We encourage anyone to jump in on these. label May 9, 2019
@DHowett-MSFT
Copy link
Contributor Author

DHowett-MSFT commented May 9, 2019 via email

@ObsidianPhoenix
Copy link
Contributor

I agree, this seems like a good shout, the profile name property should be used in the tab title instead of the commandline property.

@timheuer
Copy link
Member

I'm looking at this (it's annoying to me a bit right now).

I'm struggling to find where the instance of TerminalControl is changing as that's what is happening here: https://github.com/microsoft/terminal/blob/master/src/cascadia/TerminalApp/Tab.cpp#L34 and no matter what I've tried to force the TabViewItem.Header to the profile name, it keeps getting reset.

@ObsidianPhoenix
Copy link
Contributor

Yeah I was taking a look too. I think the initial title is taken from the console itself as it starts up. And the way Terminal initialises the consoles means that it’s just the exe path by default.

You can see how it’s hooked up by changing the title from within the console itself - the events hooked up capture this change from within the console itself and updates the tab element in the UI.

I think we’d need to be careful changing it so that a title change within the console itself continues to allow direct changes from the console.

Unfortunately I’ve still not figured out a way to set the initial value while preserving the events either. It may just need a manual action as part of the tab creation process, but that would hide something a user puts into their powershell profile script.

@oising
Copy link
Collaborator

oising commented May 15, 2019

@timheuer -- it's likely sync'ing with VT sequence OSC 0/1/2 (all are treated equivalently in the terminal although strictly they shouldn't be). Fire up a pwsh instance and try "`e]0;new title`a" and you'll see the tab header changes as well as the root window's. The reason it's getting overridden every time is that with every repaint of the buffer, it's emitting the OSC sequence to reset the title. So, in order to change the tab header, you'll need to change state in the VT engine itself; ergo you'll need to emit the right code, at the right time. This may or may not be trivial to do. I'm not that familiar with the codebase.

@oising
Copy link
Collaborator

oising commented May 15, 2019

I'm guessing whenever @miniksa gets proper region invalidation working, the title won't be emitted every frame. Right now the entire buffer is repainted with every keystroke.

@timheuer
Copy link
Member

timheuer commented May 15, 2019

it's likely sync'ing with VT sequence OSC 0/1/2 (all are treated equivalently in the terminal although strictly they shouldn't be). Fire up a pwsh instance and try "`e]0;new title`a" and you'll see the tab header changes as well as the root window's.

Interesting! Thanks for that explanation.

You can see how it’s hooked up by changing the title from within the console itself - the events hooked up capture this change from within the console itself and updates the tab element in the UI.

Yeah I see that immediately the TitleChanged event is firing pretty reliably after tab creation (I changed to some hard-coded values as my debugger is not working with breakpoints to follow the code flow :-()

Unfortunately I’ve still not figured out a way to set the initial value while preserving the events either. It may just need a manual action as part of the tab creation process, but that would hide something a user puts into their powershell profile script.

I suppose this warrants actually a PM decision here. I think the nature of profiles for me is that the 'name' I give it is what I want in the tab header (I don't care really about the Window title as I imagine that is going to go away once the team fixes the XAML non-client area situation to make it draggable while hiding the window title). This is how I have things configured in ConEmu with my tabs being the names I've provided for the tasks/shell...makes it easier for me to find them. Path is useless.

@DHowett-MSFT
Copy link
Contributor Author

Path is useless

For some. For others, the title contains useful information -- the machine they're connected to, how many hops, and what "environment" they're in!

This'll be a profile-level feature, and it might require some of the Tab changes that are going on in #825. They probably clear up ownership of a few of the Control/Tab/App areas.

@timheuer
Copy link
Member

Fair enough -- beauty in the eye of the beholder and all :-D. In a heavily multi-tabbed UI experience though, this information gets long and truncated (or should) so that the usefulness fades a bit. Take a look at any heavy user of tabs in a browser. Also please don't assume massive monitors for users and this won't happen -- I'm not a multi-mon user and my screen space is valuable to me.

Either way, having a PM call here @cinnamon-msft may be the right path to clarify desired behavior before proceeding.

@mdtauk
Copy link

mdtauk commented May 15, 2019

The teaser concept video shows a status bar at the bottom of the app. Some of that information could be placed there maybe @timheuer

@cinnamon-msft
Copy link
Contributor

I was just having a conversation about this today.

Ideally, the title of tabs will be configurable by the user, either with the path, shell name, name of their pet, etc. all configurable within the profiles.json file.

Additionally, the status bar shown in the video adds another option of where you could display the path if that's something important to you. This feature hasn't been designed yet, so that'll be a little ways out.

@zadjii-msft
Copy link
Member

zadjii-msft commented May 16, 2019

See, I'm thinking it should be either 2 or three states:

  1. Use title from terminal (this is what we have today)
  2. Use a custom string. This could default to the profile name (if we had settings UI), or the user could customize it to whatever.
  3. Use profile name. This one feels like a special case of 2.

If we went with just 2 modes, we could do it in the two possible ways:

  1. Add an optional titleText:string string to the profile. If that's set, then we'll display that string instead of the terminal's title.
  • this has the downside of not defaulting to the profile name. The user would manually need to set that string.
  • if the profile name changes, then the user would have to manually change this as well.
  • it might not be abundantly clear that titleText means we'll be using that instead of the terminal's title, but ideally the settings UI will explain this better, and the actual key doesn't matter so much.
  1. Add a useTerminalTitle:bool and optional titleText:string to the profile. If useTerminalTitle is set, then we'll use titleText, if it's set. If titleText isn't set, then we'll default to the profile name.
  • this has the upside of defaulting to the profile name.
  • this has the downside of having two settings the user needs to maintain, as opposed to one.
  • could people be confused that having titleText set to something, but useTerminalTitle:false does nothing?

Thoughts?


PS:

I don't care really about the Window title as I imagine that is going to go away

The window title will still be used, even with non-client tabs, for the alt-tab view and other shell things:

image

@timheuer
Copy link
Member

I wouldn't personally create a new property. profile:name exists and so early on that you could state this is what it is and where it will be used (frankly the only place it seems to be used now is the menu). Having name and titleText in the profile seems redundant to me and has issues with what you point out (someone may/may not change both). Feels to me:

  • add useProfileNameAsTitle and default to false (looking at conemu as an example here they use the exe)
  • keep name and make that the displayed value if above is set to true
  • if the full shell exe is used, truncate it at least. IMO the full path in the tab can get long and occupies space (open 5 powershell tabs on a laptop). Again, conemu inspiration here just shows me 'powershell.exe' unless i rename it
  • OPTIONAL: support rename from the tab (if i right-click on the tab 'Rename' -> then that sets/resets profile name + sets the useProfileNameAsTitle to true

Also, ack on the alt+tab view showing window title. Thanks for the reminder. Personally I think that should be displaying "Windows Terminal - "

@mdtauk
Copy link

mdtauk commented May 16, 2019

Tabs at the top, means no Window Title, but Tabs at the bottom would be different.

image

Then there is the Status Bar which could display various bits of information. Tabs at the top could mean a status bar below the console view, or it could be part of the console view itself, and thus customisable and monospaced.

image

But then you could have each tab appear in Alt+Tab and the Taskbar Icon hover. So perhaps.

Windows Terminal - App Name / Window Title
Ubuntu 18.04 - Profile Name / Tab Text
Windows Terminal - Ubuntu 18.04 - Alt+Tab preview text

@zadjii-msft
Copy link
Member

@timheuer I was trying to design for the fact that some people might want to set the title to something other than the profile name. I don't really know why you'd want that, but as @cinnamon-msft said:

the title of tabs will be configurable by the user, either with the path, shell name, name of their pet, etc.

So someone could have the profile be named "Foo" and the tab text still say "Bar". Or even have the name be Powershell and the title text be pwsh.exe.

@timheuer
Copy link
Member

Yeah, we should really define what profile name means...because you kind of already have an internal identifier, so if it isn't the public identifier, than what is it...so I think it really needs to be clarified what name is going to be used for. As you said I don't know why you would want name "foo" but display "bar"

@gaohongkui

This comment has been minimized.

@mdtauk
Copy link

mdtauk commented May 17, 2019

Those are just design mock ups I made to try to illustrate ideas as I contribute on here

@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Product-Terminal The new Windows Terminal. and removed Mass-Chaos labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@fredless
Copy link

until this gets addressed, I'm just:

"commandline" : "cmd.exe /k \"title cmd\"",
"commandline" : "powershell.exe -NoExit -Command \"& {$host.ui.RawUI.WindowTitle = 'ps'}\"",
"commandline" : "python.exe -i -c \\\"import ctypes; ctypes.windll.kernel32.SetConsoleTitleW('py')\\\""

(and yeah I know there are multiple clever ways to do this)

@MCKLMT
Copy link
Member

MCKLMT commented Jun 27, 2019

What about WSL? 🤔

@fredless
Copy link

fredless commented Jun 27, 2019

What about WSL? 🤔

More tricky but also way more flexible. bash in many distributions (re)sets the window title at every prompt via escape codes on PS1. For example, WSL Ubuntu 18.04 ships with this default in your user's .bashrc:

case "$TERM" in
  xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
  *)
    ;;
esac

Pay attention to what appears between \e]0 (literal "ESC"+"]"+"0") and \a (bell or alarm).
Changing this to:

 PS1="\[\e]0;ubuntu\a\]$PS1"

..yields something that suits my needs:
image

EDIT with a more considered approach: if you're aiming for a static value, rather than setting the title to the same value at every prompt, just set it once at shell init. Comment out the entire case\esac sequence that adds the ESC]0 sequence to PS1 in the 1st place, and just add a line to .bashrc to output the same sequence one time:

echo -e -n "\e]0;ubuntu\a"

@DHowett-MSFT DHowett-MSFT mentioned this issue Jul 1, 2019
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Jul 2, 2019
@cinnamon-msft cinnamon-msft removed Help Wanted We encourage anyone to jump in on these. Needs-Tag-Fix Doesn't match tag requirements labels Jul 2, 2019
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Jul 2, 2019
@cinnamon-msft cinnamon-msft added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Jul 2, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jul 2, 2019
@fredless
Copy link

fredless commented Jul 2, 2019

thanks for that tabTitle patch - haven't built this yet, but looking forward to removing my workarounds

@ghost
Copy link

ghost commented Aug 3, 2019

🎉This issue was addressed in #1358, which has now been successfully released as Windows Terminal Preview v0.3.2142.0.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.