Replace TaggedValue tabular variants for color and gradient with non-tabular forms

[Keavon]

We might not merge this, instead we may treat everything (including tables of color) as baked partial graph computations and that would be what the color picker widgets manipulate.

[gemini-code-assist]

Code Review

This pull request refactors the handling of colors and gradients by replacing Table-wrapped types with direct Color, Option<Color>, and GradientStops variants within TaggedValue. The changes span across node definitions, document migration logic, and UI property widgets to support these more concise types. The review identifies critical issues where the removal of tabular variants from TaggedValue and the property panel matching logic could break monitoring, memoization, and UI display for nodes still returning tabular data. Additionally, suggestions are provided to include missing type implementations for the color_value and empty_image nodes to ensure they function correctly with the new constants.

[gemini-code-assist]

Removing the Table<Color> and Table<GradientStops> variants from TaggedValue while they are still used as return types in the graph (e.g., in color_value, rgba_to_color, and sample_gradient) will cause try_from_any and try_from_std_any_ref to fail for these types. This will break monitoring and memoization for any node returning these tabular forms.

Since the tagged_value! macro (defined at line 33) generates these conversion methods by iterating over the variants, you should either:

1. Add manual conversion logic to the macro definition to map these Table types to the new non-tabular variants.
2. Keep the tabular variants as internal/deprecated forms to support runtime conversion of existing graph outputs.

[gemini-code-assist]

The removal of Table<Color> and Table<GradientStops> from the TypeId matching in property_from_type causes a UI regression. Many nodes in the graph still return these tabular types (e.g., color_value, rgba_to_color, sample_gradient). For these nodes, the Properties panel will now fail to display a color picker widget and instead show a fallback message indicating that no widget exists for the type.

These cases should be restored to maintain UI compatibility with nodes that still produce tabular return types. Note that color_widget will still work correctly because TaggedValue::from_type (used for initializing widgets) already maps these tabular types to the new OptionalColor and GradientStops variants.

Suggested change

	Some(x) if x == TypeId::of::<Color>() => color_widget(default_info, ColorInput::default().allow_none(false)),
	Some(x) if x == TypeId::of::<Option<Color>>() => color_widget(default_info, ColorInput::default().allow_none(true)),
	Some(x) if x == TypeId::of::<GradientStops>() => color_widget(default_info, ColorInput::default().allow_none(false)),
	Some(x) if x == TypeId::of::<Color>() => color_widget(default_info, ColorInput::default().allow_none(false)),
	Some(x) if x == TypeId::of::<Option<Color>>() => color_widget(default_info, ColorInput::default().allow_none(true)),
	Some(x) if x == TypeId::of::<graphene_std::table::Table<Color>>() => color_widget(default_info, ColorInput::default().allow_none(true)),
	Some(x) if x == TypeId::of::<GradientStops>() => color_widget(default_info, ColorInput::default().allow_none(false)),
	Some(x) if x == TypeId::of::<graphene_std::table::Table<GradientStops>>() => color_widget(default_info, ColorInput::default().allow_none(false)),

[gemini-code-assist]

The color_value node should include Color in its #[implementations] list. Since the UI now provides TaggedValue::Color(Color) for non-optional color inputs, the compiler will attempt to resolve this node with C = Color. Without this implementation, the node will fail to compile when used with a constant color value from the Properties panel.

Suggested change

	#[implementations(Option<Color>, Table<Color>)]
	#[implementations(Color, Option<Color>, Table<Color>)]

[gemini-code-assist]

The empty_image node is missing an implementation for Option<Color>. Because Table<Color> now maps to TaggedValue::OptionalColor in from_type, the UI will provide an Option<Color> to this node. Adding this implementation ensures the node remains functional with the new non-tabular color constants.

Suggested change

	pub fn empty_image<C: Into<Table<Color>>>(_: impl Ctx, transform: DAffine2, #[implementations(Color, Table<Color>)] color: C) -> Table<Raster<CPU>> {
	pub fn empty_image<C: Into<Table<Color>>>(_: impl Ctx, transform: DAffine2, #[implementations(Color, Option<Color>, Table<Color>)] color: C) -> Table<Raster<CPU>> {

[cubic-dev-ai]

1 issue found across 17 files

Confidence score: 3/5

• There is a concrete regression risk in editor/src/messages/portfolio/document_migration.rs: the migration currently forces exposed = false, which can silently change existing document behavior for users with previously exposed inputs.
• The issue is medium severity (6/10) with high confidence (9/10), so this is more than a cosmetic concern and justifies a moderate merge-risk score.
• Pay close attention to editor/src/messages/portfolio/document_migration.rs - preserve the original exposure flag during migration to avoid silently unexposing inputs.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/messages/portfolio/document_migration.rs">

<violation number="1" location="editor/src/messages/portfolio/document_migration.rs:1997">
P2: The color migration forcibly sets `exposed` to `false`, which can silently unexpose previously exposed inputs. Preserve the original exposure flag during conversion.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: The color migration forcibly sets exposed to false, which can silently unexpose previously exposed inputs. Preserve the original exposure flag during conversion.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/portfolio/document_migration.rs, line 1997:

<comment>The color migration forcibly sets `exposed` to `false`, which can silently unexpose previously exposed inputs. Preserve the original exposure flag during conversion.</comment>

<file context>
@@ -1986,6 +1986,31 @@ fn migrate_node(node_id: &NodeId, node: &DocumentNode, network_path: &[NodeId],
+	];
+	for &(ref identifier, input_index) in color_to_optional_cases {
+		if reference == DefinitionIdentifier::ProtoNode(identifier.clone())
+			&& let Some(NodeInput::Value { tagged_value, .. }) = node.inputs.get(input_index)
+			&& let TaggedValue::Color(color) = &**tagged_value
+		{
</file context>

Suggested change

	&& let Some(NodeInput::Value { tagged_value, .. }) = node.inputs.get(input_index)
	&& let TaggedValue::Color(color) = &**tagged_value
	{
	let color = *color;
	document.network_interface.set_input(
	&InputConnector::node(*node_id, input_index),
	NodeInput::value(TaggedValue::OptionalColor(Some(color)), false),
	network_path,
	&& let Some(NodeInput::Value { tagged_value, exposed }) = node.inputs.get(input_index)
	&& let TaggedValue::Color(color) = &**tagged_value
	{
	let color = *color;
	document.network_interface.set_input(
	&InputConnector::node(*node_id, input_index),
	NodeInput::value(TaggedValue::OptionalColor(Some(color)), *exposed),
	network_path,
	);