Generalize SSH explorer to also be usable for Containers and WSL

[kieferrm]

Remote-SSH provides an explorer that shows configured SSH boxes and the history of folders and workspaces opened on those boxes. It also provides an inventory of forwarded ports as well as a help section.

We'll generalize this explorer to become more of a Remote explorer rather than being specific to SSH.

Approach:

• We'll move the Remote Explorer into the core.
• Conceptually, the explorer will have three main sections: available remote targets, connection details, help. Extension will contribute views to those main sections using when clauses testing remoteName.
• Extensions should contribute available targets when the window is local.
• Extensions may contribute available targets to remote windows with a remoteName they don't own/contribute. (We'll see how that plays out and whether we need to restrict this.)
• Extensions will only contribute connection details, for a remoteName they own/contribute.
• The help section will resemble the current help section of the SSH explorer. We'll introduce a custom contribution point. In a local window, when the user selects a help entries, we present a quick pick with the contributing extensions. Once the user chooses one, the appropriate help topic is opened. In a remote window, the help entries open the help topics for the extension contributing the active remoteName.
• It will require proposed API to contribute to the Remote Explorer.

Notes:
The SSH Explorer support VM status indicators as well as Start and Stop actions for VMs (if the Azure Account extensions runs as a UI extension). This also makes sense for Remote-Containers. So, we need to establish guidelines for icons, action naming, etc.

[rebornix]

Here are some mockups of what the remote explorer might look like and proposals of how we can implement the remote explorer and data provider in the core.

Targets

Firstly, we want to show an Available Targets section at the top of the Remote Explorer viewlet if there is a remote resolver registered. It looks almost the same as Connection section in SSH Explorer.

If the window is local and we have more than one available remote solvers, we can display them all in the section, similar to how SCM handles multiple repositories. Targets tree views are grouped by remoteName

Connection Details
Connection details can probably be a tree view registered by "views/remote/connection" and it's only displayed when the remoteName matches.

Help Section

This one a bit hard to accomplish through static tree view contribution. We may want to add a new contributions type, for example

{
  "remoteHelp": {
      "getStarted": "https://code.visualstudio.com/docs/remote/ssh#_getting-started",
      "documentation": "https://code.visualstudio.com/docs/remote/ssh",
      "feedback": "https://twitter.com/intent/tweet?hashtags=remote,ssh&text=%40code"
    }
}

---

To archive above experience, extensions contribute the data by static view contribution or programmatically.

The former one requires us to register two tree view sections views/remote/targets and views/remote/connection in advance, and then extensions contribute tree views under them. The challenge we have with this solution is currently our view/container infrastructure doesn't support nested tree view contrition (contributing child tree views to the same tree view).

The latter one is leveraging APIs we already have: TreeDataProvider. Extensions can simply provide data by registering data provider for specific tree views

namespace remote {
  export function registerTargetsDataProvider<T>(treeDataProvider: TreeDataProvider<T>): Disposable;
  export function registerConnectionDetailsDataProvider<T>(treeDataProvider: TreeDataProvider<T>): Disposable;
}

[rebornix]

The Remote Explorer is already added in the core and remote extensions can now contribute to it. Guidance is written down in https://github.com/microsoft/vscode-remote-release/wiki/Remote-Explorer . cc @alexr00

Currently the Remote Explorer doesn't validate remoteName yet as extensions contributing remoteName don't contribute tree views yet. Next steps are

• Move SSH explorer contributions into SSH extension
• Add entry filtering for Help section based on remoteName in remote window

[nikmd23]

Hello all,

I noticed in @rebornix's screenshot that the grouping mechanism being used is the tree view itself.

In previous conversations we had discussed using separate panels. Something potentially like this:

I'd love to learn a bit more about the thinking of moving towards a tree view, and the pros and cons of that approach. @rebornix or @kieferrm, is that something you could help me with?

[rebornix]

@nikmd23 the screenshot I posted above is a rough idea while exploring this issue. Going that route is a bit complex (as we don't have facility for that yet) and leading to quite a few questions (what the API looks like, how to handle title actions for tree views, etc). That's why we'd love to do the simple way for now, please see https://github.com/microsoft/vscode-remote-release/wiki/Remote-Explorer for more details. With that you should be able to archive a similar UX as the screenshot you posted above.

[alexr00]

Screenshot of Remote Explorer with Containers: (yes, there is a bug in the name of the container under Attach Containers)

Long gif showing it in action:

[Chuxel]

@alexr00 @rebornix This is awesome!

One note on containers - it would be great to show the location of the devcontainer.json file in the details. One piece of feedback we got was that when using the "image" property, you can't easily tell which container is the one you want since the image name would be the same for multiple containers (e.g. ubuntu:18.04). That's available in the labels for the container - I ended up adding a hacky docker ps command to docs since it wasn't visible in the Docker extension.

[nikmd23]

This is great @alexr00! I'm pumped about this one! 🕺🏻

[rebornix]

The Remote Explorer is shipped with Insiders and will be out with next Stable. Closing this one and we can create issues to track following improvements.