-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Allow extenders to modify preferences #8626
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@westbury the property is used to
hide
elements in the view but it still allows users to add the preference in their settings (with or without the use of auto-completion). Is there a reason you want to hide the preference rather than make it non-editable?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider a custom IDE that is targeted to a very specific set of users using a specific tool chain for a specific purpose. There will be preferences that must be set to a particular value and setting the preference to any other value will always break the user. For example, a couple of days ago, after I had put in this PR, we had a bug report from a user. They had set on the 'Support Multi Root Workspace' preference. Our IDE works to a specific directory layout and does not support multi-root workspaces. So, in this situation, should we show the preference but make it non-editable, or not show it? I would suggest that not showing it is a better user experience. Mentioning 'multi-root workspaces' in a custom IDE that has no concept of multi-root workspaces will only cause confusion. If users know what multi-root workspaces are then they will think they must be supported and send in support requests complaining that they can't get them to work. A large part of providing a clean IDE is that we do not expose stuff that does not apply.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably should be removed from auto-complete in settings too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@westbury I'm not arguing the use-case, in fact I believe it is something I brought up in the past: https://spectrum.chat/theia/general/is-there-a-need-to-set-specific-preferences-as-non-overridable~2cf3bb68-59b2-4f4b-8070-b2839c35ba4d.
The issue with the approach is while the preference is
hidden
, the preference is still editable which can still break applications (for instance if they do not expect to support multi-root workspaces).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how we can stop the user from editing the settings file. If the requirement is that we do not want to give the user any way of changing the preference (short of hacking javascript) then we would have to ignore any value in the settings file, always using the default value. That would provide a consistent approach but it does remove the ability to change the preference value programatically.
The current implementation leaves the hidden property in the schema. The property would be better hidden if it were not in the schema, as it would not then appear in auto-complete. A disadvantage of removing hidden properties from the schema is that if the preference has been set programatically then the user will see it with squiggly underlining.
If we decide it is okay that hidden properties cannot be changed programatically (we have no use case) then it should be removed from the schema.