Re: [Development] ChangeLog script will need adaptation to cherry-pick model
> -Original Message- > From: Development On Behalf Of > Thiago Macieira > Sent: maanantai 10. elokuuta 2020 20.33 > To: development@qt-project.org > Subject: [Development] ChangeLog script will need adaptation to cherry-pick > model > > I've just noticed this and it'll be relevant for the 6.0 release: the > ChangeLog > script currently excludes the previous releases' commits simply because they > aren't produced in the git log / rev-list output. Because we switched to > cherry-pick model, the commits are now different and will not be excluded > by Git itself. This is something what I have been wondering a while: what is correct set of changes to be listed in changes file? Is it all changes from previous release in that same series (e.g all changes from 5.15.0 -> 5.15.1 ) or changes from previous release (with Qt 5.15.1 this would be then all changes from 5.15.0 -> 5.15.1 excluding ones in Qt 5.12.9). In my opinion it is first option; users should get info about all new changes in the release compared to same series; it doesn't matter if same changes are listed in other changes file in different series (those changes are relevant for users using that release) and user shouldn't need to browse several changes files to see what really is in the release. And if the correct behavior is the first one then the script doesn't need any change? br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qmake: qmltest missing in Qt6
On 10.08.20 11:29, Alexandru Croitor wrote: On 9. Aug 2020, at 19:57, Arno Rehn wrote: I'm trying to port over qtwebchannel from qmake to CMake, so we can hopefully include it in Qt 6.1 again. The problem is that I can't get the unit tests going with the old qmake system against current qt6 dev. I'd like to have something working which I can then port. The error message from qmake is just: Project ERROR: Unknown module(s) in QT: qmltest It seems to have its root in cause in mkspecs/features/qmltestcase.prf, where it reads mkspecs/features/qmltestcase.prf:QT += qml qmltest In this scenario, are you building Qt 6 with qmake or CMake? Running qmake tests with a CMake-built Qt is not officially supported at the moment. I suggest trying to build both Qt and the tests with qmake for now (in case you aren't doing that). If you are, I can't really say why qmltest doesn't work for you. Thanks a lot, that did it! :-) Regards, Arno -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.r...@menlosystems.com www.menlosystems.com Menlo Systems GmbH Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB 138145 Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. DE217772017, St.-Nr. 14316170324 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] ChangeLog script will need adaptation to cherry-pick model
I've just noticed this and it'll be relevant for the 6.0 release: the ChangeLog script currently excludes the previous releases' commits simply because they aren't produced in the git log / rev-list output. Because we switched to cherry-pick model, the commits are now different and will not be excluded by Git itself. Someone has to adapt this script to go over the list of commits in the previous releases and see if the same commit message or same Change-Id is present. Instead of a DAG operation in the commit history, this is a text search. If I were to implement this, I'd create a QSet-equivalent of all Change-Ids that apply to the previous branch series that were cherry-picked since the branch point. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and when evaluation occurs
I'm still trying to wrap my head around this proposal and I'm skeptical that it can be done at all. I think there are two occasions where evaluation must be instant. The first is if your write property handler has any emits in it, and the second is if there are any other properties that depend on the changed value of your property. The first case is a little bit more difficult because if you have a guard around a signal emission Qt will always have to evaluate the property to determine whether or not the signal emission occurs. It would be good to structure things in a way beforehand that we can defer the invocation totally. And there is a third case in which the handler will modify class members that aren't properties. All in all I don't think this lazy evaluation could be done safely in a way that won't break existing code. We should rely on the developer to understand how properties work and structure their code around it, otherwise if we risk creating additional rules that will cause confusion and frustration to developers. We already have established rules on how the system works and you're going to add a whole another layer of magic in. I'd rather stick with the existing simple set of rolls and allow the developers to wield that rather than have us come up with logic that doesn't work 100% better. I think any guarded signal emission breaks the case for this magic binding evaluation. You're still going to have to call the handler every time in those cases, and any other deferred handlers will make it inconsistent. I think the logic being done here should be done by the developer and not Qt itself because Qt cannot account for everything that developer could potentially want and we would be restricting them unnecessarily. > Sent: Friday, July 24, 2020 at 1:45 PM > From: "Stottlemyer, Brett (B.S.)" > To: "Volker Hilsheimer" > Cc: "development@qt-project.org" > Subject: Re: [Development] QProperty and when evaluation occurs > > Hi Volker, > > On 7/23/20, 3:13 PM, "Volker Hilsheimer" wrote: > > But why would we calculate the volume if nobody cares about the volume? :) > > Qt Remote Objects. I've got a headless service on one device, and a remote > UI for interacting with it. When signals are emitted (property change or > otherwise) by the service, the results are forwarded to the remote UI. > > Lazy evaluation probably works fine if the bindings are on the UI side, but > things break down if they are on the service side. That was why I was trying > to distinguish between derived properties _on a QObject_ vs bindings in a QML > UI. > >FWIW, pull-based systems are *much* more scalable than push-based systems, > because data is produced at the rate it can be consumed, not at the rate it > can be produced. That is unrelated to polling. > > That's only true if you know when you need to pull data. Otherwise it > _becomes_ polling. Also, I think you are assuming the pull is blocking, > which is not always valid. > > How will logging work? I often connect a lambda to a changed signal to > troubleshoot or log something. If such a routine were debug or > troubleshooting only, wouldn't that build behave fundamentally differently > (one doing immediate eval because of the signal connection, the other not)?. > > Thanks, > Brett > > ___ > 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] qmake: qmltest missing in Qt6
> -Original Message- > From: Development On Behalf Of > Arno Rehn > Sent: Sunday, 9 August 2020 7:58 PM > To: development@qt-project.org > Subject: [Development] qmake: qmltest missing in Qt6 > > Hey everybody, > > I'm trying to port over qtwebchannel from qmake to CMake, so we can > hopefully include it in Qt 6.1 again. The problem is that I can't get the unit > tests going with the old qmake system against current qt6 dev. > I'd like to have something working which I can then port. > > The error message from qmake is just: > > Project ERROR: Unknown module(s) in QT: qmltest > > It seems to have its root in cause in mkspecs/features/qmltestcase.prf, > where it reads > > mkspecs/features/qmltestcase.prf:QT += qml qmltest > > Is this a regression? I thought that qmake should still be supported with Qt6, > even though Qt itself has switched to CMake. > Any ideas? Do you have qtbase/lib/libQt6QuickTest.so.6.0.0? It could be that it failed to build for some reason, assuming you're using a self-built Qt. > Regards, > Arno > > -- > Arno Rehn > Tel +49 89 189 166 0 > Fax +49 89 189 166 111 > a.r...@menlosystems.com > www.menlosystems.com > > Menlo Systems GmbH > Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB > 138145 > Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. > DE217772017, St.-Nr. 14316170324 > ___ > 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] qmake: qmltest missing in Qt6
> On 9. Aug 2020, at 19:57, Arno Rehn wrote: > > Hey everybody, Hi, > > I'm trying to port over qtwebchannel from qmake to CMake, so we can > hopefully include it in Qt 6.1 again. The problem is that I can't get > the unit tests going with the old qmake system against current qt6 dev. I'd > like to have something working which I can then port. > > The error message from qmake is just: >> Project ERROR: Unknown module(s) in QT: qmltest > > It seems to have its root in cause in mkspecs/features/qmltestcase.prf, > where it reads >> mkspecs/features/qmltestcase.prf:QT += qml qmltest In this scenario, are you building Qt 6 with qmake or CMake? Running qmake tests with a CMake-built Qt is not officially supported at the moment. I suggest trying to build both Qt and the tests with qmake for now (in case you aren't doing that). If you are, I can't really say why qmltest doesn't work for you. > > Is this a regression? I thought that qmake should still be supported with > Qt6, even though Qt itself has switched to CMake. > Any ideas? qmake will be shipped with Qt 6 if Qt itself is built with CMake. But it will only support user projects that don't use private qmake API (think qt_module.prf, etc). I'm not sure yet where qmltest lies in that area. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
