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

keep workbench color customizations when using status bar color #2122

Merged
merged 12 commits into from
Nov 16, 2017

Conversation

twin-tigon
Copy link
Contributor

When the status bar color is controlled by the current mode, the workbench color customizations get overwritten by the status bar customizations, removing any previous existing customization. This change merges both existing and status bar customizations to avoid this behavior.

@jpoon
Copy link
Member

jpoon commented Nov 14, 2017

I believe this fixes #1654 and #2150

@jpoon jpoon self-requested a review November 15, 2017 04:25
@@ -2065,11 +2065,11 @@ export class ModeHandler implements vscode.Disposable {
setStatusBarColor(color: string): void {
vscode.workspace.getConfiguration('workbench').update(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider separating the get and the update into two separate lines for readability.

@jpoon
Copy link
Member

jpoon commented Nov 15, 2017

With this change, it also means that if you have workbench configuration, the statusBar settings are ignored.

As the colorCustomizations lives at the workspace level (https://code.visualstudio.com/docs/getstarted/theme-color-reference), this seems like the only alternative.

Soliciting @zelphir and @thousand opinions as they both filed related issues (#2150, #1654). Would this fix satisfy your ask?

@thousand
Copy link

@jpoon looks good to me! I would expect that the plugin's behavior could overwrite or replace the behavior of the related configs.

vscode.workspace.getConfiguration('workbench').update(
'colorCustomizations',
{
Object.assign({}, currentColorCustomizations, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never used Object.assign before, is there a difference between:

  1. Object.assign({}, currentColor....) and
  2. Object.assign(currentColor...,

ie. why do you need the initial {}?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first parameter of the Object.assign function is the target object. Like you wrote below, it works like an upsert, where from left to right properties get merged.

This is the behavior that I intend, since I want to get a copy of the color customizations and then overwrite its properties regarding the status bar.

The target object gets modified by the Object.assign call, that's why I pass an empty object at first. But indeed, in this case, this is not needed. I will remove it.

@jpoon
Copy link
Member

jpoon commented Nov 15, 2017

Actually, I misinterpreted the behaviour of object.assign, I thought it would only set the value if the key is null (like null coalescing), but it's more of an upsert.

That being said, that means we'll be overwriting some settings at the workbench level. I'm OK with this change, but want to double-check with your opinions @thousand @rodrigo-garcia-leon @zelphir on that's what you guys expect.

@jpoon
Copy link
Member

jpoon commented Nov 16, 2017

Thanks @rodrigo-garcia-leon

@twin-tigon
Copy link
Contributor Author

No problem! 😄

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants