-
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
Provide GUI for settings #3355
Comments
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? |
I also think this would make more people adopt VS Code. Here are some ideas:
|
@mrmckeb not yet. But speaking of which, this would probably need to go through UX first. ping @bgashler1 |
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. |
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? |
Google Chrome settings seems like a good source of inspiration since they filter through a mass of settings based off of keywords. |
@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. |
@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.
|
@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. |
Thanks @felixfbecker, good point - I didn't realise JSON schema was in use here. That's a far better solution. |
@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. |
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. :) |
@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. |
@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? |
@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. |
@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? |
@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? |
@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.
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. :)
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. |
Here's a proposed look of GUI settings. Special thanks to @felixfbecker for your idea that I incorporated in this design.
|
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.
I don't get this, there would be an actual UI. @bgashler1 this is near to how I imagined it, a few complaints though:
|
@bgashler1 That is looking good so far. Just keeps it simple.
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. 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). |
Okay, you make some fair points here.
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 |
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:
|
@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 |
@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). |
Sure @pflannery, I can take a look at this over the weekend and see what I can get done. |
@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:
|
|
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. |
I have the opposite problem now - is there any way to open
|
@gandalfsaxe I reassigned the keybinding of 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. |
There is a setting for it, |
@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. |
Yeah I'm also using a shortcut for Mac: |
The setting takes a String value of "workbench.settings.editor": "json" |
Customizing Code would be far less intimidating to new users if there was a GUI for settings customization.
The text was updated successfully, but these errors were encountered: