Enhance color logic for phantom elements to improve visual distinction based on collision status#42710
Conversation
… state This change modifies the color assignment for phantom elements in the editor. If a phantom element collides with existing elements, it now uses a custom color based on the theme's debugger accent with reduced opacity. Otherwise, it defaults to the hint color. Release Notes: - Enhanced color logic for phantom elements to improve visual distinction based on collision status.
|
Hey, thanks for the PR! I'm not sure if I'm following what's the improvement here... effectively, I see that there's now a hover state color difference for set breakpoints, which I'm not sure if it's an upgrade because the lighter color due to reduced opacity makes me think for a second whether the breakpoint is disabled or something. Is there another testing case I'm missing? Maybe I'm unsure which other elements could be considered as "phantom", but I'm assuming this is all about the breakpoint, given we're inside |
|
Sorry to make you confused. My initial idea was to adjust the interaction of creating breakpoints in zed to be translucent red when creating breakpoints as in vscode/jetbrains, and to fix the color when the mouse passes over the already created breakpoints. However, I found that zed has actually implemented the distinction between these two states, so what I can think of is to distinguish the color of the breakpoints that have been created, so that I can know whether this operation is creating a breakpoint or canceling a breakpoint. But actually I’m not sure whether my idea is in line with zed’s design concept. I’m sorry that I made the modification without opening an issue for discussion first. I’m sorry. |
|
If my idea is wrong please tell me and I will close this pr :) |
danilo-leal
left a comment
There was a problem hiding this comment.
Thank you for following up! I think when I initially ran the branch vs. main, I didn't see that we were persisting the regular color when hovering an already set breakpoint; this is definitely an improvement! I tweaked the color, though, so it is lighter rather than darker on hover, just so it doesn't get confused with a disabled state.
…n based on collision status (zed-industries#42710) This change modifies the color assignment for phantom elements in the editor. If a phantom element collides with existing elements, it now uses a custom color based on the theme's debugger accent with reduced opacity. Otherwise, it defaults to the hint color. BEFORE:  AFTER:  Release Notes: - Enhanced color logic for phantom elements to improve visual distinction based on collision status. --------- Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This change modifies the color assignment for phantom elements in the editor. If a phantom element collides with existing elements, it now uses a custom color based on the theme's debugger accent with reduced opacity. Otherwise, it defaults to the hint color.
BEFORE:
AFTER:
Release Notes: