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. :)

[mrmckeb]

@ianwesterfield I agree that some of what Atom does could be tuned, and hear both you and @eyalsk. I understand completely that many people prefer to update JSON settings, and can see why.

I'd never propose doing something that alienates part of the community, but I believe that the current approach is alienating some users. It would be great to find a strong compromise here.

There are advantages to both approaches. JSON is fast, explicit, searchable, and easy to manage/share. The GUI allow for intuitive controls, understanding without reading documentation or comments, and the ability for some magic (i.e. automatically disabling setting y as it relies on setting x to be enabled).

The right approach might be that the first time you open the settings JSON, you're prompted and asked if you'd prefer to use the GUI. We could keep data on usage of each, and if the GUI becomes more widely used, we'd default to that instead - but keep the first-time prompt in place.

Again, I'm trying to finds a solution that impacts both parties the least - let me know if you have any better thoughts here, it'd be great to keep this discussion going.

[ianwesterfield]

@mrmckeb I agree, I think some discussion should happen whenever there is a possible user gap.

I vote for @mrmckeb's idea for a prompt when first opening the settings.

I also agree that whatever the gui looks like, it should be generated automatically by the default JSON, and it's settings persist to the user's JSON as they reside today.

@felixbecker had two great points earlier in this thread.

I assume the same would go for keybindings to keep things consistent?

[iam3yal]

@mrmckeb I don't mind to have a GUI as long as it's a separate application and in fact I think it should be, someone can just pick it up and write a GUI application for VSCode and a simple extension to launch it via tasks. :)

If you are really serious about making a GUI that people will actually use then generating it automagically from the JSON file is not only a bad idea but you turn a simple problem to a much larger one that I'm not sure you understand.

P.S. I'm all for discussing it, sorry if I hijacked the post with my objection to it.

[felixfbecker]

@eyalsk the nice thing about JSON generated GUI is that it makes it easy for extensions to add settings that get a GUI aswell.

What do you think about my suggestion where the settings.json just has a button like the Markdown preview button that switches to settings UI?

[ianwesterfield]

@eyalsk I'm afraid I don't really understand how this could become a much larger problem. Perhaps you could elaborate?

I wouldn't expect a user to go find some other application just to manage the settings. That's weird in this context. Can you name other IDE/document editors that manage their settings this way?

[iam3yal]

@felixfbecker The issue with what you are proposing where you exchange text with controls is that I'm not sure how great the experience would be and I'm not sure what you gain by doing it.

So without an actual UI I see no point in it.

@ianwesterfield

I'm afraid I don't really understand how this could become a much larger problem. Perhaps you could elaborate?

Okay, if you refer to the kind of GUI @felixfbecker proposed then I guess it wouldn't be so hard to do but I don't see much value in it but maybe I'm wrong. :)

I wouldn't expect a user to go find some other application just to manage the settings. That's weird in this context. Can you name other IDE/document editors that manage their settings this way?

The person can simply make it available as an extension, when the extension is executed for the first time it grabs the installation and install the application and finally start the application, the second time it just starts the application but the bottom line is that it's not so different than installing any other extension so it certainly not weird.

The VSCode team can make this available by asking the user whether he wants a GUI to manage the settings so the user wouldn't have to find it.

The benefit of making this as a separate application is that it loads as part of a separate process.

[bgashler1]

Here's a proposed look of GUI settings. Special thanks to @felixfbecker for your idea that I incorporated in this design.

• It works similar to markdown preview.
• You can click the "Preview" button on the top of the header for the GUI.
• You can get to a particular setting or category of settings the same way as you do in JSON, by using ⌘ + f or ctrl + f.
• As you update settings in the GUI, they are reflected in the JSON (and vice versa).

[felixfbecker]

@eyalsk

The issue with what you are proposing where you exchange text with controls is that I'm not sure how great the experience would be and I'm not sure what you gain by doing it.

The benefit is easier discovery of settings. Currently, you have a) the default settings where you can discover what settings are available and b) the actual settings.json. You always have to copy+paste the settings or use IntelliSense. In a UI you can see what settings are available, see what values they have and change them at the same place.

So without an actual UI I see no point in it.

I don't get this, there would be an actual UI.

@bgashler1 this is near to how I imagined it, a few complaints though:

• the headlines need to be smaller
• true / false should simply be a checkbox
• I find it a bit weird that the UI opens over the default settings and still shows the actual settings side by side. It would make more sense if you toggled the view of the actual settings.json to get the UI, and then maybe automatically close the default settings json window.
• What should happen when you set a value back to the default value? Should it get removed from the settings file?

[pflannery]

@bgashler1 That is looking good so far. Just keeps it simple.

• The size of the text and radio button look right for people with disabilities. Maybe size could be tailored for preference but default to big so new starters to vs code with disabilities can jump right in.
• I think using radio buttons for true and false is spot on because their best for choosing a single option in a list, where as check boxes are best for opt-in opt-out lists.

Be cool to have a search filter to quickly get to each configuration from inside or outside of the settings file, it could also hide non-relevant settings too.
Also categorization for things like theme overrides and extension settings would be wonderful.

I've never liked the way ide's have handled their preference gui's. I've always felt removed from the actual environment I'm working in and to top it off I'd always find a crucial area of configuration stuck in a horrible little single line text box. (:cough: :cough: just like (the old) Microsoft Windows Env Path editor in system properties).

[iam3yal]

@felixfbecker

The benefit is easier discovery of settings. Currently, you have a) the default settings where you can discover what settings are available and b) the actual settings.json. You always have to copy+paste the settings or use IntelliSense. In a UI you can see what settings are available, see what values they have and change them at the same place.

Okay, you make some fair points here.

I don't get this, there would be an actual UI.

Yeah, what I meant by that is that exchanging text with controls might not be as intuitive as a custom made GUI and might be somewhat limited.

Don't mind me though @bgashler1 did a great job so I'm looking forward to see this in action and try it out. :)

@bgashler1 well done! mate.

Paths might be tricky to determine because there's no convention but maybe you can check whether the key ends with .path or Path and replace it with a file input instead of a textbox.

[mrmckeb]

Looking great @bgashler1. When do you expect to get sign off on the design?

I think the technical side of things should be manageable, but as a few people (like @eyalsk) have pointed out - we need to make sure that the JSON translates into a GUI as seamlessly as possible. @felixfbecker's earlier JSON Schema suggestion seems like it would cover this.

My feedback/thoughts:

• There could be a Windows-style settings search/filter, where it effectively filters the settings shown as you type. There's a lot of whitespace, but I think that fits with the design of VSCode..
• There's a lot of whitespace. This isn't necessarily a bad thing, but could make the GUI quite long - especially as people start using more extensions with their own settings.
• Has there been much thought to how extensions would be handled in settings? Would it literally represent the JSON structure? Or would it highlight extension settings vs app settings?

[Tyriar]

@mrmckeb afaik this is just exploratory and we're not committing to anything yet. The main concern of most people seems to be wasted effort in building out this when it's not adding any new real functionality, just an alternate UX. It could also potentially be more confusing have two different editors for the same thing.

Extensions are another beast which would probably need to be handled quite differently. I created an issue for that too #3356

[pflannery]

@mrmckeb I wonder if a prototype of @bgashler1's example could be started now by using a similar technique as @egamma pointed out to @drywolf #3011 (comment)

Then later on down the line it could be migrated to a json viewer extension if and when it becomes available (i.e. like the current markdown viewer).

[mrmckeb]

Sure @pflannery, I can take a look at this over the weekend and see what I can get done.

[mrmckeb]

@pflannery, sorry I didn't get a change to look at this over the weekend. I'll try to look one night after work this week, but if not, definitely on the coming weekend.

I'll obviously need to get my head around developing VSCode and it might be slow to start with, but I'm really excited about jumping in.

@Tyriar I'm sure whatever work is done here will be somewhat transferrable to that too (at least in part).

I can see the competing ideas here, and both sides make valid points. I feel that the argument around discoverability does make the GUI option compelling, but understand the need to implement this in such a way that power users could get away with never seeing it.

Personally, I don't want to have to research what each setting does or what options are available. I also see the value in having those settings in JSON so that I can store them with my projects, or synchronise my settings between computers.

If this idea did end up being an extension, I'd hope that it would be something that was an option during the install process. That could be a good compromise, example below:

Would you like to use the GUI for changing settings? Selecting yes will install the extension settings-gui, which can be removed.

[roblourens]

1. Table of contents - we have discussed this. We might end up with something like that but it does seem to add a lot of visual noise. Also our categories are not all user-friendly and we think searching is more useful than browsing categories at the moment.
2. Done, thanks for the suggestion ✔️
3. Underlined because it's a link, but the UI is a work in progress
4. I removed the dot because some people confused it for the "unsaved" file indicator. But it's also good to not rely only on color differences for important UI indications, for accessibility reasons. The "Reset" button only appears on configured settings, maybe that+the color are enough for now.

[logar16]

I was turned off to VS Code when first introduced to it because there was no simple GUI for picking colors for the theme or syntax coloring. That's the first thing I change when I get an editor. So several months later I started looking into VS Code because of good reviews. So, my experience shows that you'll get more of the beginners in if you make it easier. But leave the option for those hardcore individuals who'd rather do it all in JSON.

[gandalfsaxe]

I have the opposite problem now - is there any way to open settings.json directly, instead of:

1. going to settings
2. click ellipses
3. click "Open settings.json"

[pastudan]

@gandalfsaxe I reassigned the keybinding of Ctrl+, to workbench.action.openSettingsJson, as this keybinding was the default for opening the settings.json before the update. Easier than even navigating the file menu in my opinion.

I do think the new settings dialog should do a better job of highlighting the option of using the awesome settings.json editor, rather than hiding it behind an ellipses menu. Perhaps even give an easy option to make it the default for power users.

[roblourens]

There is a setting for it, workbench.settings.editor

[pastudan]

@roblourens ah, just noticed after reading the release notes :)

I guess my point was around highlighting that option in the settings UI. The settings.json editor is an immensely powerful feature that a new user would never know about.

[gandalfsaxe]

Yeah I'm also using a shortcut for workbench.action.openSettingsJson now:

Mac: ctrl+cmd+,
Window: ctrl+alt+,

[reeddunkle]

The setting takes a String value of "json":

"workbench.settings.editor": "json"