style(dialogs): unify picker tables (selection, edit, sort, header)

[facontidavide]

What

Brings the topic / channel / camera / sequence picker tables across the plugin dialogs onto one consistent idiom, and captures a follow-up SDK design for the one axis that can't live in a .ui file (per-column resize behavior).

Picker idiom (the 5 multi-select lists)

All now share: MultiSelection · SelectRows · NoEditTriggers · sortingEnabled · verticalHeaderVisible=false.

Picker	Before	Change
foxglove topicsList	editable, no sort, header shown	+ NoEdit, + sort, hide vHeader
pj_bridge topicsList	editable, no sort, header shown	+ NoEdit, + sort, hide vHeader
webrtc camerasList	editable, no sort, header shown	+ NoEdit, + sort, hide vHeader
ros2 listRosTopics	ExtendedSelection	→ MultiSelection
mosaico topicTable	ExtendedSelection	→ MultiSelection

Why MultiSelection over ExtendedSelection: in a picker, a bare click under ExtendedSelection silently clears the previous selection — a footgun when users expect to accumulate picks. MultiSelection makes a bare click toggle/accumulate, which matches the "Select one or multiple…" labels these dialogs already show.

Deliberate exceptions (unchanged):

• mosaico seqTable stays SingleSelection (single-select by design, now explicit).
• Both mosaico tables keep sorting off — they filter rows by index via setVisibleRows, and user re-sorting would desync that index mapping.

Not addressed here (tracked)

Per-column resize-to-content (e.g. MCAP Encoding, Msg Count hugging their content while the name column stretches) can't be expressed in a .ui file — column sizing is owned by the host's installTreeLikeHeader(). The second commit adds a design spec + TDD implementation plan for an additive, header-only WidgetData::setColumnResizeMode / WidgetDataView::columnResizeModes protocol addition spanning plotjuggler_sdk → PJ4 → this repo. Not implemented in this PR.

Notes

• These .ui files are embedded verbatim and parsed at runtime (no uic); all 5 were validated well-formed.
• No code changes — behavior-only .ui attributes + docs.

🤖 Generated with Claude Code

[facontidavide]

Codex review follow-up (pushed 973a78c)

An independent Codex review flagged a real issue in the original branch: the host realizes plugin .ui files through QUiLoader, which honors sortingEnabled and turns on Qt's built-in sort. Per the SDK dialog guide (dialog-plugin-guide.md), built-in sort desyncs any picker that restores/reads selection by row index (setSelectedRows/selectedRows()), because the sorted view's index no longer maps to the plugin's own unsorted vector.

Per-picker selection contract (verified in code):

Picker	Selection restore	Safe with built-in sort?	This PR
foxglove topicsList	text (setSelectedItems)	✅	sort on (kept)
pj_bridge topicsList	text (setSelectedItems)	✅	sort on (kept)
webrtc camerasList	index (setSelectedRows)	❌	sort removed (was a new regression)
ros2 listRosTopics	index (setSelectedRows)	❌	pre-existing sort untouched (out of scope)
mcap tableWidget	index (setSelectedRows)	❌	pre-existing sort untouched (out of scope)
mosaico seqTable/topicTable	index (setVisibleRows)	❌	correctly off

Fix in 973a78c: drop the sortingEnabled I had added to camerasList (with an inline comment so it isn't re-added), and correct the resize-mode docs (foxglove topicsList has 3 columns incl. Encoding, not 2).

Follow-up (not this PR): mcap and ros2 already ship sortingEnabled=true with index-based selection — a latent instance of the same issue. Making those genuinely sortable the SDK-correct way needs plugin-owned onHeaderClicked re-sorting; worth tracking separately.

[facontidavide]

Follow-up: mcap + ros2 sort now fixed in-PR (0b994d3)

Digging into the two pre-existing index-based pickers, the desync turned out to be latent behind a coincidence, not a live bug: both row vectors are already name-sorted (mcap std::sort by topic; ros2 std::map iteration) and the widget's default sort is column-0 ascending, so restore indices happen to line up in the common path. It desyncs only when the user sorts by another column, on a std::string-vs-QString collation edge, or (ros2) during the 1 Hz live rescan while re-sorted.

Rather than leave that fragility, per request this PR now drops sortingEnabled from both. The row order stays alphabetical (the vectors are pre-sorted), so the only thing lost is click-sort-by-other-column — which was exactly the broken path. Genuinely sortable columns remain a possible follow-up via plugin-owned onHeaderClicked re-sorting.

Final state — built-in sort is on iff selection restore is text-based:

Picker	Restore	sortingEnabled
foxglove topicsList	text	✅ on
pj_bridge topicsList	text	✅ on
webrtc camerasList	index	❌ off
ros2 listRosTopics	index	❌ off
mcap tableWidget	index	❌ off
mosaico seqTable/topicTable	index	❌ off

[facontidavide]

Course correction: pickers are now genuinely sortable (force-pushed, 9c41ae1)

I initially misread the goal and removed built-in sorting to dodge the index-desync bug. That was backwards — the ask is for sortable columns (default column-0). I've dropped that detour (force-pushed) and instead fixed the root cause the right way: restore selection by first-column text, not row index, so it survives Qt's built-in sort. This is the same pattern foxglove/pj_bridge already use.

Now sortable (built-in sort on, default column 0):

• foxglove topicsList, pj_bridge topicsList — already were (text-keyed).
• ros2 listRosTopics — converted setSelectedRows → setSelectedItems (topic name).
• webrtc camerasList — converted to setSelectedItems (unique display label, 1:1 with stream id). Verified compiles under -Werror -Wconversion.

Deferred to a follow-up (need cross-repo work):

• mcap tableWidget also disables empty channels by row index (setDisabledRows) — no text-keyed equivalent, so it would desync under sort.
• mosaico filters by row index (setVisibleRows) — same class.
• The clean fix for both is plugin-owned sorting via onHeaderClicked, but the host doesn't currently deliver header clicks for tables (onHeaderClicked is declared in the SDK but QHeaderView::sectionClicked is never wired) and there's no sort-indicator API. That's a PJ4 host + SDK addition.

Branch (3 commits): unify pickers → resize-mode docs → make ros2/webrtc sortable. mcap/mosaico left exactly as they were on main (unchanged by this PR).