+1 for #2. Additional benefit for us: less maintenance at Qt Tools site.
For reference - please see Utils::Unarchiver (https://github.com/qt-creator/qt-creator/blob/master/src/libs/utils/unarchiver.h) - I would love if we could merge functionalities and reuse what comes in Qt for the Unarchiver in Creator. Best regards, Jarek ________________________________________ From: Development <[email protected]> on behalf of Thiago Macieira <[email protected]> Sent: Wednesday, May 27, 2026 7:01 PM To: [email protected] Subject: [Development] Either remove or make QZip{Reader,Writer} official QZipReader and QZipWriter are part of QtCore, as private API. They used to live in QtGui, but got moved a while ago to support some unit tests and because they don't *really* need anything from QtGui. QZipWriter is used inside of Qt, in the ODF file exporter in QtGui, but QZipReader is only used by unit tests and experimental code. It looks like QZipReader is one of the most requested features for Qt, one we have never provided. Keeping it as private API is, in my opinion, a big disservice to our users. This API is nowhere near the quality level that one would expect from Qt APIs. For one thing, as a private API, it is not subject to any bug reports ("submit patch please"), including security fixes. And yet users are finding it and using this private API, because it is there, and this prevents them from evaluating other solutions that may be superior. For example, there are KF6Archive and libarchive, each with their own limitations (out of scope). Therefore, I'd like to propose we take one of these two actions: 1) remove them 2) promote them to public and official API (which need not be source-compatible with what is there today) Clearly option #2 would be of higher value to our users, but it's also the one with the largest cost to us. We may also take both actions: remove now and re- add later, with a better & improved API, though that implies two separate disruptions. I am not volunteering myself to do #2. As maintainer of QtCore, I reserve the right to reject inclusion of the new class to the library I maintain if I do not feel the quality is good enough and/or the maintenance burden is too high. Therefore, my preference is #1: remove with no promise of coming back. If there are volunteers to work, I would suggestion you check on the possibility of wrapping libarchive with a nicer Qt API and create a new module. This may greatly reduce our maintenance burden. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng. -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
