-
Notifications
You must be signed in to change notification settings - Fork 29.4k
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
Explore Extensions Management UX #68527
Comments
Might be an idea to use the the actual marketplace site in a webview for all “Browsing Marketplace” related items? |
I think it would be worth while to consider implementing a way to group or organize extensions, enabling the user to quickly enable/disable project specific extensions when setting up a workspace. |
This might be a separate issue but... I'd advice to add to Managing installed extensions the criteria Unmaintained. Which means the shown extension(s) didn't get any update from its developer within a year or after a new major (or minor) release of VScode. For each extension you need to manually navigate to its source repository to check its maintenance status. Which is obviously annoying. |
It would be nice to be able to install an extension, and automatically enable it just for the current workspace. Right now to do this you need to Install it, disable it, then re-enable it for the current workspace (potentially needing to reload the UI after each step). |
@LonMcGregor Just disable the extension and re-enable it for the current workspace. No reload required. After initial disabling, a reload button will show up (not knowing your future intension), which will be gone after re-enabling for the current workspace. |
I think it would also be nice to have a way to recently updated extensions so you could check out release notes for those. |
I remember asking about sorting of I could probably send a PR, but only after this decision is made. Is it resolved now? |
@usernamehw we're currently exploring adding that in this exploration (adding running extensions metadata) so I wouldn't attempt any PRs for now. We're hoping to post some updates in the next day or two 😄 |
@misolori I think this looks great and it will definitely improve extension discovering. Could you give more detail on viewing/managing installed extensions? |
@alexweininger for viewing/managing extensions, here's what we're hoping to do:
|
This looks great. With this UI/UX, the existing left pane for extensions will be unnecessary I think. |
@gulshan that's one of the options we are discussing since we already have an established pattern for actions in the activity bar to open a viewlet. Moving it next to the settings gear fits better as that opens a context menu. |
Integrating the marketplace better into vscode sounds like a good idea, but there seems to be too much going on on these proposed designs IMHO:
|
@fabiospampinato thanks for the detailed feedback, appreciate you taking the time to write this!
|
hi, please also consider the following feature request |
And splitting themes and extensions |
@misolori, in Exploration B, I really like the idea of having extensions grouped into categories. I tend to keep a lot of themes installed (because I get bored easily and like to switch things up), and as it stands, my Enabled extensions view is cluttered with themes. It would also be nice to be able to tag your installed themes so you can group them as you see fit. |
If the "installed extensions" view is being migrated to a full-page view akin to the cards in chromium's extension page, then I think it might still be nice to somehow offer a very light sidebar that just had installed extensions and a quick toggle. That's what I use in a panel my web browser to quickly toggle extensions as needed: I guess one big difference is that extensions in VS code can have 3 states: Disabled, Enabled and Enabled for this workspace. I'm not sure how would be best to show a 3 way toggle. |
@LonMcGregor, isn't there a 4th state: |
@usernamehw is correct. That's one I've never used personally. Makes things a bit trickier to imagine a quick toggle. |
Something I've found missing from the current functionality that would be handy to have would be a way to order extensions by install date. I installed the Trailing Spaces extension to highlight any random trailing spaces that have slipped into the code and it worked great, but randomly a few hours later I encountered a problem with it where it was incorrectly highlighting lines that were had no whitespace issues. I went to the extensions pane to remove the extension and couldn't remember what it was called. I clicked on the menu button (three dots) in the extension pane, first to show only the installed extensions (which hides the pre-installed and recommended extensions), then again to sort by installation date. Currently we have:
but no "Sort By: Install Date". It was only a minor nuisance to re-read all of my installed extensions (25 of them, mainly language syntax support extensions) to find the misbehaving one but this would be a nice quality of life fix to add for devs that are trying new extensions |
I also think having like a small marker noting if it's enabled locally/globally May help to resolve conflicts and make it easy for developers to fix their environment, since we can already disable per workspace etc. |
Is whitelisting of extensions per workspace part of this issue or should I create a new one? |
I doubt issue for that already exists, so please search for it. |
This still appears to be open, though it hasn't been added to in over a year. If there's a better place for this, I'm willing to move it there. I'd really like to have the ability to enable/disable extensions in the text configs. Use Case 1 (any of the config files): I have an extension that styles the Markdown Preview pane to look like an RPG rulebook. However, I don't need it for all of my Markdown files, just a subset of them, and that subset is within the same workspace as the other Markdown files (so enabling/disabling by workspace doesn't work here), but an option in the folder's Use Case 2 (only workspace level, single user): I work in a number of disparate paradigms and I find it helpful to keep enabled only the extensions a given project uses, to cut down on clutter. Having that information in the config files allows my workspaces to "just work," even if I'm on a new machine. Use Case 3 (only workspace level, multiple users): Having the enabled extensions in a workspace file allows me to share the extensions part of a workspace more concretely than the recommended extensions list currently does, adding a "required" layer and ensuring that the extensions are not only installed, but enabled. This can be particularly useful for standardizing base configurations (including extensions) within a team. |
I love the idea of enabling extensions in text config files... I always felt extensions.json needed a bigger role! |
Explore Extensions Management UX
Extensions Management include:
Managing installed extensions
Browsing Marketplace
Show Recommendations
Over the time this viewlet has become a single place for all of the above which made it
This seems like Extensions viewlet is overloaded with too many features and used for managing/browsing/customising extensions instead of just using like an explorer.
Goal of this issue is to explore some ideas considering all above use cases and come with a good design which gets aligned with current VS Code UX.
Following are some issues that are kinda related to current viewlet
The text was updated successfully, but these errors were encountered: