Add an optional status bar to the bottom

[zadjii-msft]

As seen in the original mockups:

We've apparently discussed this in a ton of threads but never had an issue for it. So this is that issue.

Things to consider:

• It must be optional. Many users won't want a status bar.
• How does it play with tabs on the bottom? See Feature request: Enable customization for tabs on bottom/right/left #835
• What info would a user want there?
  • Username, machine name, date/time are all easy kinda Hard, because of SSH.
  • Keep in mind that many things from the shell (child process) we won't be able to access. Things like current path, git branch, active codepage.
    • Working path might be possible with OSC 7 (in Open new terminal tab in same directory as existing tab (OSC 7?) #3158), though, it'll only work for shells that set it (which won't include cmd.exe).
• How does the user specify the contents of the statusbar? Alignment of pieces of info?
• Should the user be able to add buttons to the status bar that perform actions? E.g. a "gear" button to quickly open the settings?

These are all things that should be enumerated in a spec before we review a PR.

[egmontkob]

Things like current path

See OSC 7 in #3158.

git branch

Once you know the current path (and it's a local one), it's easily doable. Maybe watch for the change of whichever file tracks the checked out branch, or update every few seconds, or update every time OSC 7 is reissued.

Just wondering: Would you hardcode getting the git branch, or maybe have a plugin system that can be extended for other VCSs too?

active codepage

Hmmm, does WT not know the codepage (is conversion done by some layer running inside the terminal)?

[zadjii-msft]

See OSC 7 in #3158.

Oh lawd, I forgot that existed. That is excellent, and should definitely be considered for part of this. I'll update the OP. You're right that it does make displaying the git branch much easier (so long as a shell actually sets it 😉)

Hmmm, does WT not know the codepage (is conversion done by some layer running inside the terminal)?

Well no(ish). WT is always running in 65001. Conpty is the layer that's responsible for the magic translation here - it's the one that's actually running in an interesting codepage. It's the one that is changed when the client application calls SetConsole*Codepage. Then conpty does the magic to translate that to UTF-8 for the terminal to consume. So the interesting codepage, the one the client app is running in, isn't really exposed to WT.

[DHowett-MSFT]

Even username/machinename are fraught with peril for anything except local sessions. There's heuristic detection, sure, but that'd require us to crack the title (if we are graced with a shell that sets it) or figure out which part of the output stream is a prompt.

[egmontkob]

Username and hostname can probably be squeezed into OSC 7 without problems, using the standard file://username@hostname/path... syntax. Alas, it needs efforts from OSes (shells etc.) actually emitting it, which doesn't really seem to happen.

[mdtauk]

I'd like to throw my voice in for enabling the status bar to be in the window shell itself, but also to be placed within the terminal area itself, using the profile's colour scheme.

[DHowett-MSFT]

It's just that, like, everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

[mdtauk]

It's just that, like, everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

Progress could be displayed?

Linux profiles may offer more information to display.

Azure cloud may have local timezone.

[egmontkob]

Progress [...] Linux profiles [...] Azure local timezone

All of these require heavy design and cooperation between components (like Linux, Azure etc.), not just some easy UI work.

[egmontkob]

everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

There's a clock in the bottom right corner of your desktop. There would be a clock in the bottom right corner of your terminal. If you launch tmux inside, you have a clock in the bottom right corner of the terminal area (in tmux's status bar). Luckily my favorite text editor can also display the time :)

[mdtauk]

everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

There's a clock in the bottom right corner of your desktop. There would be a clock in the bottom right corner of your terminal. If you launch tmux inside, you have a clock in the bottom right corner of the terminal area (in tmux's status bar). Luckily my favorite text editor can also display the time :)

This would also highlight the plus side for displaying the status bar within the terminal area with profile colouring - so when the terminal is full screen or maximised, it will appear and not be distracting

[driver1998]

What about indicators for caps lock, numlock, insert and so on? These can be useful for people who have no indicators on their keyboards. Also it is a classic thing to have on status bar :)

[egmontkob]

In my serious opinion, everything that is not related to the terminal per se (e.g. date+time, caps+num lock...) should go to the desktop (taskbar) and not to the terminal.

[driver1998]

It might be right for caps lock/numlock, but insert/override status is managed per-app, not system wide.
Also ConHost changes cursor shape when Insert status changes.

Edit: well it seems Powershell doesn't actually support override mode, only insert mode... But CMD supports both.

[mdtauk]

In my serious opinion, everything that is not related to the terminal per se (e.g. date+time, caps+num lock...) should go to the desktop (taskbar) and not to the terminal.

Some people like to use the terminal in full screen, without other UI.

Also if connecting to a server or data-centre, there could be a local time zone to consider.

There are examples of terminals with status bars (probably a third party app running) so it is something that could be offered as an extension in the future, if the terminal team doesn't want to provide one inbox - but creating the ability for a status bar to display, either in the shell or in the terminal space, is worth adding.

---

Rather than adding all the functionality people want into a Status Bar - what if it becomes a surface within the terminal, that developers and plug-in/extension makers could put content into. This handles the issue of backwards compatibility, as it will be something loaded in by the Windows Terminal itself.

[egmontkob]

Some people like to use the terminal in full screen, without other UI.

I know. The question is: what does "without other UI" mean exactly? If they want to hide the taskbar, wouldn't they also want to hide the terminal's status bar? :-)

Also if connecting to a server or data-centre, there could be a local time zone to consider.

As said earlier, this requires backend work. In fact, a freaking huge amount of backend work, something along the lines of transferring the entire timezone database, or at least info about any forthcoming DST change, or transferring the local time every minute or so (even if an app is running and is the middle of emitting an escape sequence, without breaking it in hafl), or risking the clock slowly drifting away, or temporarily going off during a DST change or a sudden adjustment (the latter shouldn't happen in professional environment), or getting it stuck with a slight offset if the network was laggy when the timestamp was sent over... It's fairly easy to get it mostly working, it's extremely hard to get it robustly working. But if done, certainly this clock would be a reasonable thing to have, since then it's a per-terminal thing and not the same as the clock shown on the taskbar.

[j4james]

Something worth mentioning, is that a status line is one of the features of the VT320 terminal (and assumedly later models as well). And this was something that terminal applications could choose to overwrite with custom content, or even turn off completely if they wanted to use that space for their main content.

So if you decide to render this as part of the main viewport area, it might be worth considering where it could be made somewhat compatible with the VT status line, and at least having an option for applications to control it with the various status line escape sequences (not necessarily from day 1, but something to consider in the design).

[mdtauk]

You could display the amount of time it took to complete the last command maybe, as a Status Bar option.

[egmontkob]

@mdtauk All these things you suggest to display there are pieces of information that are not known by the terminal.

[mdtauk]

@mdtauk All these things you suggest to display there are pieces of information that are not known by the terminal.

I guess not. There may be use cases that could benefit, and other popular terminals do support displaying a status bar.

[egmontkob]

other popular terminals do support displaying a status bar.

Can you give examples please? (I mean, of a status bar displaying a progress bar (progress of what?), local time, the time it took to run a command etc.)

[mdtauk]

other popular terminals do support displaying a status bar.

Can you give examples please? (I mean, of a status bar displaying a progress bar (progress of what?), local time, the time it took to run a command etc.)

There is a plan to add a progress ring to the TabView control's tabs, and it was mentioned in another issue that there is a way to detect progress and the team want to use the tab progress ring to display progress.

https://conemu.github.io/en/Progress.html#progress-on-windows7-taskbar

---

To throw 2¢ in from the Terminal team:

This is definitely a feature I'd look for as well. One thing we want to support in the future is the ConEmu "progress" VT sequences, which can be used for setting the "taskbar progress status" for the terminal. Since we could have multiple tabs, each with their own progress status, I'd love if there was a way to display this status within each tab as well, not just in the taskbar :)

See also #3004

microsoft/microsoft-ui-xaml#1386

[egmontkob]

I said this information is not known by the terminal.

You link to a page mentioning a "simple AI" (LOL) examining the output of several applications and making a guess. Sure, that is a way that can get you a progress bar in certain specific cases.

Terminals don't understand a single bit of semantics about what is happening inside. They just receive instructions and paint their canvas accordingly. Making conclusions, guesses about this, using a "simple AI" or whatever, is certainly a direction developers could begin exploring, but is probably going to take way too much time and way too much ongoing maintenance cost, for way little advantage. I'm not a fan of this direction.

Or, another approach could be to invent some new escape sequence, and patch applications to emit that. Still a lot of work, but at least more reliable, with less ongoing maintenance cost, and potentially can be supported by other terminals too.

Similar story for other ideas you had in mind, e.g. sure a terminal could try to understand when a command was started and when it completed, but it'd be extremely fragile. Or it could be properly designed and then explicitly implemented in relevant apps. Both approaches are extremely costly in terms of developer efforts.

[mdtauk]

I said this information is not known by the terminal.

You link to a page mentioning a "simple AI" (LOL) examining the output of several applications and making a guess. Sure, that is a way that can get you a progress bar in certain specific cases.

Terminals don't understand a single bit of semantics about what is happening inside. They just receive instructions and paint their canvas accordingly. Making conclusions, guesses about this, using a "simple AI" or whatever, is certainly a direction developers could begin exploring, but is probably going to take way too much time and way too much ongoing maintenance cost, for way little advantage. I'm not a fan of this direction.

Or, another approach could be to invent some new escape sequence, and patch applications to emit that. Still a lot of work, but at least more reliable, with less ongoing maintenance cost, and potentially can be supported by other terminals too.

Similar story for other ideas you had in mind, e.g. sure a terminal could try to understand when a command was started and when it completed, but it'd be extremely fragile. Or it could be properly designed and then explicitly implemented in relevant apps. Both approaches are extremely costly in terms of developer efforts.

The reply to that comment is about making the progress display in the Tab itself. If it can display in there, it could also be displayed in a Status Bar.

Anyway, the original concept teaser design has a Status Bar, and my point is more about where that status bar is rendered.

If there is a real lack of things to put in a status bar, then it could be opened up to extension programmers. Even a looping gradient or fun ASCII animation could be enough reason for a bar.

[zadjii-msft]

I can't tell y'all how many times @DHowett-MSFT and I have had the exact same discussion with @bitcrazed on this subject 😋

[egmontkob]

my point is more about where that status bar is rendered.

There are plenty of great UI proposals for that. My point is: where will you get the data to be displayed there? It's an extremely hard question.

it could be opened up to extension programmers.

Could be? Yes. Should be? I'm really not convinced. How many programs would use it? Probably hardly any.

Even a looping gradient or fun ASCII animation could be enough reason for a bar.

I firmly disagree. Invent a new escape sequence, a quasi new standard, allocate screen real estate (and preferably make a promise that it'll stay there forever), just to see an app or two do some fun ASCII animation? I would definitely not do this.

[j4james]

Or, another approach could be to invent some new escape sequence, and patch applications to emit that.

Or, as I mentioned before, you could support some of the existing sequences: DECSSDT, DECSASD, DECLTOD.

[DHowett-MSFT]

For progress specifically, that'll be this:

I could have sworn we had an internal issue for this feature, but it never got migrated to github it appears....

FOUND IT! MSFT:18258406. Here are the relevant notes:

sequence	description
ESC ] 9 ; 4 ; st ; pr ST	Set progress state on Windows 7 taskbar and ConEmu title. When st is 0: remove progress. When st is 1: set progress value to pr (number, 0-100). When st is 2: set error state in progress on Windows 7 taskbar

It's nonstandard, but so go most OSCs. 😄

[egmontkob]

Isn't OSC 9 the desktop notification of iTerm2, or something like that?

[DHowett-MSFT]

Looks like it is, yep!

[Jaykul]

The things that are really worth having on a status bar are things that the shell doesn't know about, like the zoom level, or that change during the execution of a command, like "how long has this command been running" or "what input has been typed" (because it might not have been read by the process yet) ... or the current input/output encoding.

I'm sure a case can be made for additional controls, like maybe a slider for changing the window opacity or zoom level, or a button to send CTRL+C, or to open the command palette...

But yes, a lot of people would take information that would be better in your prompt (so there's a record of it left behind in the buffer) and happily see just the current value in the status bar instead...

1. Current directory
2. Git branch
3. Current user
4. Console encoding
5. Date and time
6. Duration of the previous command.

[mdtauk]

In the spirit of the customisation encouraged with Terminal - how about allowing the user to choose what appears in a status bar?

You could use a shorthand for various content and then display what is chosen.

[DHowett]

I don't disagree that the status bar could be used to display things the shell doesn't know. However, it also cannot be used to display things the terminal doesn't know.

Unfortunately, that includes things like...

• the working directory
• how long a command has been running after having been spawned by the shell
• the output codepage of the connected application
• the current user¹

Footnotes

1. I mean, it could display your current login user... but it can't know that when I ssh foo my username goes from being Dustin to being dhowett. ↩

[wekempf]

The shell should be in control of what's displayed, much like it is with the title. Basically something like https://mdgrs.hashnode.dev/building-your-own-terminal-status-bar-in-powershell but applied to the status bar instead of the title bar. There's all sorts of customizations done out there, targeting the prompt, the title and evidently the status bar. Just make this controllable from the shell and let users go to town. It sounds like https://vt100.net/docs/vt510-rm/DECSASD.html is intended to do just this.

The shell knows most of what a user would want displayed, for the things it doesn't know you could specify certain placeholders that the terminal would replace and fill in. Give a way to write to the status bar and third parties will find ways to make it easy to create "beautiful" status bars, and end users will customize it to their needs.

I've customized my prompt to the point of it being distracting, with information that is stale as soon as it's displayed, etc. Having a place to display real time information that's always visible can elevate the experience tremendously. The DynamicTitles linked above really illustrates what can be done, it's just unfortunate that the title bar isn't a good place to display a lot of this, especially with tabs.