Provide GUI for settings

[Tyriar]

Customizing Code would be far less intimidating to new users if there was a GUI for settings customization.

[mrmckeb]

I'd like to jump in and work on this, as I've heard the same thing from others. Are there any design guidelines or references, @Tyriar?

[felixfbecker]

I also think this would make more people adopt VS Code. Here are some ideas:

• Similar to how you can switch between markdown code and preview, allow to switch between the settings.json file and a GUI, with the GUI being the default
• Dynamically generate the GUI from the JSON schema, including those from extensions
  • booleans become checkboxes
  • arrays and hashes become lists were it is possible to add / remove new items
  • numbers become spinners
  • strings become input fields
  • union types?

[Tyriar]

@mrmckeb not yet. But speaking of which, this would probably need to go through UX first. ping @bgashler1

[mrmckeb]

Thanks @Tyriar. Perhaps I could start work on the functionality here and we could polish the UX later? The approach would be something similar to what @felixfbecker described, and I also like how the Atom team manage their settings.

[bgashler1]

Nice idea. I previously had a similar idea, and I agree this could be be less intimidating to new users. It could also beneficial to people who don't know JavaScript and who are using VS Code for another language that doesn't have anything like JSON. Finally, JSON can be unforgiving if you miss a comma or closing brace somewhere.

The worry the team had when I shared this idea previously was that a GUI would not be able to do everything JSON could do as simply and effectively. JSON is leaner (you copy just what you need and change just what you need); it's easy to see what you've changed, because you're only overriding defaults. Intellisense also helps people write what they need. Lastly, JSON results in shareable recipes that can be committed or emailed to others.

Despite the drawbacks, @felixfbecker, you have an interesting idea of generating the GUI based off of JSON—with some careful styling and layout rules, this could work well potentially.

@mrmckeb you mentioned that you've heard this from others. Could you point me to that discussion?

[bgashler1]

Google Chrome settings seems like a good source of inspiration since they filter through a mass of settings based off of keywords.

[bgashler1]

@mrmckeb Before we jump into implementation. Let me first check with the team and also get some mockups to be sure we have the experience right. I would hate to waste any effort before we have the experience where it needs to be.

[egamma]

I like the discussion, but we hear different feedback on this topic:

[mrmckeb]

@bgashler1 I've heard in a literal sense, in my office. I don't have a discussion to point you to sorry. I'd argue that whilst the tweet @egamma has shared is a valid reason to keep the JSON settings in place, it doesn't mean we can't have both - perhaps upon first opening settings, you are given an option as to which way you'd rather proceed?

As the extension/plugin library grows, I'm sure more of the creators of those plugins would also like a settings GUI to tap into (again, Atom has done a great job of this).

I also understand the complexities that are concerning a few people, that maybe the JSON is too complex to auto-generate settings from. The other way to go about this is to specifically create a GUI that's tailored for core settings, and refer users to the JSON for advanced settings - but I really would rather create something smarter and all-encompassing where possible.

If there are concerns about changing the structure of the JSON (which I assume there would be), we could also look at something JSDoc-like for declaring (in comments) what the 'GUI-friendly' name of each setting is, and how it should be displayed in the GUI. Example below.

/**
 * Controls the font family.
 * @name "Font family"
 * @type text
 */
"editor.fontFamily": "",

[felixfbecker]

@mrmckeb You do not need JSDoc, every setting is specified in JSON schema, which allows to specify descriptions, default values and types. An extension can already provide more settings with a schema.

[mrmckeb]

Thanks @felixfbecker, good point - I didn't realise JSON schema was in use here. That's a far better solution.

[ianwesterfield]

@mrmckeb I like the idea of a gui, and think @felixbecker has a good compromise to what @egamma brought up because I find updating the JSON to be faster.

Atom's implementation...it doesn't flow nicely. I find either scrolling forever (especially the beautify package), or jumping into each little extension's page and back again to be a clunky, uninspired design.

Not original, but maybe something akin to the tree in Visual Studio? That would eliminate jumping around to different views for extensions and keep scrolling to a minimum.

[iam3yal]

Personally, I don't like GUIs for options at all, I really wish for the day that Visual Studio will have its options stored in a JSON file too. :)