Vscode: Enhance custom tree views

[sandy081]

Continuation from #26948

• [x] Conditional visibility - #29436
• [x] Managing views - #30120
• [x] Tree state persistence - #40018
• [x] Navigation group for menu action in tree item - #28634
• [x] Extract icons from the resource Uri - #41535
• [x] Improve view management - #35462, #41071 #31485 #30249

[chrmarti]

I can register a command for selection changes and menus, but I don't see a way to register a command for the "open" mouse gesture (usually double-click). That would make sense to have.

[Thaina]

One of my case is cloudant design database. It is a json that contains javascript string

What is a plan if I want to make a tree of json and show js icon for a child that is javascript string?

[atian25]

https://github.com/Microsoft/vscode-extension-samples/blob/master/tree-view-sample/USAGE.md is outdated.

[sandy081]

@atian25 Thanks for pointing it out. Will update it.

[kubawolanin]

Hello,
Is it possible to provide icons from external URL? My extension calls an REST API for the items to be displayed in the TreeView. They come with svg icons and I thought it might be cool to have them.

I've tried to embed them inline with data:image/svg+xml; but with no luck.
Thank you for all the tremendous work!

[Chillee]

Is it possible to obtain the default vscode icons for the iconPath? I would prefer to be able to delegate the iconPath to the default icons instead of specifying one myself.

Ah nvm I see it was mentioned here: https://github.com/Microsoft/vscode/issues/26948#issuecomment-303036936

[alefragnani]

Hi @sandy081 ,

I don't know if I'm missing something, but I didn't find a way to have _direct access_ to the TreeItems, after they are created/provided using getChildren and getITreeItem.

I mean, let's suppose I need to add/remove a _level 0 node_. Instead of simply push/splice another TreeItem in the TreeDataSomething, I have to call onDidChangeTreeData(null) event and reload the entire tree. Similarly, if I need to *add/remove/rename a _non level 0 node_, I have to had _backups_ of the TreeItem previously provided, search for them when I need to update their children, and to call onDidChangeTreeData(foundTreeItemNode) to update only their children.'

As I said, I don't know if I'm missing something. But if I am, could you please point me in the right direction? Otherwise, I thing that you could expand the API to scenarios like this.

Thanks for your help

[sandy081]

@alefragnani Yes, It is PULL instead of PUSH. It is designed to register a data provider where the core can ask for data (similar to other providers in API). Regarding triggering changes, you do not need to have the back up of TreeItem but element of type T. If you do no want to store, you can always provide element of type string which you can resolve uniquely from your data model.

[alefragnani]

@sandy081, I understand (and agree) the decision to use a PULL design, but I expected to have _a bit more APIs_ to access/look for the data already provided. Still, I also understand that this API is in early stages, just recently published, and the current issue exists for the exact purpose to _enhance it_ 😄 .

I ended up adding a reference to my model inside the TreeItem, so I can _look for it_ when the update events are triggered, by the model. The backup was limited only for the Level 0 nodes, because they are re-created only if I call onDidChangeTreeData with null as parameter.

I would like suggest a few enhancements:

• [ ] Built-in commands to expand and collapse, located in the tree's title (like the one that already exists in explorer/find trees)
• [ ] Built-in property/event to display a notification counter in the tree's title (like the Extension's panel)
• [ ] Add an Secondary Command to TreeItem, which should be executed if you Ctrl + Click the node
• [ ] Add an Secondary Command to TreeItem, which should be executed if you Double Click the node
• [ ] Add a Hint to TreeItem

Thanks

[eamodio]

I would add a few more to that list:

• [ ] Provide an API to add a dynamic "secondary" name to a view
  
  
  
  • For example -- something like _GitLens -- branches_ where _GitLens_ is the name of the view, the _--_ is a vscode controlled separator (or unneeded if the styling or weight is different between the name and secondary name), and _branches_ is a dynamic additional name for a view to provide more context
  
  
• [ ] Support the navigation group for TreeItems -- so that they can have toolbar buttons (like search and source control viewlets)
• [ ] Provide a way to set a decoration on a TreeItem -- like strike-through, etc
• [ ] Provide a secondary icon (on the right) similar to the source control viewlet
• [ ] Provide a way to support double-height TreeItems (similar to the way you can in the quickpicks)

I'm assuming that adding a Hint to TreeItem is about customizing the tooltip of a TreeItem -- if so 👍 otherwise, I would like to be able to customize the tooltip of a TreeItem 😄

Thanks for the consideration!

[weinand]

I suggest to add #33371, #30535, and #39340 to the list and give them high priority.
Without those fixes all the other other items are only "nice to haves".

[PrashanthCorp]

Does the ' Ability to update the view label' concern tree items? I'm currently looking at a way to update the Tree-Item label without having to fire refresh (to preserve the state of the Tree-Item's children). For example, this issue in the vscode-cosmosdb would be easily solved if this functionality was provided. :-)

[weinand]

Another high priority item is #40018

[mike-lischke]

I also have a number of things I'd like to see in a tree. Here's a list of items I mentioned already in #28338.

• [ ] Not just a single icon per tree, but one for each node (just like the file tree has).
• [ ] Colors for text; markdown support would be awesome.
• [ ] Tooltips/hovers per node.
• [ ] Read and set selection status (for multiple nodes) programmatically.
• [ ] Check box support is also a pretty common requirement.
• [ ] Multi column support! This content:

would then show much nicer. All the individual values nicely aligned.

• [ ] Support docking, so that views can be spread accross all the available space. Currently I have 10 views stacked vertically. Even on a 4K screen this is all but easy to consume.

[dakaraphi]

@mike-lischke
In regards to

Support docking, so that views can be spread accross all the available space. Currently I have 10 views stacked vertically. Even on a 4K screen this is all but easy to consume.

There is another issue I don't see referenced here that I believe is same or related #41686

[sandy081]

Closing this item as mentioned items in the description are done. I would request to create a separate issue for each of your feature requests or bugs as it is becoming very difficult to track in a single item. Thanks for understanding.

[mike-lischke]

@sandy081 I don't consider it as appropriated action on this issue to simply close it and have everyone do their own issue filing. It's a pretty nice collection of FRs all revolving around the same element and the issue itself started out as a collection of ideas/wishes. Usually I also prefer to separate issues, as it's just better to solve each of them. But this issue is more about development of a core element that needs consolidation of the individual requests. Of course each FR then has to go into its own Github issue, but a central collection/discussion issue is pretty useful too.

[sandy081]

@mike-lischke The pain point here is that these feature requests are spread across multiple comments and its very hard to track them and to prioritise.

You are right that this issue was created initially to capture improvements to be done to custom views. But they are scoped to those listed in the summary. This could get easily side tracked by multiple feature requests in multiple comments. They are so important that I do not want to miss them.

Hence, I asked to create an issue per feature request. Hope it makes sense.