Re: [Development] Documenting Qt 6 API breakages
> On 27 May 2020, at 17:22, Riitta-Leena Miettinen > wrote: > > Hello, > > How about using a similar approach to that used for documenting the CMake > commands for each module in Qt 5.15? > > That is: > > • Create a qdoc file in each module that contains the breakages for > that module and contains the \ingroup command migrate2qt6, or something like > that. > • Create the \group page in the qtdoc module for central access to the > information. > This seems like a sensible approach to me. The detailed documentation lives close to source and we can keep the higher level overview documentation in a single location. P. > Cheers, > > Leena > > > Leena Miettinen > Sr. Documentation Engineer > > The Qt Company GmbH > Erich-Thilo-Str. 10 > D-12489 Berlin > riitta-leena.mietti...@qt.io > http://qt.io > > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > > Date: Wed, 27 May 2020 14:48:57 + > From: Kai Köhne > To: "development@qt-project.org" > Subject: [Development] Documenting Qt 6 API breakages > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > We should start documenting the API changes that Qt 6.0 brings soon. This > will allow getting people getting an overview, help early adopters, and will > give us time to improve the documentation before the release. > > Now I see that there are different paths taken: > - Eskil and others have started listing changes in a page in the qtdoc > repository, https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html > - I created a skeleton for Qt Core changes in the qtbase repository: > https://codereview.qt-project.org/c/qt/qtbase/+/299664 . > > I wasn't aware of the existing page in qtdoc; Anyhow, from past experience I > prefer having the documentation nearby the actual code. I therefore would > like move the existing sections about Qt Quick, Qt OpenGL to the respective > module documentation and let > https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html just link to the module > documentation pages. > > Thoughts? > > Kai > > -- > Kai Köhne, Director R | The Qt Company > > The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > > > -- > > Subject: Digest Footer > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > > > -- > > End of Development Digest, Vol 104, Issue 63 > > > ___ > 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] QMetaMethod in Qt 6
On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote: > > this is not something we can subject our users to. > > orly? kde had been doing that for quite a while. And I fixed QtCore to do the same. The only reason not to include the moc output in your .cpp is if you don't have one (a header-only class whose only non-inline methods are the moc- generated ones). Otherwise, #include your mocs. That said, we shouldn't enforce this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Documenting Qt 6 API breakages
Hello, How about using a similar approach to that used for documenting the CMake commands for each module in Qt 5.15? That is: * Create a qdoc file in each module that contains the breakages for that module and contains the \ingroup command migrate2qt6, or something like that. * Create the \group page in the qtdoc module for central access to the information. Cheers, Leena Leena Miettinen Sr. Documentation Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin riitta-leena.mietti...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Date: Wed, 27 May 2020 14:48:57 + From: Kai Köhne To: "development@qt-project.org" Subject: [Development] Documenting Qt 6 API breakages Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi, We should start documenting the API changes that Qt 6.0 brings soon. This will allow getting people getting an overview, help early adopters, and will give us time to improve the documentation before the release. Now I see that there are different paths taken: - Eskil and others have started listing changes in a page in the qtdoc repository, https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html - I created a skeleton for Qt Core changes in the qtbase repository: https://codereview.qt-project.org/c/qt/qtbase/+/299664 . I wasn't aware of the existing page in qtdoc; Anyhow, from past experience I prefer having the documentation nearby the actual code. I therefore would like move the existing sections about Qt Quick, Qt OpenGL to the respective module documentation and let https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html just link to the module documentation pages. Thoughts? Kai -- Kai Köhne, Director R | The Qt Company The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Subject: Digest Footer ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- End of Development Digest, Vol 104, Issue 63 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
On 5/27/20 3:58 PM, Matthew Woehlke wrote: *Nothing* there clearly states, at least to my reading, whether the "new" transform happens*before* or*after* any existing transforms that the QTransform is already doing. IMO, changing this to clarify that would help significantly. Sure, augmenting the docs would help. But the whole point of the API is for its usage to be straightforward. If you do QTransform t; t.translate(); t.rotate(); t.scale(); auto result = t.map(foo); the "obvious" meaning should be that foo is getting first translated, then rotated, then scaled; not the other way around. If this is achieved by pre or postmultiplication of (transposed) matrices matters only if you're into Algebra™ -- i.e. poking into the actual matrix, or if you're combining two transforms by means of operator*. Otherwise, it is not interesting at all in 99% of the cases, where you'd just set the transform on a painter or an item similar. If you really want to use the "low levels", please also note that operator* is helping you: QTransform t1, t2; QTransform t = t1 * t2; // ok... auto result = foo * t; // can only premultiply! // operator*(t, foo) does not exist So you've built foo * t1 * t2, with t1 applied first. (This in turn should reveal how QTransform works internally.) My 2 c, -- 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 - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
Hi, I think the documentation is actually clear on the order by the scale() example. I'm not sure whether we should at explicitly the concept of intrinsic transform: https://en.wikipedia.org/wiki/Euler_angles#Definition_by_intrinsic_rotations The current QTransform documentation always states transforming the coordinate system. Probably, it's supposed to be easier to understand compared the word "intrinsic". The order of extrinsic transforms would be exactly the opposite of intrinsic transforms. Regards, Dongxu On Wed, May 27, 2020 at 10:09 AM Edward Welbourne wrote: > > > Here is, for example, the documentation of QTransform::scale: > > > > Scales the coordinate system by sx horizontally and sy vertically, > > and returns a reference to the matrix. > > > > *Nothing* there clearly states, at least to my reading, whether the > > "new" transform happens *before* or *after* any existing transforms that > > the QTransform is already doing. > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > -- Dongxu Li, Ph.D. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Documenting Qt 6 API breakages
Hi, We should start documenting the API changes that Qt 6.0 brings soon. This will allow getting people getting an overview, help early adopters, and will give us time to improve the documentation before the release. Now I see that there are different paths taken: - Eskil and others have started listing changes in a page in the qtdoc repository, https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html - I created a skeleton for Qt Core changes in the qtbase repository: https://codereview.qt-project.org/c/qt/qtbase/+/299664 . I wasn't aware of the existing page in qtdoc; Anyhow, from past experience I prefer having the documentation nearby the actual code. I therefore would like move the existing sections about Qt Quick, Qt OpenGL to the respective module documentation and let https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html just link to the module documentation pages. Thoughts? Kai -- Kai Köhne, Director R | The Qt Company The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
Matthew Woehlke (26 May 2020 18:15) wrote: >>> The documentation is not clear if the scale, rotate, etc. methods of >>> QTransform apply *before* or *after* whatever the QTransform is already >>> doing. The bug report indicates that they are applied *first*. >>> >>> Given the potential for breaking existing code which expects the current >>> behavior, my inclination would be to clarify the documentation to >>> clearly state the existing behavior. On 27/05/2020 04.34, Edward Welbourne wrote: >> Yes, the docs do need updated; they do correctly say what QTransform does Matthew Woehlke (27 May 2020 15:58) > Really? Where? In the example code it includes. Not that I'm saying this is a good way to convey what's happening, but it did tell me everything I needed to know to work out what QTransform does. > Here is, for example, the documentation of QTransform::scale: > > Scales the coordinate system by sx horizontally and sy vertically, > and returns a reference to the matrix. > > *Nothing* there clearly states, at least to my reading, whether the > "new" transform happens *before* or *after* any existing transforms that > the QTransform is already doing. Indeed, although the class comment does say things from which it can be worked out - though I'm not sure every reader can be expected to. > IMO, changing this to clarify that would help significantly. No disagreement here, as I said (and you quoted): >> Yes, the docs do need updated; Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
On 27/05/2020 04.34, Edward Welbourne wrote: Matthew Woehlke (26 May 2020 18:15) wrote: The documentation is not clear if the scale, rotate, etc. methods of QTransform apply *before* or *after* whatever the QTransform is already doing. The bug report indicates that they are applied *first*. Given the potential for breaking existing code which expects the current behavior, my inclination would be to clarify the documentation to clearly state the existing behavior. Yes, the docs do need updated; they do correctly say what QTransform does Really? Where? Here is, for example, the documentation of QTransform::scale: Scales the coordinate system by sx horizontally and sy vertically, and returns a reference to the matrix. *Nothing* there clearly states, at least to my reading, whether the "new" transform happens *before* or *after* any existing transforms that the QTransform is already doing. IMO, changing this to clarify that would help significantly. I would argue this should be done *even if* the class description explains this. However, I didn't find any clarification there, either. (Admittedly, I did not rigorously read the entire description, but that's still making my point; if it's hard to find, users are going to be confused.) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] [Announce] Qt for Python 5.15.0 is out! (and 5.14.2.2 too!)
Hello everyone, I'm really happy to announce that Qt for Python 5.15.0 is finally out :) At the same time, due to all the changes we did in 5.14.2 we decided to do another release after all the feedback we got with 5.14.2.1, so that means that 5.14.2.2 is also out :D You can check the changelogs here: https://code.qt.io/cgit/pyside/pyside-setup.git/tree/dist/changes-5.14.2.2 https://code.qt.io/cgit/pyside/pyside-setup.git/tree/dist/changes-5.15.0 Check out the blog posts we wrote: https://www.qt.io/blog/qt-for-python-5.15.0-is-out As always, thanks to every person involved, both users and developers, your help was crucial to improve our project! Have a great day! -- Dr. Cristian Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ 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] QMetaMethod in Qt 6
On Wed, May 27, 2020 at 08:21:48AM +, Fabian Kosmale wrote: the only way to get this to work is to include the moc file in the same cpp file. While doing this inside of Qt is possible, this is not something we can subject our users to. orly? kde had been doing that for quite a while. also, it wouldn't be exactly rocket science to make the build system wrap each cpp with its corresponding moc file before passing it to the compiler. the matching would be heuristical, so it would still need manual includes in corner cases, but that's hardly a big deal. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
Matthew Woehlke (26 May 2020 18:15) > The documentation is not clear if the scale, rotate, etc. methods of > QTransform apply *before* or *after* whatever the QTransform is already > doing. The bug report indicates that they are applied *first*. > > Given the potential for breaking existing code which expects the current > behavior, my inclination would be to clarify the documentation to > clearly state the existing behavior. Yes, the docs do need updated; they do correctly say what QTransform does, but that behaviour managed to confuse me for a while, too. > (Note: I didn't actually test this myself or look at the code, I am just > going off of what the bug report says. In any case, however, the > documentation should be fixed.) Indeed. I did test this myself, and was surprised that double a = qDegreesToRadians(45.0); double sina = qSin(a); double cosa = qCos(a); QCOMPARE(QTransform().translate(50, 50).rotate(45).scale(0.5, 1.0), QTransform(0.5, 0, 0, 1.0, 0, 0) * QTransform(cosa, sina, -sina, cosa, 0, 0) * QTransform(1, 0, 0, 1, 50.0, 50.0)); passes. However, once it did, I knew what was going on ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QMetaMethod in Qt 6
The task: Currently, when using QMetaMethod::parameterType, we end up doing a costly string comparison. In order to get rid of the property cache in QML, we need faster way to obtain the metatype of method parameters and return types. This also has some benefits outside of QML, as it should speed up non-pointer-to-member function based connects, as well as QMetaMethod::invoke. The first solution: Thanks to Olivier's work, we already have a way to create the QMetaType [1] for properties at compile time. The straightforward solution was to extend this work to also cover the QMetaMethod use case, which is what the patch at https://codereview.qt-project.org/c/qt/qtbase/+/294774 does. The catch: Unfortunately, in order to create the necessary information, we use templates. And those templates require the type for which we create the QMetaType to be complete (and if the type is T& or T*, T must be complete). While this mostly works for properties (as those often are backed by a member), for methods those types are often only forward declared. Getting qtbase to work with this was possible, but required larger changes (https://codereview.qt-project.org/c/qt/qtbase/+/297108, in addition to the fixes already in the initial patch). In many cases, that meant using Q_MOC_INCLUDE to tell the moc to include the necessary header.[2] More annoyingly, if a type is forward declared in a header and only implemented in a cpp file, the only way to get this to work is to include the moc file in the same cpp file. While doing this inside of Qt is possible, this is not something we can subject our users to. The proposed solution: In order to not break all the existing code, I would propose the following: We generate the QMetaTypes at compile time if possible. If the type is however incomplete, we store QMetaType::Unknown, and, at runtime, fall back to the slower string check to get the actual metatype. This is implemented in https://codereview.qt-project.org/c/qt/qtbase/+/298231. For classes exported to QML, we would then either generate a warning or an error if they lack complete types. We might also want a build system option to enforce having complete types. I would appreciate any suggestions, questions or complaints about the proposed plan. [1] Strictly speaking, the QMetaTypeInterface, which QMetaType then wraps. [2] Using a regular include works too, most of the time. It can however negatively affect compile times and breaks completely in the case of circular dependencies. -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
