On Wed, 27 May 2026 at 20:03, Thiago Macieira <[email protected]> wrote: > > 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.
Do you have a guesstimate on how far the existing code would be from just being promoted as-is? -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
