[Development] Qt 5.12 beta1 released
Hi! We have released Qt 5.12 beta1 today, see http://blog.qt.io/blog/2018/10/05/qt-5-12-lts-beta-released/ You can find Qt 5.12 beta1 under 'Preview' node from Online installer. Please take a tour & start testing Qt 5.12 now. As earlier we will release new beta releases regularly until we are ready for final Qt 5.12 release. It is really important to recognize all blockers for the final release now so please make sure all release blockers can be found from RC blocker list (https://bugreports.qt.io/issues/?filter=19961). br Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Dropping remaining support of qtquick1
Hi, Can we drop the last remaining traces of qtquick1 from qtbase? Remember that qtquick1 is not part of Qt anymore since Qt 5.6. Anyhow, some people might still compiled it compiled with later versions on their own ... Right now it doesn't compile for me with 5.12, but I haven't investigated why. The last remaining support for Qt Quick 1 are in the build system (qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake ($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of QAbstractDeclarativeData::destroyed_qml1). We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd prefer 5.12 if nobody objects 😊 Regards Kai -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] unified data model API in QtCore => thin wrapper proposal
On Sunday, 9 September 2018 04:16:24 PDT Tor Arne Vestbø wrote:
>> This is exactly the kind of stuff I brought up at the contributors
>> summit. We should strive to at least be on par with QJson, but I’m
>> hoping we can also have a nice API for writing (something QJson
>> doesn’t easily facilitate). Any chance the read-only stuff can be
>> added at least Thiago?
Thiago Macieira (9 September 2018 18:36) wrote:
> It can be, but we're already past feature freeze and I don't have time
> to do it right now. I'm completely swamped at work and I'm dedicating
> any free minutes I have for Qt to do code reviews for others.
>
> The issue with map["hello"] can be an API review issue, though.
For the sake of openness (we took most of this discussion off-line), the
end result of that was:
5.12:
QCbor{Map,Array}::operator[] grow over-loads for string literals and all
read-only variants return const QCborValue:
https://codereview.qt-project.org/240046
QCborArray::operator[] and insert() allow indices past the end of the
array, padding the array with invalid entries:
https://codereview.qt-project.org/240537
dev (5.13):
QCborValue{Ref,}::operator[] added where missing
https://codereview.qt-project.org/240042
The first's const-ing and the second's padding are needed in 5.12 to let
the last be backwards-compatible, when it lands. Once the first two land,
we can finally close the qtbase API review.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building Qt documentation with developer-build
Hi! Am 05.10.2018 um 05:46 hat Jaroslaw Kobus geschrieben: > You may also want to check the > https://bugreports.qt.io/browse/QTBUG-65762 - if you think the issue > is still not solved, you may reopen / report new bug report. After rebuilding Qt it works now. On macOS is is sufficient to install clang with brew. The qmake stuff looks at the brew default location with 5.12 so setting LLVM_INSTALL_DIR is not necessary. Thanks for your help! However building the documentation with "make docs" in one of the submodules is rather slow. Pretty annoying when you only want to check whether your changes look ok when compiled to HTML. Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building Qt documentation with developer-build
> -Original Message- > From: Nils Jeisecke > Sent: Friday, 5 October 2018 2:17 PM > To: Jaroslaw Kobus > Cc: Mitch Curtis ; development@qt-project.org > Subject: Re: [Development] Building Qt documentation with developer-build > > Hi! > > Am 05.10.2018 um 05:46 hat Jaroslaw Kobus geschrieben: > > You may also want to check the > > https://bugreports.qt.io/browse/QTBUG-65762 - if you think the issue > > is still not solved, you may reopen / report new bug report. > > After rebuilding Qt it works now. On macOS is is sufficient to install clang > with > brew. The qmake stuff looks at the brew default location with > 5.12 so setting LLVM_INSTALL_DIR is not necessary. > > Thanks for your help! > > However building the documentation with "make docs" in one of the > submodules is rather slow. Pretty annoying when you only want to check > whether your changes look ok when compiled to HTML. Yeah, it is. One kinda small speed-up can be made by only running make html_docs in a specific folder, such as src/qml if you're editing QML docs, rather than doing it in the top level qtdeclarative directory and building both QML and Qt Quick docs. > Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping remaining support of qtquick1
On Friday, 5 October 2018 02:24:39 PDT Kai Koehne wrote: > The last remaining support for Qt Quick 1 are in the build system > (qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake > ($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of > QAbstractDeclarativeData::destroyed_qml1). > > We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd prefer > 5.12 if nobody objects I don't think we should. qtquick1 may not be as dead as we'd like it to be. I'd rather keep the QtCore API just in case someone is keeping the old module working for their applications (or Linux distribution, though I can't find any). They may also be (ab)using QLibraryInfo::ImportsPath for some other purpose. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] unified data model API in QtCore => thin wrapper proposal
On Friday, 5 October 2018 04:25:05 PDT Edward Welbourne wrote:
> dev (5.13):
> QCborValue{Ref,}::operator[] added where missing
> https://codereview.qt-project.org/240042
>
> The first's const-ing and the second's padding are needed in 5.12 to let
> the last be backwards-compatible, when it lands. Once the first two land,
> we can finally close the qtbase API review.
May as well bring this question to the list as a whole now:
QCborValue, Array and Map have methods like:
const QCborValue operator[](qint64 index) const;
We're trying to figure out if the returned type should be const.
Pros:
1) once QCborValue can be modified by the APi above, you can't accidentally
use it in a const object
2) you can't write
array[n] = newValue;
Cons:
Suppresses move construction as in
QCborValue v = array[n];
this still compiles, but passes through the copy constructor, not the move
one. We cana add an extra move constructor for const QCborValue && if
necessary.
Eddy: what happens in the new API if you write:
const QCborArray array = { QCborArray{ 1 } };
QCborValue v = array[0];
v[0] = 2;
Does that modify array?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] unified data model API in QtCore => thin wrapper proposal
Thiago Macieira (5 October 2018 17:35) asked me:
> Eddy: what happens in the new API if you write:
> const QCborArray array = { QCborArray{ 1 } };
> QCborValue v = array[0];
> v[0] = 2;
>
> Does that modify array?
No. It should only modify what v[0] reports, or a v.toArray()[0]
reports, after the assignment. My addition to the end of
tst_QCborValue::arrayDefaultInitialization() verifies exactly this with
the QVERIFY(a2.isEmpty()); that it adds, after such an assignment.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping remaining support of qtquick1
I would like to remind people that there has already been a deprecation thread "[Development] Deprecation of Qt Quick Controls 1" byFrederik Gladhorn this Februrary. A couple issues were raised there that were rather relevant and I would like to know if they were ever addressed. On Fri, Oct 5, 2018 at 6:29 PM Thiago Macieira wrote: > On Friday, 5 October 2018 02:24:39 PDT Kai Koehne wrote: > > The last remaining support for Qt Quick 1 are in the build system > > (qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake > > ($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of > > QAbstractDeclarativeData::destroyed_qml1). > > > > We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd > prefer > > 5.12 if nobody objects > > I don't think we should. qtquick1 may not be as dead as we'd like it to > be. > I'd rather keep the QtCore API just in case someone is keeping the old > module > working for their applications (or Linux distribution, though I can't find > any). They may also be (ab)using QLibraryInfo::ImportsPath for some other > purpose. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping remaining support of qtquick1
NIkolai Marchenko (5 October 2018 18:30) wrote: > I would like to remind people that there has already been a deprecation > thread " > [Development] Deprecation of Qt Quick Controls 1" by > Frederik Gladhorn this Februrary. > A couple issues were raised there that were rather relevant and I would like > to know if they were ever addressed. To save others the finding of it, that starts here: https://lists.qt-project.org/pipermail/development/2018-February/032073.html Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] unified data model API in QtCore => thin wrapper proposal
On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote: > Cons: > Suppresses move construction as in > QCborValue v = array[n]; > this still compiles, but passes through the copy constructor, not the move > one. We cana add an extra move constructor for const QCborValue && if > necessary. Never mind, you can't move from the const rvalue reference. It needs to be modifiable. So, again: should we have the const in the return types at the expense of losing the move semantic? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
