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 ***@***.***> 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 <#7 (comment)>, 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 microsoft/vscode#40233 (comment)

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

[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

[dferber90]

I use the Project Manager extension all the time. It has a projects.json file (under ~/Library/Application Support/Code/User/globalStorage/alefragnani.project-manager/projects.json) with a structure like

[
  {
    "name": "flags",
    "rootPath": "/Users/xxx/Sites/happykit/flags",
    "paths": [],
    "tags": [],
    "enabled": true
  },
  // .... and more projects ...
]

This defines the projects available in VS Code that I can then quickly switch between.

It would be really useful if Peacock could store its settings in the same file, as my goal would be to use a different theme for each project. Using the same file has the benefit that the settings file is outside of any workspace, so no changes to .gitignore would be necessary. I'm not sure how technically possible this is, but it would be my ideal setup. If it can't be the same file, then a separate file for the Peacock extension itself would be the next best choice.

[dandax]

I don't think this is a Peacock problem at all. It's a very simple extension that builds on top of existing VS Code behavior. I've been following this issue (microsoft/vscode#40233) for this exact reason. We should be looking at local/personalized settings instead of individual configuration. Local workspace settings would solve many more issues for everyone.

[benoitemile]

It might not be a Peacock issue but still, vscode issue you linked was created 5 years ago, we might need a solution until vscode solves it for good, there are plenty of possibilities listed here so we could avoid all those conflict, git stashing, git stash popping that very settings.json.

Like a .peacockrc that we could globally gitignore to avoid doing it in each repo.

[dandax]

It might not be a Peacock issue but still, vscode issue you linked was created 5 years ago, we might need a solution until vscode solves it for good, there are plenty of possibilities listed here so we could avoid all those conflict, git stashing, git shash popping that very settings.json.

Like a .peacockrc that we could globally gitignore to avoid doing it in each repo.

Linking to a previous comment for reference #7 (comment). Also note the two following comments. That was May 2020.

[benoitemile]

Ok but I hope you got the point, it's 2.5years, maybe we could have a temporary solution until vscode provides desired behavior ?

[ivangretsky]

It might not be a Peacock issue but still, vscode issue you linked was created 5 years ago, we might need a solution until vscode solves it for good, there are plenty of possibilities listed here so we could avoid all those conflict, git stashing, git shash popping that very settings.json.
Like a .peacockrc that we could globally gitignore to avoid doing it in each repo.

Linking to a previous comment for reference #7 (comment). Also note the two following comments. That was May 2020.

ok, but maybe 2.5 years later there is a hook that could be made to modify the settings read from .settings file with the ones read from .peacockrc before they get applied? Just a guess)

[nakah]

With the 1.75 release of VS Code, you can now have different profiles (1 profile = 1 user settings.json).
To make it work, I've created one profile per workspace. Then you copy the settings generated by Peacock to your profile's settings.json.
I know it's not automated and it's more a workaround than a solution but it works !
You have your own color theme for your workspace without annoying your whole team 😊

[eckdanny]

Agree @nakah the recently-released Profiles feature does not solve this. The Local Workspaces feature microsoft/vscode#40233 (still open at the time of writing this) would be better. There exists an extension Workspace Config+ that seems to provide that Local Workspace behavior (curious if anyone in this thread has tried yet?)

My workaround so far has been to add .vscode/settings.json to <repository-root>/.git/info/exclude after a clone (since it rarely changes if its tracked at all).

@johnpapa If Config+ is a more elegant workaround, could Peacock be configured to write to settings.local.json instead? Presumably, that'd be needed if #40233 ever ships. I don't think the solution space here is in Peacock itself.

UPDATE:

The extension Workspace Config+ works fine with Peacock. IMO, this is cleanest way until microsoft/vscode#40233, microsoft/vscode#15909 get addressed in vscode

[acelinkio]

My primary use case is to differentiate between my open vscode windows. Is there a way to just have Peacock set the current windows color randomly to and not write any configurations?

I am happy with a low tech solutions. If a color is reused, I can just close the window and reopen it again. I would rather not deal with managing state.

[NickBolles]

@johnpapa until the referenced local settings.json features hit in vscode, what do you think about adding a command to ignore the .vscode/settings.json file for convenience. Right now I'm running this command to ignore the settings.json changes since it's rarely changed (no idea if there are downsides to this yet).

git update-index --assume-unchanged ./.vscode/settings.json

A Peacock: Ignore .vscode/settings.json changes and Peacock: UnIgnore .vscode/settings.json changes (which would run with --no-assume-unchanged instead)

[fordneild]

https://marketplace.visualstudio.com/items?itemName=swellaby.workspace-config-plus

This extension solved the problem for me, by allowing me a settings.local.json

[jadnhm]

This issue has been open a long time and it seems not everyone is up to the task of reading the entire thread (as I just did...) so I thought I would grab this excellent summary of the crux of the problem by quoting @musicfuel

#7 (comment)

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

To paraphrase: the ONLY WAY to change the colours in VSCode at the present time is to write the "workbench.colorCustomizations" to one of the official VSCode settings files

All the comments suggesting that 'Peacock could simply write to its own file!' are completely missing the point.

It seems like some of the more recent commenters are having luck with Workspace Config+ and I am going to give that a whirl also, but this is still not a great solution because you're ultimately copying the "workbench.colorCustomizations" out of one of the official VSCode settings files (where Peacock knows to write those settings out) and into the special 'local' file so it can be utilized by the Workspace Config+ extension.

We're all still crossing our fingers that microsoft/vscode#40233 gets some traction and something is done about this by Microsoft/VSCode core team.

[georgeshevtsov]

git update-index --assume-unchanged .vscode/settings.json probably will do the trick for those that don't plan updating your settings.json anytime soon

[jadnhm]

yes and I use git update-index --skip-worktree .vscode/settings.json but then you have to remember /undo/ that when you need to change that file which does sometimes happen....

https://web.archive.org/web/20200604104042/http://fallengamer.livejournal.com/93321.html

[alecmce]

FWIW, I got here from https://stackoverflow.com/questions/72618635/visual-studio-code-workspace-settings-json-file-keeps-reverting-when-i-open-the after too long manually reverting settings.json. Glad to have finally found the cause!

[superjose]

Yesterday, I did an unintended April Fools.

I thought the colors only affected the ones who had peacock installed.

Oh boy, I was wrong.

You gotta see the faces of all the team members when they saw that flashy pink on their screen.

Priceless 👌

[AferraroMezrah]

This issue has been open a long time and it seems not everyone is up to the task of reading the entire thread (as I just did...) so I thought I would grab this excellent summary of the crux of the problem by quoting @musicfuel

#7 (comment)

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

To paraphrase: the ONLY WAY to change the colours in VSCode at the present time is to write the "workbench.colorCustomizations" to one of the official VSCode settings files

All the comments suggesting that 'Peacock could simply write to its own file!' are completely missing the point.

It seems like some of the more recent commenters are having luck with Workspace Config+ and I am going to give that a whirl also, but this is still not a great solution because you're ultimately copying the "workbench.colorCustomizations" out of one of the official VSCode settings files (where Peacock knows to write those settings out) and into the special 'local' file so it can be utilized by the Workspace Config+ extension.

We're all still crossing our fingers that microsoft/vscode#40233 gets some traction and something is done about this by Microsoft/VSCode core team.

But now with Profiles, don't they write to the official VSCode settings, and they change when you switch profiles? I'm pretty sure this feature was asked about before Profiles existed. But now that they have been released I was wondering if they could be the solution?

[jadnhm]

If there is a way to use profiles to do this no one has discovered/written about it yet AFAICT.

I just tried it again myself and it sure looks to me like this is still true:

To paraphrase: the ONLY WAY to change the colours in VSCode at the present time is to write the "workbench.colorCustomizations" to one of the official VSCode settings files

[jylenhof]

Maybe a solution is to use something like (supported only on Linux and MacOS, not WSL...sadly) :

cd github/myworkspace
code --user-data-dir .vscode.local .

This create a User settings in .vscode.local/User/settings.json on each on your workspace
You put your own peacock configuration
You can still have a .vscode directory for common settings

You add .vscode.local to .gitignore