Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create "focus views" in Explorer pane for custom paths in a Workspace #133412

Closed
ZaLiTHkA opened this issue Sep 19, 2021 · 3 comments
Closed

Create "focus views" in Explorer pane for custom paths in a Workspace #133412

ZaLiTHkA opened this issue Sep 19, 2021 · 3 comments
Assignees
Labels
info-needed Issue requires more information from poster

Comments

@ZaLiTHkA
Copy link

Greetings! (: FWIW, I have searched the currently open issues for something similar, didn't find anything quite like it though.. So, here goes my first feature request. 👍🏼

I think the easiest way to explain what I would like, is with a sort of "desired workflow" story. So first, just for context, let's say that we have a workspace open with multiple "project" folders:

- project-1
- - build
- - src
- project-2
- - build
- - src
- project-3
- - build
- - src

naturally, this "example" could never include every possible "boring" file and folder, but with some web projects, there are a great many..

If we want to do any work on one specific project, the best case scenario here is to "collapse" the tree to:

- project-1
- project-2
- - build
- - src
- - - [interesting-folder]
- - - - [interesting-file]
- - - [interesting-file-1]
- - - [interesting-file-2]
- project-3

At this point, I would like the ability to "focus on" the said [interesting] paths, by limiting the Explorer tree view to the folder that contains them.

So if I may take contextual liberties with action labels, I would proceed to:

  • Expand to see the project-2/src folder in Explorer pane
  • Right-click and select "Focus on this folder"

At this point, the Explorer pane should update to show that folder as though it were opened directly in VSCode. For all intensive purposes, now showing only:

- [interesting-folder]
- - [interesting-file]
- [interesting-file-1]
- [interesting-file-2]

This would allow any and all file access to be temporarily limited for the sake of specific feature development.

this does require a way to return to the normal Explorer pane tree view, so perhaps this could be a new "revert focus" or "reset tree" button to the left of "new file", "new folder", etc..? open to ideas on that point..

As a sort of "personal disclaimer", I would like to clarify a few points regarding this idea:

  • This doesn't need to prevent the "file quick open" action from being able to access all files in the Workspace, as it normally would; but if it does, opening any workspace file in this way should not remove the current "folder focus" view state.
  • Focusing on a folder should cause IDE extensions to reload, where they would receive the "focused path" as the currently open folder.
    • To speculate wildly, I think this would only really show as a lower IDE overhead, especially in cases where the different projects are written in different languages... the "unused" can simply not be loaded, so the respective extensions would never see the files, or have any reason to "trigger".
    • I am also aware that we could use "extension profile" extensions to switch out which are active at which times, but I feel this could lay the groundwork to remove the problem that these extension profile systems aim to solve, but that's a whole different topic right there.
  • I do feel this should be implemented as a VSCode core feature, as opposed to an extension, simply because re-using the existing Explorer pane feels like the best way for any user to get the proper benefit from.

As an alternative that potentially warrants an extra expanding pane: this action could instead add the selected path to a list of "focused paths", which would then be shown in their own expanding pane below the "Workspace" pane, as a sibling to the others like "Outline", "Timeline", "Servers", etc.. From there, the most logical way to remove a "focus" on any focused folder, would be to simply right-click and "un-focus".

This has the added benefit of being able to then focus on features that potentially do span multiple projects in a workspace, but with the bonus of not also seeing every accessed project's temporary folders all the time, simply as a result of having the tree node expanded.

Please note: I am aware that specific folder paths may be "filtered out" of the Explorer pane tree, as with things like node_modules for example. That in itself I feel serves a different purpose (and I do actually like to see my build folders in the tree), so this should not do anything to mess with that behaviour.

I do actually like to see the contents of the build folder, but while developing, it would be $#&^ing amazing to be able to see only something like...

- project-1/src
- - [interesting-folder]
- - - [interesting-file]
- - [interesting-file-1]
- project-2/src
- - [interesting-file-1]
- - [interesting-file-2]

...even if the workspace contains four "mini projects". Some of them could be "design", or "web-admin", or "client-mobile", or.... Not every "feature" touches every project grouped within a workspace.


So, if you've honestly read this far, thank you... 🍻 Is this worth looking into further?

@JacksonKearl
Copy link
Contributor

JacksonKearl commented Sep 23, 2021

I am not sure how this is different from extension profiles like you mentioned to control the files.exclude setting at the .code-workspace level. I'd imagine you'd have a variety of different configured files.exclude settings for different contexts and the extension would be responsible for swapping between them.

As for reloading the extension host, I don't think this is a good idea. Extensions generally expect to have a full view of the the FS, strange behaviours would occur if they saw a filtered view.

Semi-related to #41860

@JacksonKearl JacksonKearl added the info-needed Issue requires more information from poster label Sep 23, 2021
@ZaLiTHkA
Copy link
Author

ZaLiTHkA commented Oct 1, 2021

my apologies for not getting back to this sooner, I've had a week from hell, so I'm catching up on a few things quickly..

I am not sure how this is different from extension profiles like you mentioned to control the files.exclude setting at the .code-workspace level. I'd imagine you'd have a variety of different configured files.exclude settings for different contexts and the extension would be responsible for swapping between them.

As for reloading the extension host, I don't think this is a good idea. Extensions generally expect to have a full view of the the FS, strange behaviours would occur if they saw a filtered view.

Semi-related to #41860

thanks for the response @JacksonKearl, seeing the snippet of your reply in my email notification did get me thinking in a different light about the "issue" I was trying to solve, and I do believe this could (should?) be handled with a combination of "extension profiles" and possibly a custom extension.

after going back to an old Java project earlier this week, I took a closer look at the UI integration provided by the "Project Manager for Java" extension, and realised that what I was asking for is probably best handled by an extension anyway.. effectively, I'm looking for a "custom project manager" where specific folders in the project could be marked appropriately and shown in the same style as the built-in "Explorer" panel.

I'll dig into the related issue you linked to over the weekend, but for now I need to sleep (running on 36+ hours awake at the moment). FWIW, if the triage bot hadn't closed this issue already today, I would've done exactly that myself now. 👍🏼

thanks for making the most awesome IDE ever, and my apologies for making silly feature requests..

@github-actions github-actions bot locked and limited conversation to collaborators Nov 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
info-needed Issue requires more information from poster
Projects
None yet
Development

No branches or pull requests

3 participants
@ZaLiTHkA @JacksonKearl and others