Library: multi-select datasets with bulk pipeline, training, and delete actions

[mattdawkins]

• The desktop Library (Recents) table gains a selection checkbox column on the right, replacing the per-row delete button; the column header is a select-all (indeterminate when partial, follows the active search filter)
• When anything is selected, Run Pipeline, Run Training, and Delete (N) buttons appear to the left of the search box (which keeps its position); delete shows one confirmation for all selected datasets (source media and originally imported annotation files are untouched)
• Run Pipeline / Run Training navigate to their pages with the checked datasets pre-staged via a datasetIds query parameter
• Bulk pipeline runs now launch only on staged datasets compatible with the selected pipeline

🤖 Generated with Claude Code

[BryonLewis]

I moved the checkbox to the right side to be more inline with the web/girder vesion as well as other software.

I also added a check to deletion to not fail on the first deleted item.

[mattdawkins]

I thought it was on the right side?

[BryonLewis]

I meant the left side

[mattdawkins]

I had it on the left side originally, didn't like it, and moved it to the right. Don't more software use right-aligned checkboxes here?

[BryonLewis]

aligning with the web version:

[mattdawkins]

Well, maybe the web version should be right aligned too?

In desktop anyways, looked a bit cluttered

[BryonLewis]

LLM response:

in UI design if you have a list of datasets or objects and want to perform actions on them where should the checkbox go, on the left or the right side?

Left side, as a strong default.

Why left wins:

Reading order — in LTR languages, eyes scan left to right. Putting the checkbox first means the selection affordance is the first thing encountered, before the person even reads the item name. This primes "I'm selecting things" mode.
Convention — Gmail, Google Drive, Finder/Explorer list views, most admin tables (Notion, Airtable, Linear) all put checkboxes on the far left. Breaking this convention makes people hunt for it.
Alignment with row selection logic — the checkbox typically sits before or in place of a leading icon/avatar, so the row reads as: [select] → [identity] → [metadata] → [actions]. That mirrors how people think: "which one, then what about it."
Leaves the right side free — the right edge of a row/table is prime real estate for per-row actions (edit, delete, "⋯" menu), status badges, or trailing metadata. Selection and action controls competing for the same side gets cramped and confusing.

When right (or elsewhere) might make sense:

Mobile card layouts sometimes put selection as a toggle in a corner (top-right) triggered by a "select" mode rather than always-visible checkboxes — because screen width is tight and swipe/long-press interactions dominate.
RTL languages (Arabic, Hebrew) — mirror everything, so the checkbox moves to the right to preserve the same reading-order logic.
If your rows already have a leading icon/avatar that's essential for scanning (e.g. a file-type icon), some designs put the checkbox as a hover-reveal that replaces that icon on hover/select, rather than adding a new column — still functionally "left," just overlaid.

One more practical tip: make the checkbox appear on hover if you want a cleaner default view, but keep it pinned/visible once a row is selected — losing an active selection because the checkbox disappeared is a classic frustration bug.