TreeDataProvider: allow selecting a TreeItem without affecting its collapsibleState

[patrys]

Currently clicking an item will both select it and change its expanded/collapsed state. This results in very weird UX as you need to click the items to interact with them.

I have an extension that provides a tree outline of the currently opened file and clicking a class name will currently select that class in the editor and at the same time expand/collapse its children in the tree view.

Related: patrys/vscode-code-outline#24

[eamodio]

Somewhat related to #28632

[weinand]

I'm bumping the severity of this since it makes the tree very difficult to use for users.

[sandy081]

@weinand May I know the explanation behind its importance?

@patrys @eamodio May I know your expectation in this case. Is your request is to support command only for leaf items?

[weinand]

Today I learned that all VS Code trees behave like this.

So all VS Code trees collapse/expand when a node is selected.
For the standard VS Code trees (e.g file explorer) this is not a problem because the only purpose of selecting a non-leaf node is to expand or collapse it, so selecting a non-leaf node is not really needed because the node itself is never fed into an editor.

For custom trees the story is not so clear:
In a custom tree a non-leaf node might feed into an editor and expanding its children could be an expensive operation. So it is questionable whether both purposes should be coupled into one gesture.
If a user only wants to select the node in order to open it in an editor, this is not possible without expanding all children at the same time.

Since the current behaviour is consistent with the other VS Code trees, I think this is not a bug but a feature and we can remove the "important" flag (and there is no need to implement this feature in this milestone).

[patrys]

@sandy081 My extension shows a code outline so containers can be classes while leaves are functions, I'd very much like to support commands at all tree levels in a way that does not affect the tree state.

[eamodio]

For me, it is less about the user clicking on an item, and more about having an api (way) to not only set focus to the tree, but select an item -- and ideally control whether or not it expands when selected via that api.

[weinand]

@eamodio this is a different issue. You are asking for new API which is already covered by #30288.

[eamodio]

@weinand very true -- I had originally wanted something like this (where the user controlled it -- I opened #28632), but while I still think it could be useful (for example in GitLens, there are nodes in the tree that both have children and could support a click command themselves) I am worried about the user experience of it. Unless the whole tree behaves the same way, I think it would be strange for a user, if sometimes clicking on a node would expand it and sometimes it might execute a command. Anyway my 2c :)

[patrys]

I think it would be less surprising if the tree behaved more like native platform trees: usually clicking the name selects/activates items while clicking the chevron or pressing the left/right arrow key collapses/expands the tree.

[sandy081]

@eamodio I agree with your point about consistency. As mentioned, all tree in VS Code are now consistent in how to expand, collapse and selected. In order to separate commands from expand/collapse, how about exposing primary commands on nodes. Eg:

I would still allow command on selection which extension authors can decide to have or not to have on leaf nodes and parent nodes.

[patrys]

@sandy081 How do you imagine this helping with a code outline type of extension?

[sandy081]

@patrys Agreed, it wont help such extensions. Unfortunately I have to be consistent with current tree behaviour in VS Code.

[zigmondy]

Running into exactly same issue. Can you please prioritize the fix and allow extensions to override the behavior?

[TomasHubelbauer]

This is super annoying, I've upvoted both this and #28632 (where the last comment is about awaiting feedback to justify it but three months in VSCodeBot closes down the conversation, oh, how I love VSCodeBot) but feel like I need to vouch for the importance of considering this with a comment, too! The UX on custom trees is extra trippy, certainly unpleasant and I wish it can be rectified.

[patrys]

I wish I saw #28632 earlier as my extension is affected by it but I guess it could be seen as part of this issue (as there needs to be some folding mechanism).

[sandy081]

May I know every body asking for this requirement is for Outline views? Or is there some other type of custom view needed this? If so, can you please mention.

Thanks

[TomasHubelbauer]

My VS Code extension MarkDown To-Do would benefit from this. I need to be able to let the user click a to-do item in my custom tree view to open the corresponding editor and line or let them expand subitems.

[DanTup]

@sandy081 Ours is an outline view, however it's kinda specialised (doesn't map directly onto Code like a normal outline, and we'd probably also have a standard outline) if that's relevant (eg., if you built in a standard outline view, I don't think that's solve the problem for us).

[zigmondy]

Hopefully the capability to suppress collapse on click is built some day. VS code tree view extension feels so limited because of this issue :( !!!

[sandy081]

For me, it is less about the user clicking on an item, and more about having an api (way) to not only set focus to the tree, but select an item -- and ideally control whether or not it expands when selected via that api.

@eamodio I suppose your requirement mentioned here is supported now using the existing APIs

[sandy081]

Here are the two proposals I can think of as solution

1. Have a tree property like expandOrCollapseOnTwisty and let every node in the tree honours this.

2. If a tree node has a command, then Expand/Collapse it only when user clicks on twisty, otherwise do it when user clicks any where on the node.

[eamodio]

@sandy081 AFAIK there still isn't an api to select an item in the tree and have it expand or collapse though right?

With regards to the proposed, I like #2 -- implicit and imo will do what you want (even though the experience is inconsistent it could be desirable depending on the usage).

[sandy081]

@eamodio There is reveal API to select, but not to expand or collapse. Is there an issue you opened where we can discuss about it?

I also liked #2 and implemented.

• If a node provides command, then node is expanded/collapsed only when user clicks on the twisty. Also, command will not be executed when user clicks on twisty.

[eamodio]

@sandy081 We talked about it back during the reveal api discussion, but I don't have a strong enough need for it at this point, so I'll leave it be ;)

[DanTup]

@eamodio I haven't tried it, but does changing collapsibleState and then fire an update for the node work? (it's not nice, sure, but if it works?)

[TomasHubelbauer]

This has not shipped as a part of the June milestone, right? Can the milestone be updated to the next one in case this is projected to land in it?

[sandy081]

@TomasHubelbauer This is fixed in June milestone and is available in the latest 1.25 (June) stable release.

May I know why do you think so?

[zigmondy]

I've also verified in latest version 1.25 and works beautifully!! Thanks for addressing it.