[criticalAY]

Note

Assisted-by: Claude Opus 5.5

Purpose / Description

Adopt the ViewModel progress for two more Card Browser loads: the Manage columns picker and the selected notes lookup before Find and replace opens.

• The filtered deck search is the last Card Browser site on the old wrapper. I left it for after fix: escape the deck name in filtered deck search #22007, which changes that code.

Fixes

• Part of architecture: support withProgress in ViewModels #19460

Approach

check commit

How Has This Been Tested?

• Emulator Pixel 9, API 31
  before n after

Learning (optional, can help others)

NA

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[mikehardy]

Assisted-by: Grok 4.7

Thank you — these two loads were the remaining browser sites still on the activity withProgress dialog, aside from the filtered-deck search you called out.

I did not push; prep replayed the PR tip locally at 00d8011. Lint Kotlin/JS, unit tests, and the emulator lane all passed (emulator-5556, API 35 google_apis).

BrowserColumnSelectionFragment.onViewCreated calls viewModel.loadColumnSelection(cardsOrNotes) inside launchCatchingViewTask. That is progressManager.withProgress { previewColumnHeadings(cardsOrNotes) }. previewColumnHeadings keeps activeColumns when the dialog mode matches the browser, otherwise reads BrowserColumnCollection from prefs. It then ColumnWithSample.loadSample on the first row: allBrowserColumns(), and, when a row exists, setActiveBrowserColumns for every column key, browserRowForId, then restores the previous keys in finally. The fragment splits that pair into the active and available recycler sections. The short-click path showColumnSelectionDialog still calls previewColumnHeadings with no progress wrapper.

showFindAndReplaceDialog calls activityViewModel.loadFindAndReplaceNoteIds(), which is progressManager.withProgress { queryAllSelectedNoteIds() }. That delegates to selectedRows.queryNoteIds: notes mode returns the in-memory ids; cards mode calls notesOfCards on the collection. After that returns, FindAndReplaceDialogFragment.newInstance is shown. The later findAndReplace op still has its own withProgress around the undoable replace, and it queries the selection again. showEditTagsDialog still calls queryAllSelectedNoteIds with no wrapper.

The lambda receiver inside withProgress is ProgressScope. previewColumnHeadings and queryAllSelectedNoteIds resolve on the outer CardBrowserViewModel. Neither helper starts its own progress, so these wrappers are not nested.

some acceptable findings, no action required, just leaving for posterity: Approach is check commit (the commit body already says what the two methods do); showColumnSelectionDialog still calls previewColumnHeadings directly, so a short click on a column heading does not publish progress; showEditTagsDialog still calls queryAllSelectedNoteIds directly, the same lookup loadFindAndReplaceNoteIds now wraps.

[ZornHadNoChoice]

Is there a reason you didn't use the new "Material" loading indicator?

[david-allison]

Code looks good, awaiting consensus on @ZornHadNoChoice's query

@ZornHadNoChoice @criticalAY

Let's timebox 2 days, then merge and move standardization of progress dialogs to an issue if it's not resolved by then

[criticalAY]

My “after” shot was taken on an emulator with animations off, but it does use it, sorry about the confusion fyi @ZornHadNoChoice

[criticalAY]

Diuble checked its cool!