kcamcam / vscode_dark_modern.zed

VS Code Dark Modern theme for Zed
MIT License
6 stars 2 forks source link

Add missing colors #5

Closed 2zqa closed 1 month ago

2zqa commented 1 month ago

Changes suggested by @MatthewScholefield. I didn't override any fields already added by @nikeee. I did notice that the suggested colors differ from Matthew and nikeee - maybe something to discuss? Considering we're porting a theme, I assume there should be only one correct answer.

Closes #3

MatthewScholefield commented 1 month ago

Three notes on the colors:

  1. For some reason, for things like the indent guides, setting the same color as vscode didn't result in the same color visually on zed. So I decided to just keep testing values until the measured color code matched.
  2. For most of the other UI elements, there's not a 1-1 equivalent in VSCode so the colors are more by feel. For example, VSCode highlights matching brackets with a grey outline on the token rather than a grey background but putting that shade as a background would be too strong. The same applies to the current line background. The hover color on panels is primarily used in the same context, but the bars are slightly thicker for zed and the hover overrides selected items (but I suppose those should be pulled directly from vscode which I didn't do).
  3. To further complicate things, I primarily used pure white with low opacity for most elements which can blend to the same color as other colors. The benefit of this is that colors can blend on top of each other so for example the current line indicator blends with the indent guide indicators so where they cross it is a little brighter.

TL;DR, fine to choose either color in general; the above are just some reasons why there might not be "one true" answer for certain colors and why it's probably best to just choose a self-consistent color scheme that feels the most similar.

2zqa commented 1 month ago

Thanks for the insight! I guess porting is not that "absolute" or rigid as I like to think. Well in theory it maybe could be, but that would be a pipe dream.

MatthewScholefield commented 1 month ago

Oh actually the indent_guide values refer to the guides on the left of the code when it is indented which aren't shown in the screenshot. This is different from the vertical ruler color which hasn't been customized.

Regarding the ghost element changes, those modify the left sidebar hover and active colors.

2zqa commented 1 month ago

@kcamcam, could you perhaps co-assign @MatthewScholefield to this PR? Although I made the branch, the rationale and actual values come from Matthew and thus I think he should have the say here. (Although I'm happy to give my opinion on things and make any suggested changes)

EDIT: If GitHub even allows multiple assignees. Otherwise, please leave it as-is.

kcamcam commented 1 month ago

@2zqa I added @MatthewScholefield as an assignee but I think you might have meant reviewer? Unless if someone is a contributor on the repository I can't add them as reviewers.

kcamcam commented 1 month ago

@MatthewScholefield thanks for pointing out the proper attributes that are being referenced. That as very helpful.

kcamcam commented 1 month ago

@2zqa please see my supplemental findings below:

I don't see a difference in before and after for editor.indent_guide_active, ghost_element.hover, or ghost_element.selected. But like I said before the explicit value is preferred over he null value which would (I assume) fallback to the default values of Zed, which could change.

The proposed values for ghost_element.selected #333333 (51,51,51) don't seem closer to the original values on VS Code #2A292F (14,57,92) and not much different from the default values on Zed #30302F (48,48,47).

To summarize my previous comment with this one:

It's possible that I'm looking at the completely wrong elements again or my machine is interpreting the values in a strange way. But unless if you can help provide screen shots and justification for the rest of proposed changes (including warning.background). In current state of the pull request I think we could only move forward with predictive and element.active.

However, I'm happy to keep the pull request open if you would like to continue working on editor.indent_guide, editor.indent_guide_active, ghost_element.hover, and warning.background together.

editor.indent_guide_active before

indent guide before

editor.indent_guide_active after

indent guide after

ghost_element.hover before

ghost hover before

ghost_element.hover after

ghost hover after

ghost_element.selected before

ghost selected before

ghost_element.selected after

ghost selected after

ghost_hover.selected orignal

ghost hover original



2zqa commented 1 month ago

as an assignee but I think you might have meant reviewer

@kcamcam No I meant assignee, because it signals that they too are responsible for getting the PR merged. I'm kinda only the messenger here really, but I'm willing to help. The reviewer should be only you since you are the sole maintainer of this repository at the moment.

However, I'm happy to keep the pull request open if you would like to continue working [...] together

I agree on this, lets not merge unfinished work into main. Main should always be usable by end users. @MatthewScholefield, would you mind taking a look at the feedback? I'll also see if I can make any changes somewhere this week, including merging the latest changes from main into this branch.

MatthewScholefield commented 1 month ago

Just getting to this. So I installed the theme from main with the latest color import and decided to rigorously recreate the overrides using exact rendered color values for simplicity even though it isn't a perfect match for VSCode (if you look closely at spots where colors overlap in VSCode, you will see their colors use alpha).

Here's the current list of overrides, pulled directly from screenshots of VSCode:

        "predictive": "#6b6b6b",
        "editor.document_highlight.read_background": "#37373d",
        "element.hover": "#212b35",
        "element.active": "#04395e",
        "ghost_element.selected": "#37373d",
        "ghost_element.active": "#37373d",
        "hint": "#494949",
        "editor.indent_guide": "#404040",
        "editor.indent_guide_active": "#707070",
        "title_bar.inactive_background": "#1f1f1f",
        "warning.background": "#1f1f1f",
        "warning.border": "#404040",
        "error.background": "#1f1f1f",
        "error.border": "#404040",

And below is a series of screenshots for each override compared to the latest colors merged into the repo.

Screenshots

predictive Before: After:
editor.document_highlight.read_background Before: After:
element.hover Before: After:
element.active Before: After:
ghost_element.selected Before: After:
ghost_element.active Before: After:
hint Before: After:
editor.indent_guide Before: After:
editor.indent_guide_active Note: Difference is not visible with the naked eye but the active line changes from #787670 to #707070 Before: After:
title_bar.inactive_background Before: After:
warning.background / warning.border Before: After:
error.background / error.border Before: After:

Personal Overrides

Beyond this, there are a series of personal overrides that I will likely be applying on top of the above that diverge from the explicit values copied from VSCode, but I think make sense for self consistency:

        "editor.document_highlight.read_background": "#ffffff04",
        "element.hover": "#ffffff02",
        "ghost_element.hover": "#ffffff02",
        "ghost_element.selected": "#ffffff07",
        "title_bar.inactive_background": "#1a1a1a"

Explanations:

editor.document_highlight.read_background This controls the background color highlighted enclosing braces relative to the cursor location. In VSCode this is rendered as a box which changes fewer pixels and is thus less visually distracting. To maintain the same level of minimal visual distraction when clicking the cursor around in the code, the brightness of this value needs to be lowered.
element.hover This is actually a dual purpose color; it's used both for the background of the token that's hovered within the editor and the hover background for clickable menu elements within the code actions dialog. To make the hover color of the code actions dialog more natural, using an uncolored white alpha seems the most natural and matches the lightness of the hover background effect used in VSCode (it just isn't blue tinted anymore).
ghost_element.hover / ghost_element.selected This is the shade placed over a clickable ghost item, which basically includes files in the left sidebar and entries within the right click / top / f1 menu. VSCode has a strong blue accent vibe going on in the left side with their blue remote development button in the bottom left, their blue logo in the top left, and their blue notification badges. For this reason, their slightly blue tinted hover effects look relatively natural next to the stronger blue accents. Zed, however, is missing these places to show the blue accent so the tinted blue hover effect over the pure grey background looks out of place and unnatural which is why I opted for a pure grey override. Since the other menu locations have a brighter background than the left sidebar, using a rendered grey value makes it blend in with the background too much within the menus. However, using pure white with alpha provides a subtle yet distinguishable brightened background in both places.
title_bar.inactive_background This is the shade drawn on the titlebar when the window is not focused (newly introduced config). The default override feels fine under most cases, except when dragging the window it renders the titlebar with an unfocused color (I asked if this is intentional [here](https://github.com/zed-industries/zed/pull/14266#issuecomment-2227326566)). When it renders at a color matching the tab color, it visually indicates a complete loss of focus which is counterintuitive IMO since you are currently dragging it. So to counter this, using a color in between the two still gives some visual change when the window loses focus without making it feel unusual while dragging the window.
2zqa commented 1 month ago

Yes, that'll be up to me (unless Matthew makes their own PR). I think I'll have time to update it tomorrow.

2zqa commented 1 month ago

Had some snafu's with applying changes (forgot to rebase) but it's all good now.