[Development] [Announce] Qt 6.7.2 Released
2024-06-18
Thread
List for announcements regarding Qt releases and development via Announce via Development
Hi! We have released Qt 6.7.2, see https://www.qt.io/blog/qt-6.7.2-released Big thanks to everyone involved! Br, Jani Heikkinen Release Manager ___ Announce mailing list annou...@qt-project.org https://lists.qt-project.org/listinfo/announce -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changing Qt's Binary Compatibility policy
On Tuesday 18 June 2024 07:53:32 GMT-7 Giuseppe D'Angelo via Development wrote: > I think this is now effectively a separate thread of discussion, since > these deprecations create source incompatibilities, not binary > incompatibilities. > > Should we discuss it at the QtCS in a couple of slots? Please note we *can* have a binary-incompatible, source-compatible version, technically speaking. We do have two version numbers in our binaries: libQt6Core.so.6 The first 6 is the source version; the second one is the binary version. How to communicate the difference to users, how to market the versions, and whether it is worth the hassle are completely separate topics. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Systems Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changing Qt's Binary Compatibility policy
Hi, On 18/06/2024 10:15, Alex Blasche via Development wrote: Our biggest issue is the adoption of Qt by users moving from one major release to the next. The deprecations start to become a liability and while they keep SC compatibility in check for Qt 6 they become a serious concern for any adoption of Qt 7. While doing changes when it is necessary is OK as part of a major patch release, I totally agree with Andre that a lot of deprecations are nice to have and not mandatory. I would like to propose a far more restrictive process on when a deprecation is accepted (unless somebody has a better idea on how to curb this flood gate any other way). If you need any further prove of the seriousness of this problem, have a look at how long it took for KDE to adopt Qt 6 or look at the still incoming issues for Qt 5.15. Based on what I see, performance differences are the most common reason why Qt 6 is not ported to. The second one is the effort to port to Qt 6 due to mechanical porting from one API to the next. Qt 7 deprecations show an alarming trend and those mostly don't even involve truly needed architecture changes like potential QIODevice or QFileSystemEngine changes yet. (I only use these two classes examples to highlight the point and not that there is actual work being decided or ongoing) I think this is now effectively a separate thread of discussion, since these deprecations create source incompatibilities, not binary incompatibilities. Should we discuss it at the QtCS in a couple of slots? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: S/MIME Cryptographic Signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Adding CPD support to Qt print dialog
Hi all, The support for Common Print Dialog Backends has been in the works for a while. As of last year we are provisioning the SDK in our CI nodes: https://codereview.qt-project.org/c/qt/qt5/+/471258 but the change on Qt is stuck a bit. Could someone with experience and knowledge about the state of CPDB help with reviewing those patches, please? Open changes are in the chain at https://codereview.qt-project.org/c/qt/qtbase/+/437301/17 (need to be rebased and the SDK might need to be bumped to latest version v2.0b5). Thanks, Volker > On 17 Oct 2022, at 16:03, G G wrote: > > I have added CPDB support to the print dialog, and opened a pull request > here: https://codereview.qt-project.org/c/qt/qtbase/+/437301. It would be > great if anyone is able to review it. > > To build qt with CPDB support, make sure you have CPDB frontend library: > https://github.com/openprinting/cpdb-libs and CPDB CUPS backend: > https://github.com/openprinting/cpdb-backend-cups installed. Their debian > packages are outdated, since I had to make some one time changes and > improvements to CPDB while adding support to the GTK and Qt print dialog. > Once you have both of them installed, the "configure" command should > automatically pick up on the CPDB backend and prefer it over the CUPS backend. > > For now, I have used "#if QT_CONFIG(cpdb) ... #endif" constructs in the UNIX > print backend, and also added a CPDB Job widget, which shares the same UI as > CUPS Job widget but different implementation. > > Thanks, > Gaurav > > > On Fri, Sep 16, 2022 at 3:50 AM Gaurav Guleria wrote: > Hello all, > > I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add > and improve Common Print Dialog (CPD) support to existing print dialogs > like GTK and Qt. More about CPD can be read here: > https://openprinting.github.io/projects/04-print-dialog/. > > I wanted to ask about your opinions on the implementation and the way we > should proceed with it. I talked with a few people and read this old > article here: https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt > team prefers CPD support as a plugin rather than a direct integration > into the QPrintDialog. > > Just to summarize briefly, implementing CPD support directly in the > print dialog would mean that the Qt team wouldn't have to worry about > any future CUPS changes, or any other print backends for that matter, as > CPD will handle them all instead. > > It would be really helpful if you could share your views on this and > give your suggestions. > > Thanks, > > Gaurav > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changing Qt's Binary Compatibility policy
>From: Development on behalf of apoenitz > >Sent: Friday, 14 June 2024 19:32 >There are by now ~240 QT_DEPRECATED_VERSION_X_6_* in qtbase alone. Fixing them >today involves touching thousands line of code in my code base(s). Very few of >them are truly, clearly necessary. The bulk is "nice to have" or "should have >been like that from the beginning (but the benefit is not sufficient to >the drop the original)", and a few are just pain without (significant) gain. Our biggest issue is the adoption of Qt by users moving from one major release to the next. The deprecations start to become a liability and while they keep SC compatibility in check for Qt 6 they become a serious concern for any adoption of Qt 7. While doing changes when it is necessary is OK as part of a major patch release, I totally agree with Andre that a lot of deprecations are nice to have and not mandatory. I would like to propose a far more restrictive process on when a deprecation is accepted (unless somebody has a better idea on how to curb this flood gate any other way). If you need any further prove of the seriousness of this problem, have a look at how long it took for KDE to adopt Qt 6 or look at the still incoming issues for Qt 5.15. Based on what I see, performance differences are the most common reason why Qt 6 is not ported to. The second one is the effort to port to Qt 6 due to mechanical porting from one API to the next. Qt 7 deprecations show an alarming trend and those mostly don't even involve truly needed architecture changes like potential QIODevice or QFileSystemEngine changes yet. (I only use these two classes examples to highlight the point and not that there is actual work being decided or ongoing) >As an example for the latter: QCryptographicHash::addData() went from >QByteArray plus ptr/len overload to a single addData(QByteArrayView bytes). >Most of the existing uses were of the addData(reinterpret_castY*(), sizeof(something)) kind - ugly enough already, but now it needs >an additional QByteArrayView() wrapped around. Why? Why can't the ptr/len >overload just stay? One line, inline, on the library side? Because someone >doesn't like raw pointers but a struct with a raw pointer and an int will >save the world? Based on current adoption issues with Qt 5.15, these changes constitute an alarming adoption problem for Qt 7. I cannot even argue to a customer what good this change would do to his code or even Qt. The right way should have been to add the new function, leave the old one in and remove the old one from the docs/mark it as \internal. On Friday 24 May 2024 13:29:41 GMT-3 Giuseppe D'Angelo via Development wrote: >2) We stop guaranteeing forward binary compatibility within the same >minor version. For what it is worth, I agree too. -- Alex -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
