Environment

• deepin 25.2.0 (July 7, 2026 ISO)
• deepin-compressor 6.5.31
• Hardware: ASUS Vivobook Go (Intel i3-N305, 8GB RAM)

Summary

Extracting large archives (tested with a 7.1GB ZIP containing thousands of nested files) causes the Archive Manager window to become completely unresponsive in repeated bursts throughout the extraction, and overall extraction is noticeably slower than before this regression was introduced. This did not happen prior to updating to 25.2.0.

Root cause (traced in source)

The Jan 20, 2026 commit b00add3 ("Remove pzip plugin and update CMake configuration") replaced the previous in-process, worker-thread-based pzip plugin with CliPzipPlugin, which shells out to external pzip/punzip binaries via QProcess.

In 3rdparty/clipzipplugin/clipzipplugin.cpp, the constructor calls:

setWaitForFinishedSignal(true);

This flag is read in SingleJob::start() (src/source/archivemanager/singlejob.cpp):

if (m_pInterface->waitForFinished()) {
    doWork();   // runs directly on the calling thread (GUI thread)
} else {
    d->start(); // spins SingleJobThread (proper worker thread)
}

Because CliPzipPlugin sets this flag true, extraction jobs now run doWork() directly on the GUI thread instead of on SingleJobThread as before. This means the plugin's QProcess and QTimer, plus its readyReadStandardOutput handler (which parses punzip's progress output line-by-line in readStdout()), all execute on the main thread. For archives with many files, each stdout buffer flush triggers a burst of synchronous line-parsing on the GUI thread, freezing input handling until the burst completes — repeating throughout the extraction.

Confirmed not resource-bound

free -h and vmstat 1 captured during the freeze show idle CPU (id 60–95%), minimal I/O wait (wa 1–3%), and no swap usage — ruling out hardware/RAM/disk as the cause. This is purely an application-level threading issue, unrelated to Treeland or any Wayland/compositor work in this release.

Suggested fix

Move CliPzipPlugin's process handling onto a proper worker thread — either revert setWaitForFinishedSignal to false and ensure the plugin's QProcess/QTimer are safe to run on SingleJobThread, or explicitly moveToThread() them so stdout parsing doesn't block the GUI event loop.

Steps to reproduce

1. Create or obtain a ZIP archive several GB in size with thousands of nested files
2. Open in Archive Manager, extract
3. Observe: window becomes unresponsive in bursts corresponding to progress updates, until extraction completes