Cannot undo "Remove from Side Bar" in explorer

[aefernandes]

• VSCode Version: Code - Insiders 1.15.0-insider

Right click an open folder in the explorer and select "Remove from Side Bar" - this works as expected.
How do you make the same folder reappear? The removal persists across sessions and windows. File->Open Folder does not make it reappear. File->Add Folder to Workspace prompts me to reload for multiple folders, which seems incorrect because I only want one folder.

[andrewmackrodt]

👍 is there a way to restore a folder via editing a config?

[1yefuwang1]

I ran into this problem yesterday, and have failed to undo the folder removal. Is there any workaround to reload the folder to the side bar?

[aefernandes]

Found the solution: Right-clicking the word "Explorer" at the top of the side bar opens a menu where the "Folders" item can be rechecked.

[aefernandes]

To me that wasn't an intuitive place to click - I had to be told about this solution.

I would suggest the following:
On right-clicking a folder name, show a "Hide from Side Bar" option instead of "Remove from Side Bar". This would make the change seem less permanent - I initially assumed that after removing there was no way to get the folder back. (Also true for the sashes in the debug and extensions side bars)

Also perhaps once a folder has been hidden from the side bar, allow the user to right-click the open area beneath the list of open editors and show a menu with a "Show Folders in Side Bar" option.

[eamodio]

This probably overlaps with #30249, but I also find this UI less than intuitive. Although for me I think there are quite a few things at play (from both the user and extension point of view).

From the user pov -- I think having some UI (maybe a vertical ... icon or something) in the Explorer header bar (where you current have to right-click to see the "views" menu) that would trigger the "views" menu (maybe in addition to the right-click?). And then also replicate that icon on the far right of each views header bar which would also bring up that same "views" menu -- could leave the right-click Remove from Side Bar (although I would recommend calling it Hide rather than Remove since it is easily re-shown. Or if you don't want additional UI on each header bar, maybe just show the "views" menu instead of the Remove one on right-click. Personally I would lean to the consistent UI marker -- and if you have that on each view's header -- it is probably unneeded at the root Explorer level (unless only 1 view is visible in which case it should roll up into it).

From both the user and extension pov -- I find it confusing that views with a when clause that isn't met actually show in the "views" menu. I think it would be better if they were completely hidden until they were active. But even if that changed there is tension between the when clause and the user hiding the view. It also makes toggling views via commands quite tricky, because if the user has hidden it (but lets just say that didn't remember they did, or they did it and didn't notice right away how to get it back) and uses a command to show the view, it won't show. Now I definitely get the complication here in wanting to provide the user with the final say on whether or not a view is visible -- but maybe there is an API way for an extension to hook into that an explicitly override it (i.e. not as the default of using a custom view -- you'd have to work for it).

And finally from the extension pov -- As stated above the tension between the when clause and user controlled visibility, limits some usages and complicates others. But worse IMO is that there is no feedback to an extension when the user has decided to hide a view. For some views that might be fine -- because nothing will call into the methods to "provide" the tree, but for more advanced views that may trigger on external sources (active editor change, dirty toggle, etc) there isn't a way to stop listening for events and wasting resources when the view will never even be shown to the user. Maybe there could be either some visibility change callback or I think less ideal using the dispose pattern.

Thanks!

[sandy081]

@eamodio Thanks for the feedback. All your suggestions makes sense to me. Will consider them.

[Vorror]

I would also recommend, the hidden sidebar be a workspace setting.

[hexpunk]

If this becomes a workspace setting (or folder-level setting now that those are technically two different things), I'd love it if we could set this as a user-level setting as well to set certain items as hidden by default. This may dovetail with #35462.

[bchenSyd]

I hide the 'gitlens' sidebar section and spent half an hour try to bring it back with no luck--- until I got here.

It's very counter-intuitive to make it a right click on a secret corner setting, I think it should goes to workspace settings

[tclarke-scottlogic]

Literally had to find @aefernandes' answer (thanks Anjali!) before I could restore the Open Editors. Also confusing that it doesn't update the config file.

Something in the View menu would be my intuitive place to look for a global setting that's disappeared.

Or explain the show/hide in the docs?

[aharpervc]

To me that wasn't an intuitive place to click - I had to be told about this solution.

Same, just got here via google because I couldn't figure it out

[sandy081]

There are two parts to how a view can be shown or not.

1. Contextual visibility: Extensions providing a view can determine when a view can be shown or not. Some nice examples are: Showing a debug explorer only when debug session in on. Show git related custom views only when the current workspace has git repo.

2. User configurable visibility: From the UI, user can be able to show or hide a view. This will always takes the precedence to previous. Currently, we have a consistent gesture to show/hide/discover views. Please see the following video

For better discoverability, I added a new entry called Open View.. in the View menu, which will allow you to explore and access all views.

I will add this information to the docs for discoverability.

So, I would suggest extensions not to have separate actions to show/hide the view which is already supported internally by different UX gestures. I would be happy to know the need or requirements for such actions and try to fit them by enhancing the existing features.

Closing this issue in favour of above improvements. Please open new issues for specific concerns.

[eamodio]

One example I can provide for separate show/hide actions is the GitLens Results view -- it gets triggered by a user action (e.g. searching commits, showing the history of a file, comparing commits, branches, etc). So it is not a valuable view when you haven't "added" something to it (which is why it is hidden by default). I also provide an X (close button) in the button bar to allow a user to quickly and easily get rid of the view UNTIL the next action that should cause it to be shown. If I didn't provide that close command, a user would be forced to use the vscode provided gestures which would stop GitLens from ever being able to show that view again unless the user themselves chose to re-enable it. And since hidden views (via the extension when clause) are not shown (which is a great thing imo), it makes it even more challenging to turn that view back on.

[sandy081]

@eamodio

it gets triggered by a user action (e.g. searching commits, showing the history of a file, comparing commits, branches, etc). So it is not a valuable view when you haven't "added" something to it (which is why it is hidden by default)

IMO this is contextual/conditional visibility. As an owner of the view, extension can come up with such scenarios when the view is made sense to be shown. Another example is an outline view that is displayed only when particular files are open.

I also provide an X (close button) in the button bar to allow a user to quickly and easily get rid of the view UNTIL the next action that should cause it to be shown

This is again adding one more gesture to remove/hide/close the view which I think is not helpful to user. I think what is missing here is ability to open the view using an API which I think is supported for all other core views (problems, search etc) by commands. Having such an API / Command to open a view will improve user experience

[eamodio]

@sandy081 Right, it is all based on contextual/conditional visibility, so there are commands/gestures initiated by the user to will show the view, but without a specific command/gesture for a user to hide the view there are 2 big problems. First, imo, the vscode gesture is not discoverable enough, nor user-friendly enough (but I've hashed that out on other issues), and second forcing only the use of that gesture doesn't provide enough flexibility for an extension -- forcing the user to use the vscode provided gesture completely breaks the usability of the GitLens Results view, since the now the next time the user performs a compare, or a "Show in Results" command, the view will never be shown, because the extension cannot override the the user. This leads imo to be very bad user experience.

For example a user performs a commit search and chooses to show (persist) the results of the search in the GitLens Results view, so GitLens updates the context so the view will show. The view then appears (sadly collapsed in this scenario - if this is the first time and it has never been expanded, but that it another issue). The user is "done" with the view, and without any other option gets "rid" of it using the vscode gesture. Time passes and the user again performs some operation that should cause the GitLens Results view to be shown, but nothing will happen. Now the user might remember that they hid that view and realize to undo it, but there is a decent chance that the user just thinks the GitLens feature is broken. And even if they DO realize it and re-show it, it is FAR from a smooth user experience. Whereas, the experience I provide is FAR smoother imo. The starting scenario is exactly the same, but now when the user is "done" with the GitLens Results they click the X. That's all, and everything will work smoothly, the next time they cause it to re-appear.

While I think an API / command could certainly help, to really address the issue, we would also need to some ability to listen for show/hide events on the view, because using my own command / gesture, I know the view is going away, so I can clear state or do whatever I need, but using the vscode provided one, I have no ability to do that.