-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Comments
We do have a setting ( |
I agree, this seems like a good shout, the profile |
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. |
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. |
@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 |
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. |
Interesting! Thanks for that explanation.
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 :-()
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. |
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 |
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. |
The teaser concept video shows a status bar at the bottom of the app. Some of that information could be placed there maybe @timheuer |
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. |
See, I'm thinking it should be either 2 or three states:
If we went with just 2 modes, we could do it in the two possible ways:
Thoughts? PS:
The window title will still be used, even with non-client tabs, for the alt-tab view and other shell things: |
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:
Also, ack on the alt+tab view showing window title. Thanks for the reminder. Personally I think that should be displaying "Windows Terminal - " |
Tabs at the top, means no Window Title, but Tabs at the bottom would be different. 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. But then you could have each tab appear in Alt+Tab and the Taskbar Icon hover. So perhaps. Windows Terminal - App Name / Window Title |
@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:
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 |
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 |
This comment has been minimized.
This comment has been minimized.
Those are just design mock ups I made to try to illustrate ideas as I contribute on here |
until this gets addressed, I'm just:
(and yeah I know there are multiple clever ways to do this) |
What about WSL? 🤔 |
thanks for that tabTitle patch - haven't built this yet, but looking forward to removing my workarounds |
🎉This issue was addressed in #1358, which has now been successfully released as Handy links: |
"Is it also possible to shown a short title instead of the whole path?"
Originally posted by @wahid in #491 (comment)
The text was updated successfully, but these errors were encountered: