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 [email protected] wrote:

Thanks.

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.