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

Add an optional status bar to the bottom #3459

Open
5 tasks
zadjii-msft opened this issue Nov 6, 2019 · 34 comments
Open
5 tasks

Add an optional status bar to the bottom #3459

zadjii-msft opened this issue Nov 6, 2019 · 34 comments
Assignees
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Area-UserInterface 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.
Milestone

Comments

@zadjii-msft
Copy link
Member

zadjii-msft commented Nov 6, 2019

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

@zadjii-msft zadjii-msft added Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Product-Terminal The new Windows Terminal. labels Nov 6, 2019
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Nov 6, 2019
@ghost ghost added the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Nov 6, 2019
@egmontkob
Copy link

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link

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
Copy link

mdtauk commented Nov 6, 2019

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.

59804721-0fb2fd80-92e7-11e9-9cd6-7d7a242feda5
57567807-a500cf00-73d6-11e9-806f-39cc316e916b

59804746-2194a080-92e7-11e9-8ee7-cde122dceb64
57567803-9fa38480-73d6-11e9-827a-549de5d65a62

@DHowett-MSFT
Copy link
Contributor

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

@mdtauk
Copy link

mdtauk commented Nov 6, 2019

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
Copy link

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
Copy link

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
Copy link

mdtauk commented Nov 6, 2019

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
Copy link

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
Copy link

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
Copy link

driver1998 commented Nov 7, 2019

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
Copy link

mdtauk commented Nov 7, 2019

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.

image

image


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
Copy link

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
Copy link
Collaborator

j4james commented Nov 7, 2019

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
Copy link

mdtauk commented Nov 7, 2019

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

@egmontkob
Copy link

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

@mdtauk
Copy link

mdtauk commented Nov 7, 2019

@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
Copy link

egmontkob commented Nov 7, 2019

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

@egmontkob
Copy link

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
Copy link

mdtauk commented Nov 7, 2019

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
Copy link
Member Author

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
Copy link

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
Copy link
Collaborator

j4james commented Nov 7, 2019

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
Copy link
Contributor

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
Copy link

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

@DHowett-MSFT
Copy link
Contributor

Looks like it is, yep!

@Jaykul
Copy link
Contributor

Jaykul commented Mar 24, 2023

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
Copy link

mdtauk commented Mar 24, 2023

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.

image

@DHowett
Copy link
Member

DHowett commented Mar 24, 2023

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 user1

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
Copy link

wekempf commented May 3, 2023

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.

@xborke
Copy link

xborke commented Sep 1, 2024

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.

image

image

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.

is it possible to use Tmux's status line in Windows Terminal's Powershell section?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Area-UserInterface 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.
Projects
None yet
Development

No branches or pull requests