feat(dialog): WidgetData setListItemColors / listItemColors

[pabloinigoblasco]

Summary

Add a per-item foreground-color channel to the WidgetData dialog protocol so plugins can color entries inside a host-rendered QListWidget. The Filter Editor toolbox uses it to paint each entry of its source-curve picker list in the same color as the corresponding line on the plot — letting the user pick a curve by color instead of by name.

What setListItemColors is for (and what it isn't)

This addition colors items inside the dialog's QListWidget (the source-curve picker on the left panel of the Filter Editor). It is the channel the plugin uses to push a per-item color into WidgetData so the host can apply it to the QListWidgetItem when rendering.

It is not the path that colors the derived curve that lands on the plot after Save — that is plot-side logic and lives in pj_app directly (PlotWidget::addCurve(name, color) and friends), not in the dialog protocol.

Color	Where	Who applies it	API
Item inside the picker list of the Filter Editor dialog	The host-rendered QDialog	pj_dialog_host reading WidgetData::listItemColors	setListItemColors ← this PR
Derived curve drawn on the plot after Save	On top of the Qwt canvas, next to the other curves	pj_app via PlotWidget::addCurve(name, QColor)	Existing plotting API — unchanged

Why the setter has to live in the plugin (and not be host-derived)

The host renders a generic QListWidget — it has no semantic knowledge of what the list contains. Lists in PJ dialogs can be curves, topics, transform IDs, frequency bins, file paths, etc. Only the plugin knows that entry #3 of this list maps to the curve /imu/orientation/w and that that curve is red in the plot.

The plugin gets the curve→color information from the host when the dialog is launched, then writes it back into WidgetData via setListItemColors. The host reads it via listItemColors and applies it on render. Standard plugin↔host pattern, mirroring the existing setListItems / listItems channel on the same struct.

Why it matters (UX)

• Visual matching: red line in the plot ↔ red entry in the picker. Recognition is instant; no need to read the name.
• Multi-selection: the picker supports selecting several source curves and applying one transform to all (Filter Editor multi-select feature). With many similarly-named series (/imu/orientation/{w,x,y,z}, etc.) the color is the only discriminator that scales beyond two or three items.
• PJ3 parity: PJ3's transform-editor dialog colorizes its source list the same way.

ABI

• Additive only: one optional channel (std::optional<std::vector<std::string>>) on WidgetData, accessed through the matching getter on WidgetDataView.
• No field reorder, no struct shrink.
• Plugins that don't set the new channel render with the inherited foreground color (current behavior).
• No host or plugin recompile needed for existing extensions.

Generalization

The channel is generic. Any dialog plugin that shows a list of items with an associated semantic color benefits without further protocol changes (FFT picker per-channel, quaternion source picker, future toolboxes).

History

This branch previously included a remove_data_source runtime-host slot. After review feedback ("FilterEditor doesn't need to remove a DataSet") it was reverted — the Filter Editor uses the volatile DatastoreCurveAdapter model and never writes to the datastore, so it has nothing to remove on Reset. Only the WidgetData extension remains.

Downstream consumer

• PlotJuggler/PJ4#160 depends on this PR — the Filter Editor host wiring uses view.listItemColors(name) to color the picker list, and the CI on that PR is currently red until this lands and the SDK Conan package is bumped.

Test plan

• Existing widget_data_view_test still passes.
• Downstream consumer (Filter Editor in PlotJuggler/PJ4#160) renders the picker entries in plot-curve colors.