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

Consider deprecating the split JSON settings editor #62964

Closed
roblourens opened this issue Nov 12, 2018 · 30 comments
Closed

Consider deprecating the split JSON settings editor #62964

roblourens opened this issue Nov 12, 2018 · 30 comments
Assignees
Labels
search Search widget and operation issues under-discussion Issue is under discussion for relevance, priority, approach

Comments

@roblourens
Copy link
Member

roblourens commented Nov 12, 2018

Edit - Since this has so many 👎, I need to be very clear, we will never remove editing settings.json files. This is about the UI in the JSON editor, e.g. the pencil icons, the split view, the search bar, etc.


Now that the settings UI is stable, we should consider getting rid of the split JSON settings UI. It would just mean less code to maintain, and new UX feature investment can be focused on the UI.

I think that by default, we would open the default settings and settings.json side by side, and the setting workbench.settings.openDefaultSettings would still control whether the default settings editor is opened.

We need a better understanding of how many people are using it over the settings UI.

@roblourens roblourens added feature-request Request for new features or functionality search Search widget and operation issues labels Nov 12, 2018
@roblourens roblourens added this to the November 2018 milestone Nov 12, 2018
@roblourens roblourens self-assigned this Nov 12, 2018
@eamodio
Copy link
Contributor

eamodio commented Nov 13, 2018

Please don't get rid of the JSON settings editor -- I find it far more valuable than the UI, especially when seeing what settings I actually have set.

@furudean
Copy link

furudean commented Nov 13, 2018

I'm sure I'm not the only one who still uses - and prefers using the old JSON-style settings. As a programmer it feels very natural and fun to work directly "inside code" to adjust settings.

Some advantages that I felt the old editor has is

  • It is a settings editor with a focus on overriding defaults. You get a really good overview of which settings you have set. The new editor shows you everything, always.
  • It was very easy to export and share your settings with others, this is now not as easy as before.

I think if these were amended, I would consider to start using the new settings, but for now I will stick with the old.

@ghost
Copy link

ghost commented Nov 13, 2018

I wish #50249 remained open or at least this issue was mentioned in a last comment there, because when it comes to seeking feedback on who uses the original settings editor, that's a good place to start.

I would like to offer another data point here, I don't use the settings UI and don't plan on it, for me the loss of the JSON editor would be a big deal and would make my experience using VS Code worse.

@roblourens
Copy link
Member Author

I need to be clear, we will never remove editing settings.json files. This is about the UI in the JSON editor, e.g. the pencil icons, the split view, the search bar, etc.

@eamodio
Copy link
Contributor

eamodio commented Nov 13, 2018

While I don't care much about the pencils, I definitely like the split view and filtering. I would still consider that quite a loss

@roblourens
Copy link
Member Author

roblourens commented Nov 13, 2018

Would the simpler split view (just two editors like keybindings uses) suffice? And you would still get intellisense filtering in settings.json which I find sometimes more useful anyway.

@martellaj
Copy link
Member

martellaj commented Nov 13, 2018

It looks like this has already been implemented in Insiders... First bad move VS Code has made IMO. 🙁

EDIT: You can still get to it by going to Settings -> Text Editor -> Files -> "Edit in settings.json". 👍 Really consider keeping this more top-level or making it easier to get to. Coming from another Microsoft product with a lot of settings, I have to guess that not many people even change default settings (maybe more because your audience is developers), but if they do it's probably a small subset. I'd rather see it in text form where I can quickly edit settings I change instead of looking through a UI with 500 settings.

@roblourens
Copy link
Member Author

No, I haven't made any change for this.

I think some people are misunderstanding what this change is about. settings.json is not going away, you can even set it as the default if you want.

@martellaj
Copy link
Member

martellaj commented Nov 14, 2018

Got it. Thanks, Rob. The link in the rich settings UI to open in settings.json seems to be gone in the latest build so that's why I assumed. I'll have to hunt it down...

EDIT: Found your comment on another issue (#63044)...

@roblourens
Copy link
Member Author

roblourens commented Nov 14, 2018

Oh, under the ... button? Yes that was moved to an editor action button, so now you can get to it with a single click 😄

image

(The { } button)

@eamodio
Copy link
Contributor

eamodio commented Nov 14, 2018

@roblourens for me I think just a normal split view would suffice. Sometimes I like the search filtering, but I don't think I'd miss it much.

@carlocardella
Copy link
Member

Personally I don't care too much about the pencil (as long as intellisense will still work) but I do like the search/filtering. For settings I'm not a UI fan, I have set the json view as my default

@Astrantia
Copy link

Astrantia commented Nov 14, 2018

@roblourens The new settings UI doesn't provide configuration for more complicated extensions. For example look up latex extension, 40% of the extension settings cant be configured in the new editor that can be configured in the json editor.

List of stuff that's not supported:

  "latex-workshop.latex.magic.args": [
    "-synctex=1",
    "-interaction=nonstopmode",
    "-file-line-error",
    "%DOC%"
  ]

and

  "latex-workshop.latex.recipes": [
    {
      "name": "latexmk",
      "tools": [
        "latexmk"
      ]
    },
    {
      "name": "pdflatex -> bibtex -> pdflatex*2",
      "tools": [
        "pdflatex",
        "bibtex",
        "pdflatex",
        "pdflatex"
      ]
    }
  ],

How would you able to set these in the new settings UI? That's why an inplace json input is required in the new settings UI...

@roblourens
Copy link
Member Author

@Astrantia I understand that, and as I keep saying, the JSON itself is not going away, just some of the UI sugar.

@carlocardella do you prefer finding settings with the search bar rather than using intellisense? I'm curious what is your workflow like? e.g. search, copy/paste from left to right...?

@carlocardella
Copy link
Member

@roblourens if I don't know exactly what I'm looking for and I'm just fishing for the right setting, I use the search bar with some generic enough keyword to return a list of settings to help me figure out the one I need, then I may use the pencil to copy/update it from left to right (assuming using the pencil brings up a list of values I can easily choose from) or sometimes just copy/paste or even type myself on the right side where I can customize more as needed.
I especially like this approach because this help me familiarize with the large amount of settings available and better learn how to customize them exactly the way I want

@akdevservices
Copy link

Don't do that!

@martellaj
Copy link
Member

@carlocardella Thanks for the heads up that there's a setting for settings. 😂 Just switched mine to be JSON by default! 🎉

@graph
Copy link

graph commented Nov 20, 2018

When I saw the json settings editor for the first time I thought it was a genius approach. Especially given that vs code target audience is developers. The pencil button is great, the search is great, comments in the code. It feels so simple and easy. It's easy to find what I'm looking for and edit the settings as needed. The new UI is also simple and easy to use, and is great, but I don't feel it's worth effort to migrate to new UI.

@carlocardella
Copy link
Member

Exactly my reaction: I did not complain when the Settings UI was proposed (I understand people may have different requirements and taste) but given being a developer tool I had not expected the need for a UI, since the Json split view works very well.

@JeffreyCA
Copy link
Member

JeffreyCA commented Nov 26, 2018

Coming from 1.29 to the Insiders build, it took me way too long to figure out that the {} icon was for opening the settings.json file. I thought you guys removed the feature or something. My initial instinct was to think that it would be under the ... button on the tab bar because it had been under the ... before.

The location of the icon got moved to the same row as the upper tab bar which makes it difficult for users to discover where the new button for accessing the JSON is.

Before After
screen shot 2018-11-26 at 10 42 12 am screen shot 2018-11-26 at 10 42 22 am

Can we move the {} button to where the previous ... button was: on the same row as User Settings and Workspace Settings?

@roblourens

@roblourens
Copy link
Member Author

This actually makes it more consistent with the rest of vscode, e.g. similar to the button to navigate from a git diff view to the individual file. I understand it might be a road bump for people who have gotten used to the second ... menu but I think it's better long term to be consistent. Also, this puts it a single click away instead of two clicks which was a common complaint.

@JeffreyCA
Copy link
Member

My suggestion would be sort of a middle ground, so that accessing the JSON is still one click away, but in the previous location. I think it makes more sense to put it on the lower row because it applies only to the Settings view.

There will probably be many reports by users asking where that setting went when 1.30 is released.

@roblourens
Copy link
Member Author

Could you open a new issue for that since it's not quite related to removing the UI in the JSON editor?

@JeffreyCA
Copy link
Member

Sure, created an issue here: #63806

Other than discovering the new button after upgrading I don't think there are major issues with the change.

@piotrtobolski
Copy link

Maybe we should consider deprecating the GUI settings editor? The JSON settings editor in a developer tool is a brilliant idea I wish more apps would adopt.

I would love an option to disable the GUI settings editor completely to make the VS Code a bit faster and simpler.

@roblourens
Copy link
Member Author

If you don't like it, don't use it 😁 See workbench.settings.editor

@thernstig
Copy link
Contributor

thernstig commented Dec 7, 2018

@roblourens Have you made some telemetry on who is using the GUI vs the JSON editor? The reason I am asking is your original post where you state:

We need a better understanding of how many people are using it over the settings UI.

I am guessing more people would use the JSON editor by default if they knew they could choose, but my guess is as good as anyone's. Hence the question if it would be wise to do some telemetry before doing any changes.

My experience is this: Every developer I have talked to and have them understand they can switch the default to use the "old" JSON settings editor has done so. It is more natural to a coder, who is the primary user of VS code. It has multiple benefits, as explained in this thread.

I understand you are not removing the editor, but you are aiming to trim off some of its limbs. I think this is the wrong route. The JSON settings editor, as is, was a genius implementation from the start. Built by coders, for coders.

@MeikTranel
Copy link

MeikTranel commented Dec 9, 2018

@roblourens then why is this issue even discussed if you don't plan to get rid of the split view editor, but default to the GUI editor instead?

@thernstig
Copy link
Contributor

thernstig commented Dec 9, 2018

Benefits of the JSON editor

  • Easy copy&paste of settings.
  • Quick overview of your personal settings. You easily see the default settings you have overridden.
  • All your documentation shows JSON for settings. This is a huge thing. When a user who is learning VS code they can quickly copy&paste settings from your own docs and directly get it working. When they see the GUI they have to spend time searching. All extensions also show their settings as JSON as far as I am aware. Maintaining images for the settings for the GUI editor would be a huge burden and documentation would quickly get outdated everywhere.
  • You get green squiggly lines on settings that you have configured but that do not longer exist, which gives a quick visual indication.
  • Possibility to configure more complex settings.
  • You can add comments to settings. A great way to explain complex settings to team members in the workspace settings.

Benefits of the GUI editor

  • You can click stuff.

Feel free to add to the list.

To reiterate: I've already understood this is not about removing the JSON editor. But you are aiming to do "something" and that "something" I do not like whatever it is :)

But I have no idea why the GUI editor is the default. Do Microsoft employees actually prefer that? As coders? Another topic for another day maybe.

@roblourens
Copy link
Member Author

I am moving this issue to #64932

@thernstig Those are all good reasons that you may prefer to use JSON and you are still welcome to do so 😁

But there are many benefits of the GUI editor for new users. Not every vscode user is an experienced coder. Not every coder knows what JSON is. The JSON-based experience is overwhelming to many people who just want to change the font size with a minimal learning curve. When there is a power user option and a friendly option, the friendly option is going to be the default.

@vscodebot vscodebot bot locked and limited conversation to collaborators Jan 27, 2019
@dbaeumer dbaeumer added the verification-needed Verification of issue is requested label Jan 29, 2019
@jrieken jrieken added under-discussion Issue is under discussion for relevance, priority, approach and removed feature-request Request for new features or functionality verification-needed Verification of issue is requested labels Jan 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
search Search widget and operation issues under-discussion Issue is under discussion for relevance, priority, approach
Projects
None yet
Development

No branches or pull requests