Peacock without a workspace: Allow option for colors to only affect one user and one instance

[johnpapa]

Currently the extension sets the colors in workspace settings. THis means whatever settings are in that file are then either gitignored or allowed, and then team members will also get your color. It may be desirable for many to only let the color affect one instance of vscode and for a specific user.

[burkeholland]

This is kinda related to #8.

I think it's ok to set it in the workspace settings. If you set any other colors there, they will also change for other people.

[johnpapa]

But is that undesirable? Imagine I change to bright yellow and you get it too, you may not like that?

[burkeholland]

This is true, but if you change any other color in the editor, I will get that too. What makes the title bar special?

[johnpapa]

Good question. Let me clarify a little.

If you change a color and put it in user settings, it is your color setting and applies only to you, but across all of your VS Code instances.

If you change a color and put it in workspace settings, it is (by default) a changed file that will go to github and apply to anyone who gets your repo, only for VS Code instances opening that code base.

The workspace settings will affect others, unknowingly.

The user settings don't do that ^^ , but won't let you color each code instance

Does that make sense?

[burkeholland]

What if we allow both? Set it for everyone in workspace settings, or read from editorconfig? Editorconfig would override workspace settings. This would address #8 as well and is something I can work on.

[johnpapa]

Interesting. But it won’t solve the original problem of allowing you to color one instance and not impose it on others. If it goes in user settings then every code window for you would be the same color still

[crossan007]

What about adding a key-value pair list to the user settings value; indicating a color for each "known" workspace file (maybe by workspace name)?

[johnpapa]

Had this neat idea from the Code team

You could easily set a user setting like:

  "peacock" : {
    "/development/vscode-browserpreview" : {
      "titleBar.activeBackground": ""
    }
  }

And namespace/scope the settings to a particular workspace path. Not shared and local to the user.

------
Kenneth Auchenberg

[sdsalyer]

Hi there. :) Great idea for an extension @johnpapa . Kind of in the vein of this thread:

1. is it possible to just set a temporary color (ie. per session / in memory) without creating the .vscode/settings.json in the folder directory?
2. It might also be useful to have per-language settings (e.g. SQL files are red, c# files are blue, etc.).

Thanks for listening!

[johnpapa]

Thanks.

1. hmmm. i dont think so. i think it needs to be in the settings.

2. The idea for coloring files (maybe the tabs) has come up (somewhere in here or twitter). I'm not sure it would be fun nor useful to look at a code instance with files tabs of red, yellow, blue, etc ... maybe too much color then. or did i miss your intention?

[sdsalyer]

re: 2, I guess I was thinking the active file's language association would color the title bar, etc. (not necessarily the tabs -- I agree that would be unpleasant with more than a couple colors). I suppose it could get rather hectic, though, if switching between different languages regularly. It was just a thought.

If you figure out #1 though, temporarily changing the color setting, that would be boss. :-)

On Fri, Mar 1, 2019, 11:25 AM John Papa notifications@github.com wrote:

Thanks.

1.

hmmm. i dont think so. i think it needs to be in the settings. 2.

The idea for coloring files (maybe the tabs) has come up (somewhere in here or twitter). I'm not sure it would be fun nor useful to look at a code instance with files tabs of red, yellow, blue, etc ... maybe too much color then. or did i miss your intention?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johnpapa/vscode-peacock/issues/7#issuecomment-468722828, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkbhpdXWxDUa7ssI0U3WqlYZsgwLp_Jks5vSVRegaJpZM4bJqmh .

[stratosgear]

I think this really needs to be resolved.

I definitely do not want to share my workspace colors with any other user of the project, and I definitely would not want to "receive" a garish color from any of my colleagues (beauty is in the eye of the beholder, after all).

Peacock, is not really usable for me now, as is, because I cannot commit code when the workspace settings have been altered... :)

But I would really like to use it to differentiate different opened code instances...

How about that idea from some posts back...?

[musicfuel]

@johnpapa I've been playing with this a bit focusing on the namespacing idea that Kenneth provided you with. Currently I've got it storing values in the User settings file so that it looks like:

"peacock.workspaceColorCustomizations": {
    "/Users/musicfuel/Projects/vscode-ext/vscode-peacock/testworkspace": {
        "activityBar.background": "#1accff",
        "activityBar.foreground": "#15202b",
        "activityBar.inactiveForeground": "#15202b99",
        "activityBarBadge.background": "#df00ad",
        "activityBarBadge.foreground": "#e7e7e7",
        "titleBar.activeBackground": "#00b3e6",
        "titleBar.inactiveBackground": "#00b3e699",
        "titleBar.activeForeground": "#15202b",
        "titleBar.inactiveForeground": "#15202b99",
        "statusBar.background": "#00b3e6",
        "statusBarItem.hoverBackground": "#008bb3",
        "statusBar.foreground": "#15202b"
    }
},

The idea is that you could store a workspace's settings in this manner and then use activate/deactivate of the extension on application start, close, or workspace change to apply or clean up the customizations. The issue I can't get around is the whole concept of writing to workbench.colorCustomizations to override the colors. Doing so modifies the file and if the developer or team is not ignoring the file then it will certainly get inadvertently committed at some point.

Any ideas on how to apply Peacock coloring without modifying that file? I know in 1.32 some new support for applying themes came online, but I am pretty sure that is not available to extensions.

[johnpapa]

I'm not sure.

Writing to user settings feels like it would be a big change ... meaning a lot to test and probably more than the tests currently cover. I'm open to it, but I sense some hurdles, such as what you point out.

Another idea is to create a .peacockrc file (as also suggested in some other issues by community folks). This doesn't solve it on its own, but at least then the changes are contained in one place. Then they would have to be applied somehow (maybe write them to the workspace settings and then clean them up?). It feels a bit error prone to me.

The only way to do this is to write to the settings file (that I know of). So whether it stores in user settings or another file, somehow they need to be applied. And that will update the workspace.

adding @auchenberg as he may have some ideas

[musicfuel]

Yes I agree. I don't like writing to the user settings either as that is a big change, but an aspect I do like of it is that it is scoped to the user and only the user. One issue with the .peacockrc approach is that we then still have to deal with how you have changes only impact you and not your other teammates when they pull the latest changes. I suppose that file could simply be part of the .gitignore (or other SCM ignore) and just be something that the team has to do to make this work.

In any of the cases, we are still left with the fragility of applying the settings and cleaning them up using the workbench.colorCustomizations approach. The code that looks for and applies those settings is in colorThemeData.ts and it currently allows for two forms--the one we've been using and a slightly different syntax to override only a specific theme:

"workbench.colorCustomizations": {
    "[Monokai]": {
        "statusBar.background": "#000"
    },
    "[Solarized]": {
        "statusBar.background": "#db57ac"
    }
}

This seems similar to what @auchenberg was referring to as an approach, but this is just for themes and doesn't really solve the problem of different workspaces and/or different users.

[johnpapa]

For reference, here is an issue in the VS Code repo that proposes a local workspace setting https://github.com/Microsoft/vscode/issues/40233#issuecomment-466390248

Quoting the original idea:

So there would be three locations for settings (for a single-folder workspace): user settings

• ${workspaceRoot}/.vscode/settings.json
• ${workspaceRoot}/.vscode/settings.local.json

This would work well for our scenario, too. But I do not know if it is on the roadmap.

[musicfuel]

It's been open for quite some time. It does sound like something Peacock could very much take advantage of.

[auchenberg]

We don't have a good way to do this from a programatic context. You could leverage multi-root workspace settings, but that wouldn't be great for single workspaces. @johnpapa

[granmoe]

There was talk (in a mentioned VS Code issue, I believe) of having a third kind of vs code config that would be workspace-specific yet not shared. The objection to this was that it would complicate the settings story (understandable), but I disagree. It would be as simple as defining a .vscode-user/settings.json and then putting this in your .gitignore (or equivalent in other SCMs). Then you get workspace-specific user settings that are not shared, solving our issue.

That said, I think writing out the settings to normal user settings with color settings namespaced under each directory path is the ideal solution if possible.

(Sorry if I'm repeating something that was already said. I've been jumping around issues and may have lost track of what was said where.)

[dkpalmer]

Just wanted to +1 the desire to manage in my own user settings and not in the workspace. I already know the rest of my team could never agree on a color 😅. Right now I'm just not checking in my peacock workspace settings.

[johnpapa]

The idea is that you could store a workspace's settings in this manner and then use activate/deactivate of the extension on application start, close, or workspace change to apply or clean up the customizations. The issue I can't get around is the whole concept of writing to workbench.colorCustomizations to override the colors. Doing so modifies the file and if the developer or team is not ignoring the file then it will certainly get inadvertently committed at some point.

Any ideas on how to apply Peacock coloring without modifying that file? I know in 1.32 some new support for applying themes came online, but I am pretty sure that is not available to extensions.

@auchenberg is there a way to do this ^^^ ? To sum up, if we store the color settings in a namespaced property in user settings, we are thinking we still have to write them to workspace settings while the session is active, and wipe them when deactive. How can that be done?

Or is there a way to have the colors be read from the namespaced user settings?

[tommck]

I find it weird that vs code doesn't have a ".user" settings file like VS does.

But, I would much prefer to have some file outside the workspace folder controlling this, since deleting a folder/re-retrieving from source control wouldn't wipe out my settings.

[LiamDobbelaere]

+1 I don't want to use Peacock so long as it modifies the workspace settings.json :\ I don't want to accidentally check in the Peacock color changes, we do use our workspace settings file for other important settings so it's not like I can gitignore it

[mtwilliams5]

My team have inadvertendly come across this issue without even intending to use Peacock - Peacock gets installed as part of the Live Share extension pack, which we've recently started using, and as a result we keep getting .vscode/settings.json files created in the workspaces we're in. Half the time, these settings files are empty, or other times they seem to pull in colour customisation settings from the user settings.json file that were set outside of peacock for the user who happens to be hosting the live share at the time and aren't intended to be shared. Since our working pattern normally ends up with us hopping between three or four different workspaces/repos within a piece of work, we don't want to go through and add .vscode to the gitignore for all of them, especially when this behaviour is being triggered by something that we're not even actively using...

[johnpapa]

@mtwilliams5 thanks for the feedback. I've added @lostintangent (from Live Share) and @egamma (from VS Code) to let them know some of the feedback you and others have reported on this.

There is not much more I can do at this time as Peacock writes to that file. If we had a way to write to a different file for workspace & user specific file that was auto-git-ignored, that would solve both issues mentioned here:

1. not wanting to git ignore the settings
2. not wanting to share the same colors

i'm open to any new ideas on how to solve this (see previous threads for what has been tried).

You can disable the peacock extension, too.

One idea I hadn't thought of before ... because Peacock does write to this file when it detects it is newly installed. I could add a setting that effectively tells Peacock to be disabled and not write to the file. This feels wrong to me ... since there is a way to disable it already though ... so try that first.

[musicfuel]

I still think the ideal scenario would be for VS Code itself to allow for overriding the current theme colors without writing to the file. The need to write to a physical file is the issue that is tripping people up because it then leaves it on their teams to manage/ignore it or makes the logic of Peacock more complex with adding or removing it in a session.

If we could apply Peacock colors without the need to write to the file then it would be easy to change the extension to:

1. Always apply the style overrides to the current session virtually without the file
2. Add a command to write the current style to the workspace
   • Via user settings (possibly using the namespace approach mentioned above)
   • Via the workspace settings file so that it can be committed to the project for all of the team

I know this is not possible now, but I wonder if it could be made possible through a contribution to the VS Code code base.

[johnpapa]

That, @musicfuel , is a good idea! I know we discussed this before, but have you put this in the attached VS Code threads? i wonder if the team would be open to this. @egamma - would this be a possibility for a community member to help extend VS Code to allow it to change colors without writing to a file?

[musicfuel]

I don't think I ever wrote to the attached threads, but I know I looked into the code a bit at the time to see if there was any potential to add support for it. The https://github.com/microsoft/vscode/issues/40233#issuecomment-466390248 mentioned above has bits and pieces of it in the comments now, but doesn't seem like right issue to attach this to. I'll take a look at the existing issues around theme colors and see if there are any existing requests for this.

[octogonz]

@johnpapa Have you considered having Peacock write its color configuration into a MyProject.code-workspace file instead? That file is a pretty good place for local user settings, and then the shared settings can go in .vscode/settings.json. (See here for docs.)

This has the slight disadvantage that you have to remember to open the workspace file (code MyProject.code-workspace) instead of opening the folder (code .). But VS Code reminds you about that when it sees a .code-workspace file.

The workspace approach also works for other user-specific settings such as launch.json. And you can even have multiple .code-workspace files for the same repo folder.

[egamma]

@octogonz it is correct that you can put settings into the code-workspace file. However, the code-workspace file is typically checked into the repository and shared with the team. It therefore affects other users as well.

[jooeycheng]

Hi @johnpapa, would VS Code Project Manager's approach of having a local configuration file under the user settings work? It's essentially a central json keeping track of colors for each workspace.

[johnpapa]

Yes. Thanks for sharing that. I’ll look at it.

Storing project workspace settings in user settings can work but it has some downsides. I would have to copy them to workspace when you open a project and remove later. That still writes to workspace settings and can be buggy.

Some other issues listed above too.

But there is hope - local settings look like they are coming to vs code! The issue we linked to here is being worked on in April. I have no idea yet what form it will take or if or how it will help peacock. But - I am hopeful.

So stay tuned.

[jooeycheng]

I see. Thanks for the prompt response!

I would have to copy them to workspace when you open a project and remove later.

Ah, I didn't know that. So, we cannot escape writing to workspace config, given how VS Code works right now?

[johnpapa]

Vs code reads the setting to determine the colors. So it has to be in user settings or workspace settings.

No worries

[gurgeous]

Great extension and I really want to use it! Just chiming in to say that I can't at this time because our team shares .vscode/settings.json and I can't commit to that file. That would be a gaffe on my part.

[mediantiba]

@johnpapa I love this extension but I'm hesitant to use it due to this very issue. I wouldn't want to force anyone to use my colors, let alone this extension if they didn't want to.

What if you write the config to some other file, e.g. .vscode/peacock.json which can be added to the git ignore list, wouldn't that solve the problem?

The extension could then read config based on priority, 1 being the highest and 3 being the lowest.

1. peacock settings (peacock.json)
2. workspace settings (settings.json)
3. user settings (global settings.json)

I don't know if I missed anything, but that way it would make it very easy to use the extension both individually and/or in a team environment :)

[musicfuel]

@mediantiba That is a good idea. Unfortunately the central problem behind this is not storing the settings in a manner that keeps them local and is instead about applying them to the interface of VS Code. Currently, the extension works by overriding the workbench.colorCustomizations setting in .vscode/settings.json. We could load settings for only you from the peacock.json file which is ignored, but it would then need to apply those changes to .vscode/settings.json which really shouldn't be ignored and typically is not. This makes a modification to that file which then can very easily be committed to the repo by accident.

Currently this mechanism is the only way for an extension to apply colors to the interface short of changing the theme completely which is not something this extension aims to do. Many solutions have been discussed, but all roads lead to changing .vscode/settings.json in the current session to actually apply the colors. There does appear to be ongoing work in the VS Code API to enable what Peacock wants to do to address this problem, but that hasn't landed into a release as of yet.

[johnpapa]

Well Said @musicfuel

[musicfuel]

To extend my comment above, see https://github.com/microsoft/vscode/issues/40233 for active discussion on how to deal with local settings. The simplest solution that many are arguing for (including @johnpapa) is to allow for some kind of settings.local.json file that could be created in the workspace folder. This file would then override workspace settings in the "default -> user -> workspace" settings inheritance. The file would allow for teams to still have common workspace settings, but individual users to override them. It would then be a determination of the user or team on how to manage that file in source control, but generally the idea is that someone savvy enough to create the file is also likely to setup the ignore support.

For some reason there is pushback to this approach in the thread, but I tend not to agree with the arguments and counter-proposal to it.

[mediantiba]

Thanks for the detailed explanation, @musicfuel, I wasn't aware of the limitations regarding this matter. Well, what can I say, I guess I hope to see local settings come to VS Code in a future update.

[prateekkathal]

Bump!

[tom-sherman]

@prateekkathal please don't do that. There are a lot of people subscribed to this issue so that we can receive important updates, this type of comment is just spam in people's inboxes. See https://blog.sindresorhus.com/issue-bumping-e3b9740e2a0

[ivangretsky]

There does appear to be ongoing work in the VS Code API to enable what Peacock wants to do to address this problem, but that hasn't landed into a release as of yet.

@musicfuel , what are those features that are being worked on? We could at least go thumb them up)

[ThaDaVos]

I am currently running into this myself - something like a settings.local.json would solve it I think - as we want to commit our settings.json as it contains configurations for shared used extensions, like i18n-ally and stuff

[aisbergde]

I would prefer a separate file, which can be added into .gitignore Then I will not disturb other users with my settings. For example, I am using a bookmarks extension. It has its own file "bookmars.json" in the ".vscode" folder, and I can easily add it to .gitignore Why not just use a file "peacock.json", which contains only the peacock settings?

[RexBarker]

So I'm here in 2023 with the same issue. I just installed peacock and it looks great...functions how I would like it. However, it's modifying my settings.json which is under git control (project wide). From this loooong history here, I still don't understand if the issue was resolved. Is there some other way to keep the peacock settings without using the settings.json file?

[carlocardella]

If all you care about is user settings (settings.json) you could use a local only workspace (not under source control). For some of my repos I have a local workspace file (the file is saved in a separate folder, not under source control) that contains only the project folder. Color changes would be saved in this workspace file and will not affect other users unless you explicitly share the workpace file with them.

If you do care about workspace settings (or yours are under source control) then you are in the same boat as everyone else here 😃.

I guess one could also experiment with the new Profiles (still in preview) since that creates a separate local settings file, not under source control.

[aisbergde]

Why it should be so complicated, instead of just using a separate file which can be included into the .gitignore? This would be intuitive and transparent.

Another idea is to gitignore the whole settings file. I think, it is better to use the general settings file for general project settings, and there should be a user specific setting file. But this is currently not the case in VSC. It would resolve some other issues with other settings to.

The profile solution seams to be complicated, but maybe it could be a way. I have no idea, how. Should the extension support profiles? Or how to define, which settings for which project will be stored in a profile?

[carlocardella]

I know the separate workspace file just for the sake of storing some settings may seem complicated, I mentioned just because it works today with what we have at our disposal. Other solutions may require changes to Peacock (doable) or VSCode itself (a bit more complicated, even if in theory still doable).

The Profiles solution does not need much really: you can create a new Profile through the VSCode menu (it takes just a few seconds) and uses your current settings as base. Once you are in the new profile, any config changes made are local to this profile instance, it's up to you if you want to source control this file or not. Switching between profiles is not perfect yet (it's a bit slow for large profile files) but it takes just a couple of clicks.

That being said, I think the ideal solution would be for Peacock to deal with the problem directly.

[ivangretsky]

Why it should be so complicated, instead of just using a separate file which can be included into the .gitignore? This would be intuitive and transparent.

That being said, I think the ideal solution would be for Peacock to deal with the problem directly.

100% agreed