Implement contributable tree views

[sandy081]

Implement contributed views those can be shown in Explorer as trees.

• Contribution point to describe a view
• API to register a tree data provider for the view
• Multi views explorer

Actions can be contributed to the following locations by giving proper when clause

• View titlebar: view/title
• On item:view/item/context

Example:

"contributes": {
    "menus": {
         "view/title": [
	    {
		"command": "extension.commandId",
		"when": "view == viewId",
		"group": "navigation"
	    }
         ],
         "view/item/context": [
	     {
		"command": "extension.commandId",
		"when": "view == viewId && viewItem == contextValue",
	      }
          ]
   }
}

More

• Remember the view collapsible state and size

Deferred

• View visibility
• Extract icons from the resource Uri
• Tree state persistence
• Customizable location of the view inside explorer
• Get children in pages
• Ability to update the view label

[formulahendry]

Awesome! Look forward to this API! 😃

[bpasero]

FTP Explorer:

I played around with the API and here is some feedback:

• overall love the simplicity of the API 👍
• not restoring the UI state on restart is a very tough one for me. at the minimum I think we should restore the view expansion state and size. my scenario is a FTP explorer and always having to click it to show the contents is very annoying at times
• in my case I am showing files in the same way the explorer does. I would like to reuse the same icons the explorer uses for files without me having to introduce new icons. for that, maybe the API should allow a TreeItem to have a resource URI that we then simply take as ResourceLabel and support icons with? Even more, if we had an associated resource, we could automatically open a document with that resource on click?
• API: registerTreeDataProvider is not really related to the view in terms of naming, I suggest registerView (similar to registerCommand)
• having a generic onDidChange on both text document provider and tree data provider is odd, because that way I cannot have my class implement both interfaces (their type is different)
• suggestion: we should probably come up with a way to contribute views to a specific position in the same way I can set the location of an action when contributed into a menu. people will have the desire to put a view to the top or in between opened editors and the explorer itself

[sandy081]

@bpasero Thanks for the feedback.

• Agreed that, we need to support persisting view state. There are multiple use cases, one is what you mentioned and other is if there is a view that shows different tree based on the document opened. Then state should be stored when switching back and forth.

• Good point to include resourceUri for enabling file icon themes

• I see your point about registerTreeDataProvider. I think what we are using this API is to register a data provider for a view. So we can name it registerTreeDataProviderForView. View is already registered in package.json and having registerView again might be confusing

• Reason to have a generic onDidChange listener is to support change on both element and root. To make it more specific and align with the provider, I can call onDidTreeDataChange.

• Yes, you can contribute actions to the following locations: view/title and view/resource by giving proper when clause. Eg:

"view/title": [
	{
		"command": "extension.commandId",
		"when": "view == viewId",
		"group": "navigation"
	}
],
"view/resource": [
	{
		"command": "extension.commandId",
		"when": "view == viewId && resource == contextValue",
		"group": "navigation"
	}
]

• Positioning of views, yes thought about it. Was thinking providing a property index in view contribution for the position of the view.

[bpasero]

Re: registerTreeDataProvider

I just like the symmetry between contributing a command via package.json and having a method registerCommand

Re: onDidChange

That is fine, I am more concerned about the name clash with the text document provider. If all providers have the same event onDidChange, you cannot implement all the interfaces in one class in my extension. I suggest onDidChangeTextDocument (unfortunately we cannot change this anymore as it already is API) and onDidChangeTreeData.

Re: Positioning of views

Instead of introducing a new concept with index, why not reuse what we do for menus where you have menu item groups?

[bpasero]

Another thing that might come up is being able to change the view label dynamically. For example for the ftp explorer I could maybe show the currently connected host in there.

[sandy081]

I am having an idea to expose Views as an API just like other objects (editors, extensions, documents) and have some methods to control the view. This would be next step.

[Gama11]

in my case I am showing files in the same way the explorer does [...]

I have a very similar use case - I want to implement a tree view that shows a few folders (of dependencies) outside of the current workspace. That means tree view items should otherwise behave exactly like those in the existing file explorer. They should:

• have a tooltip showing the URI
• have the usual context menu for rename / delete / etc
• support drag and drop into editor tabs or to move them around between folders
• there might be more I'm not aware of

Maybe this could be tied to the planned resourceUri?