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

Settings editor: Support .enabled to hide other settings in the namespace by convention #115409

Open
Tyriar opened this issue Jan 29, 2021 · 4 comments
Assignees
Labels
feature-request Request for new features or functionality settings-editor VS Code settings editor issues under-discussion Issue is under discussion for relevance, priority, approach
Milestone

Comments

@Tyriar
Copy link
Member

Tyriar commented Jan 29, 2021

Related/parent issue: #70589

@eamodio suggested the idea of special settings that would hide other settings, that got me thinking we have this pattern already but don't hide them. In the screenshot below, only the top setting means anything unless it's checked, so we could hide them to reduce the overwhelming number of settings available:

image

This is similar to how most GUIs would disable settings when the feature is disabled. I'm not sure whether they should show up when searching, maybe they should but be faded/disabled out or something and point to the parent .enabled setting?

@roblourens roblourens added feature-request Request for new features or functionality settings-editor VS Code settings editor issues labels Feb 2, 2021
@roblourens roblourens added this to the Backlog milestone Feb 2, 2021
@rzhao271 rzhao271 self-assigned this Jun 22, 2021
@rzhao271 rzhao271 modified the milestones: Backlog, September 2021 Aug 3, 2021
@rzhao271
Copy link
Contributor

rzhao271 commented Aug 4, 2021

I think that adding more support for setting ordering and setting groups could be done instead of this feature (see #70589 (comment)). If collapsible groups can be added too, then I think it'd be even less of an issue.

Let's say a .enabled setting is disabled. Then, if a setting the user wants to edit is disabled, the user has to find the .enabled setting, enable that first, and then find the original setting again to edit the setting.
Also, when the user searches for the setting, if we show the setting in the search result disabled, the user must do the same thing, and go find the .enabled setting.
If we don't show the disabled setting in either case, the user, assuming they don't know that .enabled settings exist, would be confused about where the setting is. Even if they did know that there was a .enabled setting, they would have to go there again.

Pinging @eamodio for thoughts on this topic.

@rzhao271 rzhao271 added the under-discussion Issue is under discussion for relevance, priority, approach label Aug 4, 2021
@eamodio
Copy link
Contributor

eamodio commented Aug 5, 2021

I think this issue is more about simplifying settings -- like if you have a group of settings that are all controlled/dependent on another setting - we could then hide (not show) all those other settings that wouldn't apply if the "main" setting is off. This allows us to hide complexity when it honestly is just noise. If I have mini-map disabled, none of its other settings are valuable to me.

@Tyriar
Copy link
Member Author

Tyriar commented Aug 9, 2021

👍 this could be presented instead if minimap is disabled:

image

Much better without the noise imo.

@roblourens
Copy link
Member

It seems like it would be useful to see what is available even when the feature is enabled. I think it will lead to confusion when someone searches for "minimap render characters" and gets no results, but their friend does get a result. Would rather show the setting with a warning hint or grayed out or something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality settings-editor VS Code settings editor issues under-discussion Issue is under discussion for relevance, priority, approach
Projects
None yet
Development

No branches or pull requests

4 participants