[OmarGonD]

Problem

Sometimes clicking a folder shows nothing, and the contents only appear after several more clicks (seen in large trees such as ~/Projects).

Folder listings, folder counts, previews and descriptions all ran on the global thread pool. Counting huge or slow subfolders can occupy every thread and queue the listing of the folder just opened behind them. Further clicks bump the generation and overtake the stuck work, which is why retrying eventually works.

Changes

• Folder listings now run on a dedicated pool (8 threads), and folder counts on a small separate one (2 threads), in foldermodel.cpp.
• Backend::showItem was missing Q_INVOKABLE, so clicking a file in the columns view logged FolderColumns.qml:222: Property 'showItem' of object Backend is not a function.

Testing

• Builds; the full test suite passes (196 passed, 0 failed).
• The hang is intermittent and I haven't reproduced it deterministically, so the pool change is based on reading the code and is not yet confirmed in daily use.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The changes affect folder loading and file selection in Folio.

The PR appears safe to merge, with a non-blocking fix needed for the cancellation test.

Findings

1.  Cancellation test controls wrong pool ▶

Summary

Separates folder reads from background counts and makes Backend::showItem callable from QML.

• Folder listings keep their workers separate from folder counts.
• QML file clicks can now call showItem.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Reload["FolderModel::reload"] --> Listings["Listing pool: 8 threads"]
  Listings --> Results["Show current results"]
  Results --> Counts["Counting pool: 2 threads"]
  Counts --> Updates["Update folder counts"]
  Other["Previews and descriptions"] --> Global["Global pool"]

Loading

_{Reviews (1) · Last reviewed commit: "Give folder listings their own thread po..." · Reviewed by Greptile}

[greptile-apps]

Cancellation test controls wrong pool

folderModelStopsReadingWhatsBeenOvertaken still limits the global pool to one thread, but listings now use listingPool() with eight threads. The next listing can finish on another thread even if the old read never stops, so the test no longer checks cancellation. Update the test to constrain the pool that actually runs listings, or check cancellation directly.