Vscode: Investigate to rewrite workbench layout using grid widget

[bpasero]

Given the introduction of the grid widget, we should explore to use it as the driver for the workbench layout, at least for the parts that are connected via sashes:

• sidebar (left / right)
• panel (bottom / right)
• editor area

Related issues:

• Allow 100% panel width even with the explorer view is open #42149
• Provide workbench.panel.location "left" option #37877
• Provide workbench.panel.location "top" option #50984
• Panel and viewlet on right should have a border between them #37373

Grid widget prerequisites

• [x] allow to mark a specific view in the grid as the one to resize when the outer container grows (this is to make sure the editor area always increases in size if the window gets larger)
• [x] allow to "snap to hide" so that e.g. you can use the mouse to make the sidebar small enough that it hides and move back to show it again

[bpasero]

Some prerequisites for the grid widget before this can happen:

• [x] allow to mark a specific view in the grid as the one to resize when the outer container grows (this is to make sure the editor area always increases in size if the window gets larger)
• [x] allow to "snap to hide" so that e.g. you can use the mouse to make the sidebar small enough that it hides and move back to show it again

[joaomoreno]

Splitview now supports:

• resize priorities, which allows to mark a specific view in the grid as the one to resize when the outer container grows
• snap to hide

🎆

Another related commit: c01cf1d166bf33a7efc69d3db9c7774af4ee6ea2

[joaomoreno]

Gridview now supports all of that too! 🎉 Getting closer

[bpasero]

Awesome 👍

[costincaraivan]

This looks really cool, if it's what I think it is. One thing I'd be curious to know - would this include the possibility of having multiple terminal splits/sections as part of the grid?

That would enable some great workflows available when working in a terminal environment, but with the extra Visual Studio Code polish and better debugging experience.

Or does this include putting the whole panel in a split? Which definitely represents progress but doesn't get Visual Studio Code all the way to what I'm proposing 😃

[joaomoreno]

This looks really cool, if it's what I think it is.

This is very likely not what you think it is. Though we appreciate your passion.

This issue aims to use the grid widget for layouting. It will not introduce any new layouting features. It will not enable you to move viewlets around. It is a purely engineering issue to clean up some old layouting code.

[costincaraivan]

This is very likely not what you think it is.

😞 So it's clean up/refactoring. Oh well, I imagine it's needed to move forward 👍

Is there some plan/UX thing about making the terminals more flexible/will there ever be the possibility of using VS Code in a tmux-like fashion? It's so, so close to it. Or, alternatively, is there some sort of longer term roadmap for 2019, so that I can stop spamming this bug report? 😃

[joaomoreno]

I believe @Tyriar already runs an issue for that.

[Tyriar]

@costincaraivan see https://github.com/Microsoft/vscode/issues/10546#issuecomment-416306717

[Novack]

Hello, I cant grasp some of the slang used to define steps and aims here, but I've been told at #65971 that this work would enable us to relocate Debug panels from side bar to bottom?

[joaomoreno]

@Novack No, this does not enable that.

[Novack]

Ups, thank you.

[sbatten]

@joaomoreno After getting the grid layout mostly working on my branch, it seems the methodology of having to remove parts from the grid and add them back is very costly. e.g. toggling the status bar requires adding the status bar under the editor, but first we must remove the sidebar and activity bar, then we can add them all back. This takes around 200ms in my testing which is far too slow for say toggling the menubar in full screen. Would it be possible to hide views without changing their membership in the grid? I can fake this now by setting the size to 0 but this requires a snap value and changing the minimum size (and also adds a sash to resize elements).

Another thing I noticed is that adding or removing a view essentially relays out the grid so I can't batch operations. Anyway to do that?

[joaomoreno]

toggling the status bar requires adding the status bar under the editor, but first we must remove the sidebar and activity bar, then we can add them all back

You're just lacking API on the grid to add the status bar when you don't have a possible reference view.

The current Grid API works great for our editor pane where the user can't move or add an editor into an area without a reference point (under two existing editors). I can add API for you to be able to do that, a different value for the direction parameter.

Would it be possible to hide views without changing their membership in the grid?

Not a good idea because hiding means everything is still in the DOM (perf) and potentially taking DOM focus. Doing that would propagate into implementing enabled state changes all the way down to all the widgets. Removing the views from the DOM is the way to go.

adding or removing a view essentially relays out

If you add/remove views in the same stack frame, layout should only occur once. There's no setTimeout anywhere which would trigger more layouts. Can you show me those multiple layouts in a single stack frame, using the Perf tool?

[joaomoreno]

That extra API needs some extra thought. Let me get back to you on this.

[joaomoreno]

An alternative to adding new API to place views next to branch nodes, would be to simply wrap your views around a view wrapper which can be hidden/shown. Here's what that would look like: https://github.com/Microsoft/vscode/pull/67049/files

Such a view wrapper has show() and hide() methods which will basically add and remove the DOM nodes from the tree as well as notify the grid of the constraint changes. You could wrap all your views with this helper, add them all on startup and conditionally show and hide them on demand.

Would this work for you?

[sbatten]

@joaomoreno oooo will try this today

[joaomoreno]

Didn't actually run it, so might not be complete, but you get the idea.

[dbaeumer]

Moving to Feb.

[marcos-diaz]

Please note that ideal decoupling should not be just about choosing left/right position of the whole sidebar, but the ability of position each element in whatever panel the user wants, i.e. treeview at left, open files at right, and search at bottom... all at the same time!

[sbatten]

closing this item as I believe we have tackled "investigation" :P