Position the output window and debug console in a horizontal panel

[stevencl]

To improve readability of text inside the output window and debug console and to avoid the problem of these windows taking the position of an open editor we should display the output and debug console in a separate horizontal panel. For example:

This panel should have the following characteristics:

• Should be as wide as the main editor area
• Does not participate in quick open or recent files list
• Does not contain tabs to switch between different providers such as output and debug console (hence does not support viewing output and debug console simultaneously)
• Can be opened manually from main menu commands or automatically based on specific actions (such as pressing F5)
• Is visually distinct from an editor
• Can be docked to the side
• Can be resized to a maximum height of 66% of the available height and resized to a minimum height of 20% of available height (these numbers can and will be tweaked as we experiment with this)

[bgashler1]

Adding myself as a participant

[bgashler1]

@bpasero Please see the comments on this issue #1876 (comment)
for current design proposals. Let us know your thoughts.

[isidorn]

Done with the PR #2042 and #2146

[jrieken]

Should be as wide as the main editor area

@stevencl Why is that and not as wide as the VS Code window? I understand the main requirement of the panel show to output without wrapping hence getting as much h-space as possible

[stevencl]

There are two reasons: First is that we tried out a design with full horizontal width and compared that to a design that is as wide as the editor area. In our studies, nobody expressed a preference for the full width panel.

Secondly, one of the main ways we achieve flow in the product is by maintaining a horizontal order, or flow. For example, in the standard layout it starts with the activity bar on the left - the user clicks on an icon and a viewlet appears to the right of the activity bar. From within the viewlet, the user chooses an item and, if that item contains any content, the content is viewed in the editor area to the right of the viewlet.

For all of the content that we considered that might show up in the horizontal panel they were all related to content inside a viewlet. Details about the running program for example or details about git commands or running tasks. All of which have a 'parent' inside a viewlet.

We also considered other items that might show up in here in the future such as errors and warnings and also believe that those are related to content inside a viewlet.

So a combination of maintaining the sense of flow through the product, the relationship between different components and our experiment comparing different designs led us to this requirement.

[jrieken]

That makes sense, tho the parent-child metaphor is little harder to explain when it comes to things like Omnisharp or Task output.

TBH my motivation is that even with the redesign it's painful to switch between output and debug (it's even worst cos they aren't in editor history anymore) and if we keep adding stuff like errors&warnings it won't get better.

When using the full width of the window I see how we could use the side bar to put in a different set of switcher icons - which then would act as parent for that panel.

[stevencl]

Thanks, that was one of the designs we tried too. One of the key things we want to ensure with this design is that we maintain the lightweight feel of the overall product and optimise the real estate for code and related assets. The design you've suggested above was one of the ones we considered but we don't want to start to litter the activity bar (and status bar, another design we considered) with buttons that toggle the visibility of a UI panel.

So why have them in the activity bar then for explorer, debug, search and git you might ask? The activity bar provides access to the main activities that a developer performs. It's not simply a place for buttons which turn panels on and off. We didn't feel that the output button and debug console were on the same level as the other buttons in the activity bar hence we didn't go for this one. On top of this, we were not keen on the full width panel for the reasons I listed above.

We tried another design with these two buttons and the panel taking the width of the editor but that still falls foul of the principle laid out above (and doesn't look good).

We have added actions with keybindings for switching between the panels, is that something that you might get used to using? What do you think about the shortcuts, are they memorable? We also have a shortcut for toggling the whole panel (Ctrl-J) which brings the panel up in the same state it was in when it was closed (ie, showing debug or output).

We've considered all sorts of ways in which we provide visible UI affordances to toggle the visibility of this panel but we ended up backing away from them all because of the risk that the UI becomes cluttered and we end up losing the lightweight feel of the whole product.

For errors and warnings the design we propose is that the errors and warnings status area in the status bar when clicked, will open the panel with the list of errors and warnings.

[jrieken]

We also have a shortcut for toggling the whole panel (Ctrl-J) which brings the panel up in the same state it was in when it was closed (ie, showing debug or output).

Yes, I know and it's similar to Ctrl-B for the sidebar. That I use a lot and I can see myself using Ctrl-J in the future but the issue that I never use the keybinding to reveal the sidebar and jump right to the debug view. I always use the buttons for that.

[mredbishop]

I frequently want to keep output visible but whenever there is an update to the debug window it displays hiding the output window. Is there a way to have both displayed as it's driving me mad :) ?

[bgashler1]

@mredbishop, thanks for sharing this frustration. I created an issue for this #3597.