Error indicators in project panel should use different border for selected files

[WeetHet]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

In #18182 error indicators were added. For the selected file, the border used for the error icon is of an incorrect color

Environment

Zed: v0.162.0 (Zed Nightly 55cd99c)
OS: macOS 15.1.0
Memory: 8 GiB
Architecture: aarch64

[nilskch]

I can change that later today if this is not intentional?

[WeetHet]

I can change that later today if this is not intentional?

I think it doesn't look good, but I'd prefer to hear @danilo-leal's opinion on it

[danilo-leal]

You're referring to the white stroke around the x, right? If that's the case, this is a bit challenging at the moment because these different states in the project panel items (like hover or selection) use colors that leverage opacity, whereas the diagnostic icon uses a solid color. If we use exactly the same token as we use for the states, the knockout effect wouldn't quite work.

That original PR was merged because I think we're in a good spot with icon positioning, API to do the icon knockout effect, and, generally, the functionality. But there's still room to make this perfect, which includes possibly refining the color tokens we use for project panel items, ensuring the knockout thing always works well.

Does this make sense?

[WeetHet]

If that's the case, this is a bit challenging at the moment because these different states in the project panel items (like hover or selection) use colors that leverage opacity, whereas the diagnostic icon uses a solid color. If we use exactly the same token as we use for the states, the knockout effect wouldn't quite work.

It seems like, when the file isn't in focus, the white stroke blends in with the background. Can't we update the decoration color depending on the status of the entry?

[danilo-leal]

We can yeah, but it's what I said—other states of the project panel item use transparent colors, which means the icon stroke wouldn't blend perfectly as they do in the resting/default state. The solution seems to be not in the color used by the icon, but rather in the color token itself.

[WeetHet]

We can yeah, but it's what I said—other states of the project panel item use transparent colors, which means the icon stroke wouldn't blend perfectly as they do in the resting/default state. The solution seems to be not in the color used by the icon, but rather in the color token itself.

Yeah, makes sense

[nilskch]

@danilo-leal I did not understand this completely so I might be missing something, but I played around a little and I think item_colors.selected needs to be item_colors.marked_active instead.

zed/crates/project_panel/src/project_panel.rs

Lines 2808 to 2812 in 093c9cc

	if is_marked || is_active {
	item_colors.selected
	} else {
	item_colors.default
	},

selected and default are the same color here:

zed/crates/project_panel/src/project_panel.rs

Lines 254 to 264 in 093c9cc

	fn get_item_color(cx: &ViewContext<ProjectPanel>) -> ItemColors {
	let colors = cx.theme().colors();
	ItemColors {
	default: colors.surface_background,
	hover: colors.ghost_element_hover,
	drag_over: colors.drop_target_background,
	selected: colors.surface_background,
	marked_active: colors.ghost_element_selected,
	}
	}

For hovering we could use item_colors.hover (the screenshot removed the mouse, but its the hovering state):

Would this work or am I missing something?

[nilskch]

I think this works pretty well. I'm going to create a PR for this tmr. I think we should fix this before #18182 makes it into the normal release.

[danilo-leal]

Yeah, good call @nilskch. I opened up #20723 to update the active color and remove the not used selected variable. Hover is trickier—curious about how you pulled it off as we don't have some akin to is_marked.