General TreeView Question

[adrianstephens]

There are really only two UIs open to extensions - Treeviews and Webviews; and the webview docs start with a 'only if you really must' disclaimer.

Although the Treeviews extensions create look and feel like the views used throughout vscode, the treeview api has a lot of limitations that make it impossible to recreate them fully, leaving extensions looking and feeling clunky in comparison.

A few simple examples:
Labels can't be edited (as they can in the file explorer and watch panel), so extensions have to use quickpick.
The font can't be changed, so we can't use a mono-spaced fonts, italics, bold, etc
The labels are monochrome
Drag and drop doesn't show insertion lines like the watch panel can.

Obviously there is an internal treeview api that is capable of much more than the one exposed to extension developers. So my actual questions are:

• Does the exposed API wrap the internal one with added imposed limitations, or is it a different implementation (because it's running in a different host?) that only supports the exposed functionality?
• Is there any reasonable chance of feature parity with the built-in views? (#170063, #115365, #48754 are years old).
• Is the idea that the treeview API is only for simple cases, and anything else will bypass it entirely and use a webview?
• Has it ever been suggested or discussed that all vscode UI should be built using the same API that extensions use? Not to make vscode look worse, but to make the API better.