Favorite folder contents

[4ux-nbIx]

Hi there!
Awesome extension, but I've got a suggestion. It would be cool to be able to expand a favorite folder and see it's contents (sub-folders and files). This can be useful if you already have a workspace folder open in VS code and need quick access to some files outside the workspace, like a collection of snippets and etc. So instead of adding all those files to favorites (can be a lot of files) it would be awesome to add an entire folder and open files one by one when needed.

What do you think?

Thanks,
Roman

[oleg-shilo]

Agree. Good idea.
Will do it as soon as the opportunity comes.
Fortunately VSCode API is generous enough to support such a use-case. Doing something like this in the SublimeText port of this extension would be a completely impossible task.

[4ux-nbIx]

Cool, thanks!

[oleg-shilo]

Done

This feature is not a substitution of the Workspace explorer view, which does by far superior job. It's just a convenience measure for a quick access of the top level folder files. The feature can be enabled/disabled with favorites.showFolderFiles setting.

Note, the feature overall experience is subject to the limitations/defects of the VSCode tree view. These defects are officially reported and being dealt with by the VSCode team:
microsoft/vscode#34130
patrys/vscode-code-outline#24

[4ux-nbIx]

Hi Oleg! Thanks a lot for the update. Just tried it and here are some comments:

1. After clicking on a folder it get's loaded automatically every time. Would be nice to be able to control this behavior in settings. May be load the folder by double-click?
2. favorites.showFolderFiles doesn't seem to work for me. VSCode doesn't show it neither in settings editor, nor in extension contributions tab although I can see that it's defined in extension's package.json.

Also, why did you decide to limit favorite folder contents to one level only? It would be nice to be able to browse it as in explorer view, so it was possible to organize all favorite files in sub-folders. I understand that it shouldn't act as Workspace explorer replacement, but in my case it'd be extremely useful, because I tend to organize my files in groups within one category. Here's an example. I have a folder with http request files for many different APIs that I use from time to time. Each API can have many different endpoints, so I group all files like this:
Http Requests
-App1
endpoint1.http
endpoint2.http
-App2
endpoint1.http

Thanks,
Roman

[oleg-shilo]

OK. One by one.

After clicking on a folder it get's loaded automatically every time.

That's why I put the limitation disclaimer. :)
You see, all implementations of TreeView implement simple intuitive interaction paradigm. The item can be selected and expanded. First one is triggered by a single (or double) click on the item. Expanding is triggered by clicking the expander spot (triangle on the left):

However in VSCode TreeView expanding and selecting is the same thing. One cannot expand item without selecting. I have no idea who decided that having it done this way is a good user experience. Apparently you don't think so. Me neither. I have listed two defect describing this problem.

...VSCode doesn't show it neither in settings editor, nor in extension contributions tab

Yes I also noticed that. What ever I try to do it just does not appear in the contributions. Though it works perfectly if "favorites.showFolderFiles": true, setting is placed in the user setting file.

Also, why did you decide to limit favorite folder contents to one level only?

Because I am not sure the feature is useful until VSCode has TreeView problem fixed. The fact that you were trying to disable this new feature confirms that it is not very usable right now. And also I did't want to have too much overlap with the Workspace explorer.

[oleg-shilo]

OK, I have solved one and addressed (a little) another problem:

• Setting not being displayed in the contributions tab was caused by the package.config targeting older version of VSCode, which did not support displaying settings. Fixed now (v1.1.1).
• Added option to show favorite's folder item sub-folders content. Controlled by favorites.folderFilesTopLevelOnly setting.

A for user experience with Folder's item content. This feature is heavily affected by the VSCode treeView item bug (microsoft/vscode#34130 and patrys/vscode-code-outline#24) which always triggers node selection when you try to expand it.

The re is no way around it except using keyboard for selecting and expanding items instead of mouse clicks.

[4ux-nbIx]

Cool, got the update and it looks great except for the tree view bug! What if you add an option to disable folder loading on selection completely? I personally don't see a big need in this, because I'm using Project Manager extension to load workspace folders. This way expanding a folder node with a mouse click will select it but the extension won't load the selected folder allowing to browse folder contents. Right now it's only possible to browse a favorite folder contents with keyboard. Clicking anywhere on a folder node (even expand button) loads the folder and makes the whole point of this change pretty useless...

Thanks,
Roman

[4ux-nbIx]

It can also be a good idea to add a context menu item to load selected folder instead of loading it automatically. Here's what I think is the best way to make user experience the best:

• If autoLoadFolderoption is set, don't show folder contents, because it'll be fully accessible after the folder has been loaded.
• If autoLoadFolderoption is off, show contents and auto-open files only.

Another idea is to have some special syntax that controls folder loading in favorites.txt. This way it'll be possible to define folders that should be loaded on click and folders that should not auto-load and display it's contents instead.

What do you think?

[oleg-shilo]

My initial thought was also in the area a custom syntax. I don't like menu approach. Too many clicks...

One possible approach would be to have a dedicated prefix (e.g. !) to prevent opening:

!E:\Projects\VSCode\favorites.vscode

Then... I changed my mind. :) The truth is that it is a VSCode bug and I feel uneasy about changing my extension conceptually simply because VSCode hasn't fixed their bug yet. Even more, I am uncomfortable to ask users to deal with the extra config values, tolerate user experience inconsistencies and remember special syntax simply because I want us to pretend that VSCode does not have a bug.

I came up with the solution that does not change much the concept of the extension but rather it presentation. Thus I decided to leave only one setting favorites.showFolderFiles and provide a visual alternative for opening folder as a workspace.

The solution is to prevent opening the folder on clicking the folder item (clicking will only toggle the expanded state). And also to insert a "command node" that will open the parent folder. This way syntax remains the same and the user experience is reasonably consistent across the whole treeview :

But when VSCode fixes the problem that extra "command-node" will be gone.

[oleg-shilo]

Done in the latest Release v1.1.2