Explore user profiles

[miguelsolorio]

Overview

This issue aims to explore what adding "profiles" could look like in the product. These profiles can be used in education, presentations, or can even be language specific. The explorations should cover being able to setup and switch between profiles. Ideally these profiles should be synced with Settings Sync (if used) so you can use those profiles anywhere.

One idea for settings is to introduce a new settings object like:

{
    "profiles": {
        "demos": {
            "files.autoSave": "onFocusChange",
            "editor.fontSize": 18,
            "editor.tabSize": 2,
            "editor.fontWeight": "600",
            "screencastMode.enabled": true,
        }
    },
    
    "editor.fontFamily": "Cascadia Code",
    "editor.renderWhitespace": "all",
}

The "Demos" profile inherits the current settings a user has and adds additional settings on top of the current ones. Also, when profiles are enabled we will create a "Default" profile where the user can switch back to their default mode.

Related issues

• Screencast Mode only settings Screencast Mode only settings #105226
• Sync mutliple settings profiles Sync mutliple settings profiles #92393
• Multiple environment profiles (either per-session or per-window) Multiple environment profiles (either per-session or per-window) #57548
• User profile User profile #53453
• Enable/disable extensions from config file Feature Request: Enable/disable extensions from config file #40239
• Local Workspace settings [Feature] Local Workspace settings #40233
• Support "perspectives" like approach in VSCode Support "perspectives" like approach in VSCode  #95182

[miguelsolorio]

Here's the initial exploration of what profiles could look like, starting with a basic example of setting up a "Demos" profile. In this profile, the user can choose to either start with an empty profile (no settings/extensions) or keep their existing data.

Concept A

This concept shows the entry point from the gear menu, but it could also be enabled via the command palette. I didn't show what extension management looks like (yet) because it requires a bit more thinking.

[miguelsolorio]

Concept B

This concepts attempts to re-use the accounts menu in the activity bar and also creates a default profile and reduces the effort involved with creating/switching accounts.

[carlocardella]

One idea for settings is to introduce a new settings object like:

{
    "profiles": {
        "demos": {
            "files.autoSave": "onFocusChange",
            "editor.fontSize": 18,
            "editor.tabSize": 2,
            "editor.fontWeight": "600",
            "screencastMode.enabled": true,
        }
    },
    
    "editor.fontFamily": "Cascadia Code",
    "editor.renderWhitespace": "all",
}

The "Demos" profile inherits the current settings a user has and adds additional settings on top of the current ones. Also, when profiles are enabled we will create a "Default" profile where the user can switch back to their default mode.

So with this approach if I update a setting in the default profile (say editor.fontFamily) but I want the Demos profile to use the default font instead, it should be overridden with its default value here?

That would also mean that every change made in the default profile is automatically inherited by all other profiles? If the change was intended only for the default profile, all other profiles should be modified to revert that change?

I realize it is probably unlikely someone will have a high number of profiles (but who knows, really?); one way to avoid the revert problem above would be to not inherit from the default profile, maybe only use it as a starting point when a new profile is first created. Of course that also means if I change a setting in the default profile that I do want inherited, I'm out of luck... Maybe this inherit from default profile could be a setting as well?

[jjspace]

Maybe this inherit from default profile could be a setting as well

What if it was set up in a similar way to how .eslintrc can "extend" other configurations?

For example, when you create a new profile it starts with an "extends-profile": "default" setting which would mean it always inherits from the default, even if default changes. If you no longer want this behavior just remove this extends setting and this profile would go back to App defaults for everything that's not set for that profile?

This would also allow profiles to extend each other (and maybe even allow people to share them!). To go with OPs example, maybe I have a teaching profile with bigger font/zoom and some parts hidden. But now I start teaching another class in a different language and I want a different set of extensions or maybe a different theme that's better for this language. I could just create a new profile that extends my base teaching profile with just the new settings.

I guess this would still leave the question of "if I change a setting of the 'child' profile, which level of the config do I want it on, this one or the parent?" Maybe it's still best to have no inheritance at all and all new profiles should start with App defaults or duplicate the default at creation.

[jjspace]

Also not directly related to current conversation but the term "Profiles" threw me off at first. I was expecting something along the lines of User profiles like multiple Chrome accounts. Not different configuration sets. I think profiles works but it may be worth thinking of alternatives?

[miguelsolorio]

Yea I did originally play around with the "inheritance" concept, mostly focused on disabling it in a certain profile. The idea of mixing profile sounds interesting but would love to see a use case for it first because it could add some unnecessary complications, like you just described.

In terms of the term "Profiles", this one is tricky because we do also have user accounts where you login for certain extensions (like GitHub or Azure), so we want to make sure those are separated and not mixed. But thanks for this feedback, we'll gauge to see if we get similar feedback.

[yume-chan]

I prefer concept B. Looking together with #115641, maybe there is no such strong need for the account manager. I personally never touched it after setting up all my accounts.

However, from these early concepts, I did get how it will resolve all related issues.

• Can I use different profiles for different Code instance? Will it switch profile automatically when opening a workspace or enter/exit screencast mode?
• I care more about [Feature] Local Workspace settings #40233, what's the priority of profile settings? Will it be like user settings < profile user settings < workspace settings < workspace profile settings?

[gjsjohnmurray]

Another related issue is #95182, which proposes the term "perspectives".

[LucaGabi]

Here's the initial exploration of what profiles could look like, starting with a basic example of setting up a "Demos" profile. In this profile, the user can choose to either start with an empty profile (no settings/extensions) or keep their existing data.

Concept A

This concept shows the entry point from the gear menu, but it could also be enabled via the command palette. I didn't show what extension management looks like (yet) because it requires a bit more thinking.

This looks very good and easy to use also.
B is hard to navigate in my opinion.