From marc.mutz at kdab.com Sat Apr 1 01:19:07 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 01 Apr 2017 01:19:07 +0200 Subject: [Development] QList In-Reply-To: <20170331202746.GA3405@klara.mpi.htwm.de> References: <201703310943.12538.marc.mutz@kdab.com> <3776251490946198@web15m.yandex.ru> <201703311056.54007.marc.mutz@kdab.com> <20170331202746.GA3405@klara.mpi.htwm.de> Message-ID: <79b0cb00f8a92185f54e4813670245bf@kdab.com> On 2017-03-31 22:27, André Pönitz wrote: > On Fri, Mar 31, 2017 at 10:56:53AM +0200, Marc Mutz wrote: >> On Friday 31 March 2017 09:43:18 Konstantin Tokarev wrote: >> > 31.03.2017, 10:38, "Marc Mutz" : >> [...] >> > > [1] even better than Qt's, these days, since cppreference.com >> > > clearly shows what's available in which C++ version while Qt hides >> > > all but the latest documentation, which only describes the current >> > > state of affairs. >> > >> > Each Qt release is shipped with documentation. >> >> That doesn't help if you develop software that's supposed to be >> compatible with multiple Qt versions. Even if you install all Qt >> releases, the fact that you have separate documents per version makes >> finding past changes very hard. >> >> > Also, there is \since. >> >> But no \until. I try to put this in the docs, and sometimes I >> succeeded, but I've also been -1ed for trying already. > > Funnily enough I never caught you trying that. > > But sure, removing convenience from Qt by itself is -1-worthy, > as is trying to set up infrastructure to allow that. I - honestly - have not idea what you're talking about _now_. Mentioning that QSharedPointer::create() in the past took only one or even zero arguments when now it's taking by variadic template is "removing convenience from Qt"? Hu? What kind of twisted logic led you to write that remark? Thanks, Marc From Martin.Smith at qt.io Sat Apr 1 08:32:01 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 1 Apr 2017 06:32:01 +0000 Subject: [Development] QList In-Reply-To: <79b0cb00f8a92185f54e4813670245bf@kdab.com> References: <201703310943.12538.marc.mutz@kdab.com> <3776251490946198@web15m.yandex.ru> <201703311056.54007.marc.mutz@kdab.com> <20170331202746.GA3405@klara.mpi.htwm.de>, <79b0cb00f8a92185f54e4813670245bf@kdab.com> Message-ID: But about the indirectly proposed \until command. What is it supposed to do? Are we setting a policy of announcing the version when a class or function will be removed? ________________________________ From: Development on behalf of Marc Mutz Sent: Saturday, April 1, 2017 1:19:07 AM To: development at qt-project.org Subject: Re: [Development] QList On 2017-03-31 22:27, André Pönitz wrote: > On Fri, Mar 31, 2017 at 10:56:53AM +0200, Marc Mutz wrote: >> On Friday 31 March 2017 09:43:18 Konstantin Tokarev wrote: >> > 31.03.2017, 10:38, "Marc Mutz" : >> [...] >> > > [1] even better than Qt's, these days, since cppreference.com >> > > clearly shows what's available in which C++ version while Qt hides >> > > all but the latest documentation, which only describes the current >> > > state of affairs. >> > >> > Each Qt release is shipped with documentation. >> >> That doesn't help if you develop software that's supposed to be >> compatible with multiple Qt versions. Even if you install all Qt >> releases, the fact that you have separate documents per version makes >> finding past changes very hard. >> >> > Also, there is \since. >> >> But no \until. I try to put this in the docs, and sometimes I >> succeeded, but I've also been -1ed for trying already. > > Funnily enough I never caught you trying that. > > But sure, removing convenience from Qt by itself is -1-worthy, > as is trying to set up infrastructure to allow that. I - honestly - have not idea what you're talking about _now_. Mentioning that QSharedPointer::create() in the past took only one or even zero arguments when now it's taking by variadic template is "removing convenience from Qt"? Hu? What kind of twisted logic led you to write that remark? Thanks, Marc _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Sat Apr 1 17:58:06 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 01 Apr 2017 17:58:06 +0200 Subject: [Development] \until (was: Re: QList) In-Reply-To: References: " <201703310943.12538.marc.mutz@kdab.com>" <3776251490946198@web15m.yandex.ru> <201703311056.54007.marc.mutz@kdab.com> <20170331202746.GA3405@klara.mpi.htwm.de>, <79b0cb00f8a92185f54e4813670245bf@kdab.com> Message-ID: <59864d3b3abafcde4d56292c3a0c1ffa@kdab.com> On 2017-04-01 08:32, Martin Smith wrote: > But about the indirectly proposed until command. What is it supposed > to do? Are we setting a policy of announcing the version when a class > or function will be removed? Let's look at QSharedPointer::create(): It started out with no arguments, so you could only default-construct T. \fn QSharedPointer::create() \since 4.8 # I'm making these number up Then, we added one argument, but it was taken by const-&. That's an overload: \fn QSharedPointer::create() \since 4.8 \fn QSharedPointer::create(const Arg &arg) \overload \since 5.1 # made up (empty line separates apidox comment blocks). And finally, we went for variadic templates, replacing both overloads: \fn QSharedPointer::create(Args &&...args) \since 5.8 I now wrote in prose what the situation was in versions prior to 5.8. With \until, we'd keep the old docs: \fn QSharedPointer::create() \since 4.8 \until 5.7 \fn QSharedPointer::create(const Arg &arg) \overload \since 5.1 # made up \until 5.7 \fn QSharedPointer::create(Args &&...args) \overload \since 5.8 How we render that in the docs is another question. cppreference.com is one example. But probably not applicable to our layout, since they use one page per set of overloaded functions, not one for the whole class. One option would be to put these functions into a page like the obsolete members, say "historic members". Makes sense? Thanks, Marc From Martin.Smith at qt.io Sat Apr 1 18:26:34 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 1 Apr 2017 16:26:34 +0000 Subject: [Development] \until (was: Re: QList) In-Reply-To: <59864d3b3abafcde4d56292c3a0c1ffa@kdab.com> References: " <201703310943.12538.marc.mutz@kdab.com>" <3776251490946198@web15m.yandex.ru> <201703311056.54007.marc.mutz@kdab.com> <20170331202746.GA3405@klara.mpi.htwm.de>, <79b0cb00f8a92185f54e4813670245bf@kdab.com> , <59864d3b3abafcde4d56292c3a0c1ffa@kdab.com> Message-ID: >One option would be to put these functions into a page like the obsolete >members, say "historic members". I like this idea much better than trying to use combinations of \since and \until. In the function comment, after the current description, there can be multiple \history sections: \history myFunction(oldType *param) \since 4.8 description of myFunction() in Qt 4.8 \endhistory \history myFunction(oldType *param, anotherType anotherParam) \since 5.2 description of myFunction in Qt 5.2. \endhistory ________________________________ From: Development on behalf of Marc Mutz Sent: Saturday, April 1, 2017 5:58:06 PM To: development at qt-project.org Subject: [Development] \until (was: Re: QList) On 2017-04-01 08:32, Martin Smith wrote: > But about the indirectly proposed until command. What is it supposed > to do? Are we setting a policy of announcing the version when a class > or function will be removed? Let's look at QSharedPointer::create(): It started out with no arguments, so you could only default-construct T. \fn QSharedPointer::create() \since 4.8 # I'm making these number up Then, we added one argument, but it was taken by const-&. That's an overload: \fn QSharedPointer::create() \since 4.8 \fn QSharedPointer::create(const Arg &arg) \overload \since 5.1 # made up (empty line separates apidox comment blocks). And finally, we went for variadic templates, replacing both overloads: \fn QSharedPointer::create(Args &&...args) \since 5.8 I now wrote in prose what the situation was in versions prior to 5.8. With \until, we'd keep the old docs: \fn QSharedPointer::create() \since 4.8 \until 5.7 \fn QSharedPointer::create(const Arg &arg) \overload \since 5.1 # made up \until 5.7 \fn QSharedPointer::create(Args &&...args) \overload \since 5.8 How we render that in the docs is another question. cppreference.com is one example. But probably not applicable to our layout, since they use one page per set of overloaded functions, not one for the whole class. One option would be to put these functions into a page like the obsolete members, say "historic members". Makes sense? Thanks, Marc _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Sun Apr 2 21:03:26 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 2 Apr 2017 21:03:26 +0200 Subject: [Development] QList In-Reply-To: References: <201703241718.05520.marc.mutz@kdab.com> <82F4CE78-0C24-43F1-9318-35776C71601B@qt.io> <2867454.cgdXHHexsp@tjmaciei-mobl1> Message-ID: <6990001a-72bc-e87f-ddd3-2d5bad9266da@kdab.com> Il 27/03/2017 20:14, Giuseppe D'Angelo ha scritto: >> We can port away from QStringRef and into QStringView as we go by and where >> it's safe. But unless we're willing to refactor some code substantially. >> Unfortunately, it's very likely we can't begin this work now as it would break >> the QStringRef API and thus be BIC/SIC. > If we can't make it an alias, can we start adding extra functions for > the various QStringRef *ref() methods (in QXmlStreamReader, > QRegularExpressionMatch, probably elsewhere too), returning QStringView? QREM: https://codereview.qt-project.org/#/c/190365/ -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From giuseppe.dangelo at kdab.com Mon Apr 3 00:36:32 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 3 Apr 2017 00:36:32 +0200 Subject: [Development] QList In-Reply-To: <2867454.cgdXHHexsp@tjmaciei-mobl1> References: <201703241718.05520.marc.mutz@kdab.com> <82F4CE78-0C24-43F1-9318-35776C71601B@qt.io> <2867454.cgdXHHexsp@tjmaciei-mobl1> Message-ID: <76dde6d0-b8a7-d84b-50e2-c2972ed325e7@kdab.com> Il 27/03/2017 17:46, Thiago Macieira ha scritto: > >> Another point that hasn’t been discussed yet, is how to handle QStringRef. >> In my opinion, we should deprecate it, but it’s used quite a bit in some >> parts of our API (QXmlStreamReader comes to my mind). It would be good to >> also think about how to solve that case. QStringRef has a pointer to a >> QString, but does not increase the refcount of it. So it looks like we can >> simply make it an alias for QStringView. That would break the >> QStringRef::string() method (which we should probably deprecate in 5.10 to >> prepare for the change), but everything else should stay compatible. > We can't... I tried that a while ago and it broke QXmlStreamReader and other > places badly. The issue is that they expect QStringRef to continue to be valid > after mutating the QString it was bound to. That works because of the pointer > to the QString, as opposed to a pointer to the data. And that's just what I > found by after changing QStringRef a few years ago to be like QStringView > today and simply running Qt Creator. > > We can port away from QStringRef and into QStringView as we go by and where > it's safe. But unless we're willing to refactor some code substantially. > Unfortunately, it's very likely we can't begin this work now as it would break > the QStringRef API and thus be BIC/SIC. > > So, yes, deprecate, but we'll have to carry QStringRef for some time, like > QRegExp. QRegularExpressionMatch has a similar problem: it currently stores a copy of the subject string passed to QRegularExpression::match(QString/QStringRef). People are relying on this behaviour, including its own autotests; for instance, this works: > QRegularExpression re("\\d+"); > auto m = re.match("foo123bar"); // stores a copy > assert(m.captured(0) == "123"); // safe -- extracts substring from internal copy Questions: 1) Should this behaviour be deprecated and eventually changed? How to make users aware of this behaviour change? 2) Suppose we add right now a match(QStringView) overload, should it still return a QRegularExpressionMatch or a new class with similar API? If it still returns a QREM, what would QREM::capturedRef(N) then return for a match over a string view? (Trying to find the path of least breakage) Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Mon Apr 3 04:59:27 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 02 Apr 2017 19:59:27 -0700 Subject: [Development] QList In-Reply-To: <76dde6d0-b8a7-d84b-50e2-c2972ed325e7@kdab.com> References: <2867454.cgdXHHexsp@tjmaciei-mobl1> <76dde6d0-b8a7-d84b-50e2-c2972ed325e7@kdab.com> Message-ID: <5537194.QK03QBU8JZ@tjmaciei-mobl1> On domingo, 2 de abril de 2017 15:36:32 PDT Giuseppe D'Angelo wrote: > > QRegularExpression re("\\d+"); > > auto m = re.match("foo123bar"); // stores a copy > > assert(m.captured(0) == "123"); // safe -- extracts substring from > > internal copy > Questions: > > 1) Should this behaviour be deprecated and eventually changed? How to > make users aware of this behaviour change? Change what? The ability to run the code above? No. Whatever we do, we shouldn't break the code above. > 2) Suppose we add right now a match(QStringView) overload, should it > still return a QRegularExpressionMatch or a new class with similar API? > If it still returns a QREM, what would QREM::capturedRef(N) then return > for a match over a string view? Anything that takes a QStringView and needs to store should store a QString, not a QStringView. So if it needs to make a copy, so be it. That's why I was proposing for QStringView to carry QString's d pointer if it knows it, so the refcounting can resume. Marc doesn't want that. So we need to have a QString overload for match(), if necessary. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Apr 3 09:33:35 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 3 Apr 2017 09:33:35 +0200 Subject: [Development] \until (was: Re: QList) In-Reply-To: References: <59864d3b3abafcde4d56292c3a0c1ffa@kdab.com> Message-ID: <201704030933.35464.marc.mutz@kdab.com> On Saturday 01 April 2017 18:26:34 Martin Smith wrote: > >One option would be to put these functions into a page like the obsolete > > > >members, say "historic members". > > I like this idea much better than trying to use combinations of \since and > \until. The rendering of the information is completely independent of the markup. So you can have that historic members page with any form of markup. The markup you propose below is going to cause a lot of code churn, I think. With \until, you just add a line to an existing apidox block. I also don't see how you would represent the replacement of two (or more) overloads with a single function, unless you also propose the (welcome) option to document all overloads of a function in a single apidox block. Thanks, Marc > > In the function comment, after the current description, there can be > multiple \history sections: > > > \history myFunction(oldType *param) > > \since 4.8 > > > description of myFunction() in Qt 4.8 > > \endhistory > > > \history myFunction(oldType *param, anotherType anotherParam) > > \since 5.2 > > > description of myFunction in Qt 5.2. > > \endhistory > > ________________________________ > From: Development > on behalf of Marc Mutz Sent: Saturday, April 1, 2017 > 5:58:06 PM > To: development at qt-project.org > Subject: [Development] \until (was: Re: QList) > > On 2017-04-01 08:32, Martin Smith wrote: > > But about the indirectly proposed until command. What is it supposed > > to do? Are we setting a policy of announcing the version when a class > > or function will be removed? > > Let's look at QSharedPointer::create(): > > It started out with no arguments, so you could only default-construct T. > > \fn QSharedPointer::create() > \since 4.8 # I'm making these number up > > Then, we added one argument, but it was taken by const-&. That's an > overload: > > \fn QSharedPointer::create() > \since 4.8 > > \fn QSharedPointer::create(const Arg &arg) > \overload > \since 5.1 # made up > > (empty line separates apidox comment blocks). > > And finally, we went for variadic templates, replacing both overloads: > > \fn QSharedPointer::create(Args &&...args) > \since 5.8 > > I now wrote in prose what the situation was in versions prior to 5.8. > With \until, we'd keep the old docs: > > \fn QSharedPointer::create() > \since 4.8 > \until 5.7 > > \fn QSharedPointer::create(const Arg &arg) > \overload > \since 5.1 # made up > \until 5.7 > > \fn QSharedPointer::create(Args &&...args) > \overload > \since 5.8 > > How we render that in the docs is another question. cppreference.com is > one example. But probably not applicable to our layout, since they use > one page per set of overloaded functions, not one for the whole class. > > One option would be to put these functions into a page like the obsolete > members, say "historic members". > > Makes sense? > > Thanks, > Marc > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Mon Apr 3 09:45:49 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 3 Apr 2017 09:45:49 +0200 Subject: [Development] QRegularExpressionMatch (was: Re: QList) In-Reply-To: <5537194.QK03QBU8JZ@tjmaciei-mobl1> References: <76dde6d0-b8a7-d84b-50e2-c2972ed325e7@kdab.com> <5537194.QK03QBU8JZ@tjmaciei-mobl1> Message-ID: <201704030945.49561.marc.mutz@kdab.com> On Monday 03 April 2017 04:59:27 Thiago Macieira wrote: > On domingo, 2 de abril de 2017 15:36:32 PDT Giuseppe D'Angelo wrote: > > > QRegularExpression re("\\d+"); > > > auto m = re.match("foo123bar"); // stores a copy > > > assert(m.captured(0) == "123"); // safe -- extracts substring from > > > internal copy > > > > Questions: > > > > 1) Should this behaviour be deprecated and eventually changed? How to > > make users aware of this behaviour change? > > Change what? The ability to run the code above? No. > > Whatever we do, we shouldn't break the code above. > > > 2) Suppose we add right now a match(QStringView) overload, should it > > still return a QRegularExpressionMatch or a new class with similar API? > > If it still returns a QREM, what would QREM::capturedRef(N) then return > > for a match over a string view? > > Anything that takes a QStringView and needs to store should store a > QString, not a QStringView. So if it needs to make a copy, so be it. This is an open question, one what the QT_STRINGVIEW_LEVELs are supposed to help decide, so I strongly object to any blanket statement, in either direction, from anyone, at this point. > That's why I was proposing for QStringView to carry QString's d pointer if > it knows it, so the refcounting can resume. Marc doesn't want that. So we > need to have a QString overload for match(), if necessary. The long-term goal here should be to not store a strong reference on matching. How to get there is an open, and controversial, question. I'd make the QStringView overload return a new class that does not store a strong reference. But then the QString overload can't just go away with QT_STRINGVIEW_LEVEL < 2, as usual (code comment necessary). My original idea was to overload QStringView with QString&&. Whether that works out in practice remains to be seen. It's becoming clearer and clearer that just replacing QString/QStringRef overloads with a QStringView one won't cut it. But when it doesn't, it points to interesting optimisation oppporunities, like a missing QLatin1String or QStringBuilder overload. How does the existing match(QStringRef) overload handle lifetime? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Mon Apr 3 10:40:38 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 3 Apr 2017 10:40:38 +0200 Subject: [Development] QList In-Reply-To: <5537194.QK03QBU8JZ@tjmaciei-mobl1> References: <2867454.cgdXHHexsp@tjmaciei-mobl1> <76dde6d0-b8a7-d84b-50e2-c2972ed325e7@kdab.com> <5537194.QK03QBU8JZ@tjmaciei-mobl1> Message-ID: <217a9363-d293-fab1-cd04-7bf90d5bd395@kdab.com> Il 03/04/2017 04:59, Thiago Macieira ha scritto: >> 2) Suppose we add right now a match(QStringView) overload, should it >> still return a QRegularExpressionMatch or a new class with similar API? >> If it still returns a QREM, what would QREM::capturedRef(N) then return >> for a match over a string view? > Anything that takes a QStringView and needs to store should store a QString, > not a QStringView. So if it needs to make a copy, so be it. If that's the intention, I'd rather not add a match(QStringView) overload at all and move the burden of taking a copy to the user, so at least it's evident that there's a deep copy happening there. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From giuseppe.dangelo at kdab.com Mon Apr 3 11:07:26 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 3 Apr 2017 11:07:26 +0200 Subject: [Development] QRegularExpressionMatch In-Reply-To: <201704030945.49561.marc.mutz@kdab.com> References: <76dde6d0-b8a7-d84b-50e2-c2972ed325e7@kdab.com> <5537194.QK03QBU8JZ@tjmaciei-mobl1> <201704030945.49561.marc.mutz@kdab.com> Message-ID: Il 03/04/2017 09:45, Marc Mutz ha scritto: > How does the existing match(QStringRef) overload handle lifetime? By getting the internal QString and storing a copy of it (alongside with the offset/length carried by the QStringRef): > https://code.woboq.org/qt5/qtbase/src/corelib/tools/qregularexpression.cpp.html#_ZNK18QRegularExpression5matchERK10QStringRefiNS_9MatchTypeE6QFlagsINS_11MatchOptionEE Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Martin.Smith at qt.io Mon Apr 3 11:23:23 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 3 Apr 2017 09:23:23 +0000 Subject: [Development] \until (was: Re: QList) In-Reply-To: <201704030933.35464.marc.mutz@kdab.com> References: <59864d3b3abafcde4d56292c3a0c1ffa@kdab.com> , <201704030933.35464.marc.mutz@kdab.com> Message-ID: >I also don't see how you would represent the replacement of two (or more) >overloads with a single function, unless you also propose the (welcome) option >to document all overloads of a function in a single apidox block. You can already do that. For example, I'm about to commit this in qimage.cpp: /*! \fn QImage QImage::rgbSwapped() const & \fn QImage QImage::rgbSwapped() && Returns a QImage in which the values of the red and blue components of all pixels have been swapped, effectively converting an RGB image to an BGR image. The original QImage is not changed. \sa {QImage#Image Transformations}{Image Transformations} */ >The markup you propose below is going to cause a lot of code churn, I think. >With \until, you just add a line to an existing apidox block. There would be a lot of code churn, but I think it would almost all be automatically generated. I'm proposing to add an output generator to qdoc that generates history files automatically. For class QWidget, there exists qwidget.h and qwidget.cpp. I'm proposing to add the possibility of there being a qwidget.hist, which would actually be a .qdoc file, i.e. it only contains qdoc comments. qwidget.hist would be created this way: First, run qdoc -history, which tells qdoc to just compare two versions of each class in Qt, and if a class has history (because the qdoc comment for a particular function is not the same in both versions), then either create the history file for the class if it doesn't exist (because the class has no history yet) or update the history file, if it does exist, with the new history. So when we release Qt 5.9, we want to create or update the history files for 5.9 by running qdoc -history in Qt-5.9 and comparing the documentation for each class in 5.9 to to the same documentation in 5.8. So we also have to pass the path to the 5.8 tree: qdoc -history ~/depot/qt-5.8 qdoc then runs as usual for each module in Qt-5.9 to build its documentation tree for the entire module. But it doesn't generate the html files for the module. Instead, it builds a second documentation tree for the module for Qt-5.8 Now qdoc has two documentation trees for QtCore, say, one for 5.9 and one for 5.8. Next, qdoc traverses the tree for 5.9. For each member function of each class, it finds the same function in the tree for 5.8. It compares the two qdoc comments to see if the documentation has changed. If the documentation for a member function of QWidget has changed, then it looks for qwidget.hist for Qt-5.9. If that file does not exist, qdoc creates it and adds a \history block to it containing the qdoc comment from the Qt-5.8 tree. It would add a \fn command to this comment if it wasn't already there. If qwidget.hist already exists, qdoc just adds the new history comment to the file. Each history comment would be marked with the Qt version it came from. Once qwidget.hist exists, it becomes a permanent part of the documentation, so after qdoc -history runs, I have to use git to add and commit the new .hist files, but qdoc can give me a list of those. From then on, qwidget.hist can be updated both manually and automatically with qdoc -hist. And we could repeatedly run qdoc -history over successive versions of Qt 5 to generate each function's complete history in Qt 5. But it wouldn't work for Qt 4 because of modularization. When qdoc later generates the html files for 5.9, it generates qwidget-history.html, which would render the complete history of each member function of QWidget. On the class reference html page for QWidget, the documentation for each member function would show a link to the functions history, if it exists. Maybe this is overkill? What do we want to achieve with the concept of a functions "history" ? martin ________________________________________ From: Development on behalf of Marc Mutz Sent: Monday, April 3, 2017 9:33:35 AM To: development at qt-project.org Subject: Re: [Development] \until (was: Re: QList) On Saturday 01 April 2017 18:26:34 Martin Smith wrote: > >One option would be to put these functions into a page like the obsolete > > > >members, say "historic members". > > I like this idea much better than trying to use combinations of \since and > \until. The rendering of the information is completely independent of the markup. So you can have that historic members page with any form of markup. The markup you propose below is going to cause a lot of code churn, I think. With \until, you just add a line to an existing apidox block. I also don't see how you would represent the replacement of two (or more) overloads with a single function, unless you also propose the (welcome) option to document all overloads of a function in a single apidox block. Thanks, Marc > > In the function comment, after the current description, there can be > multiple \history sections: > > > \history myFunction(oldType *param) > > \since 4.8 > > > description of myFunction() in Qt 4.8 > > \endhistory > > > \history myFunction(oldType *param, anotherType anotherParam) > > \since 5.2 > > > description of myFunction in Qt 5.2. > > \endhistory > > ________________________________ > From: Development > on behalf of Marc Mutz Sent: Saturday, April 1, 2017 > 5:58:06 PM > To: development at qt-project.org > Subject: [Development] \until (was: Re: QList) > > On 2017-04-01 08:32, Martin Smith wrote: > > But about the indirectly proposed until command. What is it supposed > > to do? Are we setting a policy of announcing the version when a class > > or function will be removed? > > Let's look at QSharedPointer::create(): > > It started out with no arguments, so you could only default-construct T. > > \fn QSharedPointer::create() > \since 4.8 # I'm making these number up > > Then, we added one argument, but it was taken by const-&. That's an > overload: > > \fn QSharedPointer::create() > \since 4.8 > > \fn QSharedPointer::create(const Arg &arg) > \overload > \since 5.1 # made up > > (empty line separates apidox comment blocks). > > And finally, we went for variadic templates, replacing both overloads: > > \fn QSharedPointer::create(Args &&...args) > \since 5.8 > > I now wrote in prose what the situation was in versions prior to 5.8. > With \until, we'd keep the old docs: > > \fn QSharedPointer::create() > \since 4.8 > \until 5.7 > > \fn QSharedPointer::create(const Arg &arg) > \overload > \since 5.1 # made up > \until 5.7 > > \fn QSharedPointer::create(Args &&...args) > \overload > \since 5.8 > > How we render that in the docs is another question. cppreference.com is > one example. But probably not applicable to our layout, since they use > one page per set of overloaded functions, not one for the whole class. > > One option would be to put these functions into a page like the obsolete > members, say "historic members". > > Makes sense? > > Thanks, > Marc > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From ulf.hermann at qt.io Mon Apr 3 11:33:50 2017 From: ulf.hermann at qt.io (Ulf Hermann) Date: Mon, 3 Apr 2017 11:33:50 +0200 Subject: [Development] \until In-Reply-To: References: <59864d3b3abafcde4d56292c3a0c1ffa@kdab.com> <201704030933.35464.marc.mutz@kdab.com> Message-ID: <1a2fc818-834f-2733-636c-48f8c232945f@qt.io> The idea is great. But ... The changes from Qt4 to Qt5 are actually among the most interesting ones. So, rather than comparing on a file-by-file base, wouldn't it be better to first index the documentation by function signatures and then compare on a function-by-function base? That would also handle cases of functions getting moved to a different file in between Qt5 releases. Ulf From rjvbertin at gmail.com Mon Apr 3 12:09:16 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 03 Apr 2017 12:09:16 +0200 Subject: [Development] redistributing QPA and platform style plugins Message-ID: <1876998.PGiPlZ3921@bola> Hi, As you know I've been tinkering with the Cocoa QPA plugin and the Macintosh style. Are there legal restrictions to making my modified versions available (say on github) other than maintaining the license headers and any licensing files? How feasible is to extract these components and make it possible to build them standalone (preferably using CMake)? A cursory look suggests that the Cocoa platform plugin might be easier isolate than the built-in Macintosh style, correct? And last but not least, does doing this have any incidence on "upstreaming", should I ever decide to submit some of those modifications? Thanks, René From Martin.Smith at qt.io Mon Apr 3 12:43:38 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 3 Apr 2017 10:43:38 +0000 Subject: [Development] \until In-Reply-To: <1a2fc818-834f-2733-636c-48f8c232945f@qt.io> References: <59864d3b3abafcde4d56292c3a0c1ffa@kdab.com> <201704030933.35464.marc.mutz@kdab.com> , <1a2fc818-834f-2733-636c-48f8c232945f@qt.io> Message-ID: >The changes from Qt4 to Qt5 are actually among the most interesting >ones. So, rather than comparing on a file-by-file base, wouldn't it be >better to first index the documentation by function signatures and then >compare on a function-by-function base? That would also handle cases of >functions getting moved to a different file in between Qt5 releases. Good point, and anyway, the comparison would be done by traversing the tree of the later version and for each function node found, search the tree of the earlier version to find the corresponding function. The search is done by looking for the QWidget class node and then searching the children of that node for the function. So the structure of the tree of the earlier version doesn't matter. martin From Jake.Petroules at qt.io Mon Apr 3 17:33:34 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 3 Apr 2017 15:33:34 +0000 Subject: [Development] redistributing QPA and platform style plugins In-Reply-To: <1876998.PGiPlZ3921@bola> References: <1876998.PGiPlZ3921@bola> Message-ID: > On Apr 3, 2017, at 3:09 AM, René J.V. Bertin wrote: > > Hi, > > As you know I've been tinkering with the Cocoa QPA plugin and the Macintosh style. > > Are there legal restrictions to making my modified versions available (say on github) other than maintaining the license headers and any licensing files? In short, no. You know Qt is licensed under GPL & LGPL, right? > How feasible is to extract these components and make it possible to build them standalone (preferably using CMake)? A cursory look suggests that the Cocoa platform plugin might be easier isolate than the built-in Macintosh style, correct? Actually, I'm working on making the platform styles into plugins right now, so it'll be very easy to build QMacStyle standalone once https://codereview.qt-project.org/#/c/186909/ is merged. Keep in mind it'll still require a number of private headers, though. > And last but not least, does doing this have any incidence on "upstreaming", should I ever decide to submit some of those modifications? Possibly, if others contribute to your modifications, they'll also need to sign the CLA and somehow "co-submit" the changes to the Qt Project alongside you. On that note, why not upstream the changes immediately and make things better for everyone? > Thanks, > René > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Mon Apr 3 17:35:32 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 03 Apr 2017 08:35:32 -0700 Subject: [Development] redistributing QPA and platform style plugins In-Reply-To: <1876998.PGiPlZ3921@bola> References: <1876998.PGiPlZ3921@bola> Message-ID: <1994665.nAVHDliflC@tjmaciei-mobl1> On segunda-feira, 3 de abril de 2017 03:09:16 PDT René J.V. Bertin wrote: > Hi, > > As you know I've been tinkering with the Cocoa QPA plugin and the Macintosh > style. > > Are there legal restrictions to making my modified versions available (say > on github) other than maintaining the license headers and any licensing > files? It's open-source. You're encouraged to make your changes available to others. You're also encouraged to contribute the important changes back to Qt. > How feasible is to extract these components and make it possible to build > them standalone (preferably using CMake)? A cursory look suggests that the > Cocoa platform plugin might be easier isolate than the built-in Macintosh > style, correct? That's your problem. We don't have to make it easy for you to fork Qt code. Specifically, there's no binary compatibility guarantee between the QPA plugin and QtGui. Keeping a fork of a QPA plugin is not recommended. Now, if you want to make a better style than what Qt provides, just look at how Breeze does it in KDE. > And last but not least, does doing this have any incidence on "upstreaming", > should I ever decide to submit some of those modifications? The recommendation is that you think of upstreaming early. The longer it takes you to upstream, the more stale your changes may be and the more difficult it may become to merge them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tor.arne.vestbo at qt.io Mon Apr 3 17:40:42 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Mon, 3 Apr 2017 17:40:42 +0200 Subject: [Development] redistributing QPA and platform style plugins In-Reply-To: <1994665.nAVHDliflC@tjmaciei-mobl1> References: <1876998.PGiPlZ3921@bola> <1994665.nAVHDliflC@tjmaciei-mobl1> Message-ID: <3e604116-d2b2-e57f-1553-2c058fcfdcb3@qt.io> On 03/04/2017 17:35, Thiago Macieira wrote: >> And last but not least, does doing this have any incidence on "upstreaming", >> should I ever decide to submit some of those modifications? > > The recommendation is that you think of upstreaming early. The longer it takes > you to upstream, the more stale your changes may be and the more difficult it > may become to merge them. Related to this, making sure your changes align with the project goals and platform direction, and getting buy-in for your changes, increases the chance that upstreaming will be a smooth process. tor arne From thiago.macieira at intel.com Mon Apr 3 18:01:24 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 03 Apr 2017 09:01:24 -0700 Subject: [Development] redistributing QPA and platform style plugins In-Reply-To: <3e604116-d2b2-e57f-1553-2c058fcfdcb3@qt.io> References: <1876998.PGiPlZ3921@bola> <1994665.nAVHDliflC@tjmaciei-mobl1> <3e604116-d2b2-e57f-1553-2c058fcfdcb3@qt.io> Message-ID: <9825033.am5jB42TP5@tjmaciei-mobl1> On segunda-feira, 3 de abril de 2017 08:40:42 PDT Tor Arne Vestbø wrote: > On 03/04/2017 17:35, Thiago Macieira wrote: > >> And last but not least, does doing this have any incidence on > >> "upstreaming", should I ever decide to submit some of those > >> modifications? > > > > The recommendation is that you think of upstreaming early. The longer it > > takes you to upstream, the more stale your changes may be and the more > > difficult it may become to merge them. > > Related to this, making sure your changes align with the project goals > and platform direction, and getting buy-in for your changes, increases > the chance that upstreaming will be a smooth process. And the best way to achieve those requirements is to not fork. Just work with the Qt Project. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Apr 4 10:33:13 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 04 Apr 2017 10:33:13 +0200 Subject: [Development] redistributing QPA and platform style plugins In-Reply-To: References: <1876998.PGiPlZ3921@bola> Message-ID: <3317288.RI0PtZnJfE@bola> On Monday April 03 2017 15:33:34 Jake Petroules wrote: Thanks for all your answers. >> Are there legal restrictions to making my modified versions available (say on github) other than maintaining the license headers and any licensing files? > >In short, no. You know Qt is licensed under GPL & LGPL, right? Yep. I just wanted to be sure. >Actually, I'm working on making the platform styles into plugins right now, so it'll be very easy to build QMacStyle standalone once >https://codereview.qt-project.org/#/c/186909/ is merged. Keep in mind it'll still require a number of private headers, though. Good new, thanks! I haven't looked yet but with luc that'll make it easier also to isolate the current style sources too (5.8). For the private headers I was thinking I'd include any of those that aren't installed in a complete install. Using private headers is acceptable for low-level plugins like this; the Plasma integration platform theme plugin also does that (and so does my Mac fork of that plugin). >Possibly, if others contribute to your modifications, they'll also need to sign the CLA and somehow "co-submit" the changes to the Qt Project alongside you. The only contributions I'm daring to hope for are ideas and opinions ;) >On that note, why not upstream the changes immediately and make things better for everyone? Others made similar remarks, and normally I wouldn't disagree. In this case I'm not sure: - I've been getting a bit of an idea about what's upstreamable and my modifications might not be, or not in a form that I am happy with. In the latter case I'd still be wanting to make my own take available. FWIW, most of the modifications I make aim at improving what I call the "KDE experience" (where that cannot be done directly in KDE code). - Providing modified Qt behaviour through plugins rather than patches to apply to the Qt sources makes it easier for others to use them, which in turn should allow me to present a more mature and tested concept if and when I decide to go for upstreaming. In an ideal world and all that ;) - In addition, that modified behaviour becomes available *now*, and not in some more or less far-off future version. That also has a practical consideration for me personally: I don't have the resources to maintain a development Qt install with all dependents to test things properly. The cocoa QPA plugin isn't very big (QMacStyle certainly not) so keeping a fork in sync with upstream developments shouldn't be very hard even when done manually at intervals. With that it might be possible to build and use newer/development versions of those components with a Qt release version, no? R. From marc.mutz at kdab.com Tue Apr 4 21:33:40 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 04 Apr 2017 21:33:40 +0200 Subject: [Development] =?utf-8?b?bWlkKCksIGxlZnQoKSwgcmlnaHQoKSwgYW5kIC4u?= =?utf-8?b?LiA/?= Message-ID: <93d26bb4640fb6e48c20a1d8b95a40ad@kdab.com> Hi, We have two functions to get a substring without doing some calculations involving size(): - mid(p): mid(p, size() - p) - right(n) : mid(size() - n, n) (left does not involve size(), so isn't in that set). What is missing is a name for - f(n): mid(0, size() - n) As a mutator, it's called chop(n). So... chopped()? std::string_view has remove_suffix(n), btw. Thanks, Marc From apoenitz at t-online.de Tue Apr 4 20:56:34 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 4 Apr 2017 20:56:34 +0200 Subject: [Development] mid(), left(), right(), and ... ? In-Reply-To: <93d26bb4640fb6e48c20a1d8b95a40ad@kdab.com> References: <93d26bb4640fb6e48c20a1d8b95a40ad@kdab.com> Message-ID: <20170404185634.GA6684@klara.mpi.htwm.de> On Tue, Apr 04, 2017 at 09:33:40PM +0200, Marc Mutz wrote: > Hi, > > We have two functions to get a substring without doing some calculations > involving size(): > > - mid(p): mid(p, size() - p) > - right(n) : mid(size() - n, n) > > (left does not involve size(), so isn't in that set). What is missing is a > name for > > - f(n): mid(0, size() - n) > > As a mutator, it's called chop(n). So... chopped()? Sounds sensible. Andre' From thiago.macieira at intel.com Wed Apr 5 05:10:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 04 Apr 2017 20:10:40 -0700 Subject: [Development] mid(), left(), right(), and ... ? In-Reply-To: <93d26bb4640fb6e48c20a1d8b95a40ad@kdab.com> References: <93d26bb4640fb6e48c20a1d8b95a40ad@kdab.com> Message-ID: <1818689.5JEzZyfWyA@tjmaciei-mobl1> Em terça-feira, 4 de abril de 2017, às 12:33:40 PDT, Marc Mutz escreveu: > Hi, > > We have two functions to get a substring without doing some calculations > involving size(): > > - mid(p): mid(p, size() - p) > - right(n) : mid(size() - n, n) > > (left does not involve size(), so isn't in that set). What is missing is > a name for > > - f(n): mid(0, size() - n) > > As a mutator, it's called chop(n). So... chopped()? Yeah. or left(-n). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuli.piippo at qt.io Wed Apr 5 09:07:26 2017 From: samuli.piippo at qt.io (Samuli Piippo) Date: Wed, 5 Apr 2017 10:07:26 +0300 Subject: [Development] Nominating Katja Marttila for Approver status Message-ID: <2ae1ae6c-457b-3083-32bf-1aa5e32fcf9c@qt.io> Hi, I'd like to nominate Katja Marttila for Approver status. Katja has been working among other things as the maintainer for Qt Installer Framework for a while now. Her gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Katja+Marttila%22+status:+merged,n,z -samuli From jani.heikkinen at qt.io Wed Apr 5 09:40:23 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 5 Apr 2017 07:40:23 +0000 Subject: [Development] Nominating Katja Marttila for Approver status In-Reply-To: <2ae1ae6c-457b-3083-32bf-1aa5e32fcf9c@qt.io> References: <2ae1ae6c-457b-3083-32bf-1aa5e32fcf9c@qt.io> Message-ID: +1 -Jani ________________________________________ From: Development on behalf of Samuli Piippo Sent: Wednesday, April 05, 2017 10:07 AM To: development at qt-project.org Subject: [Development] Nominating Katja Marttila for Approver status Hi, I'd like to nominate Katja Marttila for Approver status. Katja has been working among other things as the maintainer for Qt Installer Framework for a while now. Her gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Katja+Marttila%22+status:+merged,n,z -samuli _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andy.shaw at qt.io Wed Apr 5 10:08:59 2017 From: andy.shaw at qt.io (Andy Shaw) Date: Wed, 5 Apr 2017 08:08:59 +0000 Subject: [Development] Nominating Katja Marttila for Approver status In-Reply-To: <2ae1ae6c-457b-3083-32bf-1aa5e32fcf9c@qt.io> References: <2ae1ae6c-457b-3083-32bf-1aa5e32fcf9c@qt.io> Message-ID: <98639F3B-238B-45F1-8B39-F5454A0B455A@qt.io> +1 from me. Andy Development på vegne av Samuli Piippo skrev følgende den 05.04.2017, 09.07: Hi, I'd like to nominate Katja Marttila for Approver status. Katja has been working among other things as the maintainer for Qt Installer Framework for a while now. Her gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Katja+Marttila%22+status:+merged,n,z -samuli _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Wed Apr 5 11:24:15 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 5 Apr 2017 09:24:15 +0000 Subject: [Development] Moving Qt's undo framework out of Qt Widgets Message-ID: I'd like to remove the undo framework's dependency on widgets. There's a bug report for this here: https://bugreports.qt.io/browse/QTBUG-40040 My plan is mentioned in the commit message of the following change: https://codereview.qt-project.org/#/c/190704/ To summarise: - Introduce QGuiUndo* classes that don't have any QAction-related API (which is the only thing tying the framework to widgets) - Make the existing QUndo* classes derive from the respective Qt Gui classes This would allow existing code that relies on the QAction API (or otherwise uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. Qt Quick applications to use the undo framework without relying on widgets. This is a change for Qt 6, seeing as we cannot "[for existing classes] change the class hierachy in any way (add, remove, or reorder base classes)." https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts If people are OK with having duplicated code until Qt 6 (it's code that's rarely touched anyway), we could also introduce the QGuiUndo* classes in the next applicable minor version. Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do with graphics". While he phrased it in a pretty ridiculous (the majority of applications using undo/redo are graphical user interfaces) and familiarly arrogant way, I do agree that non-GUI applications could benefit from this. So, should this get its own module, and if so, can widgets depend on it? From annulen at yandex.ru Wed Apr 5 11:28:42 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 05 Apr 2017 12:28:42 +0300 Subject: [Development] Moving Qt's undo framework out of Qt Widgets In-Reply-To: References: Message-ID: <5587641491384522@web32j.yandex.ru> 05.04.2017, 12:24, "Mitch Curtis" : > I'd like to remove the undo framework's dependency on widgets. There's a bug report for this here: > > https://bugreports.qt.io/browse/QTBUG-40040 > > My plan is mentioned in the commit message of the following change: > > https://codereview.qt-project.org/#/c/190704/ > > To summarise: > > - Introduce QGuiUndo* classes that don't have any QAction-related API (which is the only thing tying the framework to widgets) > - Make the existing QUndo* classes derive from the respective Qt Gui classes Out of curiosity, why does this code have to be in QtGui? Looks pretty-much GUI-independent. > > This would allow existing code that relies on the QAction API (or otherwise uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. Qt Quick applications to use the undo framework without relying on widgets. > > This is a change for Qt 6, seeing as we cannot "[for existing classes] change the class hierachy in any way (add, remove, or reorder base classes)." > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts > > If people are OK with having duplicated code until Qt 6 (it's code that's rarely touched anyway), we could also introduce the QGuiUndo* classes in the next applicable minor version. > > Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do with graphics". While he phrased it in a pretty ridiculous (the majority of applications using undo/redo are graphical user interfaces) and familiarly arrogant way, I do agree that non-GUI applications could benefit from this. > > So, should this get its own module, and if so, can widgets depend on it? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From mitch.curtis at qt.io Wed Apr 5 11:33:28 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 5 Apr 2017 09:33:28 +0000 Subject: [Development] Moving Qt's undo framework out of Qt Widgets In-Reply-To: <5587641491384522@web32j.yandex.ru> References: <5587641491384522@web32j.yandex.ru> Message-ID: > -----Original Message----- > From: Konstantin Tokarev [mailto:annulen at yandex.ru] > Sent: Wednesday, 5 April 2017 11:29 AM > To: Mitch Curtis ; development at qt-project.org > Subject: Re: [Development] Moving Qt's undo framework out of Qt Widgets > > > > 05.04.2017, 12:24, "Mitch Curtis" : > > I'd like to remove the undo framework's dependency on widgets. There's a > bug report for this here: > > > > https://bugreports.qt.io/browse/QTBUG-40040 > > > > My plan is mentioned in the commit message of the following change: > > > > https://codereview.qt-project.org/#/c/190704/ > > > > To summarise: > > > > - Introduce QGuiUndo* classes that don't have any QAction-related API > (which is the only thing tying the framework to widgets) > > - Make the existing QUndo* classes derive from the respective Qt Gui > classes > > Out of curiosity, why does this code have to be in QtGui? Looks pretty-much > GUI-independent. It doesn't, it just seemed like a reasonable option to me; it's in the same repo and it's mostly used by GUI applications. The same could be said about QValidator and friends. > > > > This would allow existing code that relies on the QAction API (or otherwise > uses widgets anyway and hence doesn't care) to remain unchanged, and for > e.g. Qt Quick applications to use the undo framework without relying on > widgets. > > > > This is a change for Qt 6, seeing as we cannot "[for existing classes] change > the class hierachy in any way (add, remove, or reorder base classes)." > > > > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2 > B%2B#The_Do.27s_and_Don.27ts > > > > If people are OK with having duplicated code until Qt 6 (it's code that's > rarely touched anyway), we could also introduce the QGuiUndo* classes in > the next applicable minor version. > > > > Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do > with graphics". While he phrased it in a pretty ridiculous (the majority of > applications using undo/redo are graphical user interfaces) and familiarly > arrogant way, I do agree that non-GUI applications could benefit from this. > > > > So, should this get its own module, and if so, can widgets depend on it? > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin From Shawn.Rutledge at qt.io Wed Apr 5 12:34:15 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 5 Apr 2017 10:34:15 +0000 Subject: [Development] Moving Qt's undo framework out of Qt Widgets In-Reply-To: References: Message-ID: <345B9E7B-38E7-4FF6-AB0B-D1D3FD14D154@qt.io> > On 5 Apr 2017, at 11:24, Mitch Curtis wrote: > > I'd like to remove the undo framework's dependency on widgets. There's a bug report for this here: > > https://bugreports.qt.io/browse/QTBUG-40040 > > My plan is mentioned in the commit message of the following change: > > https://codereview.qt-project.org/#/c/190704/ > > To summarise: > > - Introduce QGuiUndo* classes that don't have any QAction-related API (which is the only thing tying the framework to widgets) I keep wishing that QAction wasn’t tied to widgets either, though. Could we fix that in Qt 6? I think it would remove obstacles in quite a few places... > - Make the existing QUndo* classes derive from the respective Qt Gui classes > > This would allow existing code that relies on the QAction API (or otherwise uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. Qt Quick applications to use the undo framework without relying on widgets. > > This is a change for Qt 6, seeing as we cannot "[for existing classes] change the class hierachy in any way (add, remove, or reorder base classes)." > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts > > If people are OK with having duplicated code until Qt 6 (it's code that's rarely touched anyway), we could also introduce the QGuiUndo* classes in the next applicable minor version. > > Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do with graphics". While he phrased it in a pretty ridiculous (the majority of applications using undo/redo are graphical user interfaces) and familiarly arrogant way, I do agree that non-GUI applications could benefit from this. > > So, should this get its own module, and if so, can widgets depend on it? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Wed Apr 5 12:37:09 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 5 Apr 2017 12:37:09 +0200 Subject: [Development] Moving Qt's undo framework out of Qt Widgets In-Reply-To: References: Message-ID: <20170405103709.GQ4621@troll08> On Wed, Apr 05, 2017 at 09:24:15AM +0000, Mitch Curtis wrote: > So, should this get its own module, and if so, can widgets depend on > it? > an own module just for that seems over the top - i don't think we want to end up with 100 micro-libraries. however, splitting up qtcore has been raised multiple times, and putting this into one of the resulting libs would seem reasonable. for example, this seems conceptually quite related to item models. possibly also state machine. and animation. these are all things which initially elicit a "huh, this is core?" response, until you think a bit about it. GuiSupport may be a better name for it (i'm sure some will disagree). generally, an effort to map all the qt classes to smaller libraries would be welcome. also, a plan for splitting up qtbase wouldn't be entirely off the mark. untangling tests and examples would be the major effort here. From Morten.Sorvig at qt.io Wed Apr 5 14:02:32 2017 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Wed, 5 Apr 2017 12:02:32 +0000 Subject: [Development] Moving Qt's undo framework out of Qt Widgets Message-ID: > On 5 Apr 2017, at 12:37, Oswald Buddenhagen wrote: > > On Wed, Apr 05, 2017 at 09:24:15AM +0000, Mitch Curtis wrote: >> So, should this get its own module, and if so, can widgets depend on >> it? >> > an own module just for that seems over the top - i don't think we want > to end up with 100 micro-libraries. > > however, splitting up qtcore has been raised multiple times, and > putting this into one of the resulting libs would seem reasonable. for > example, this seems conceptually quite related to item models. possibly > also state machine. and animation. these are all things which initially > elicit a "huh, this is core?" response, until you think a bit about it. > GuiSupport may be a better name for it (i'm sure some will disagree). So both QtCore and QtGui could be split up into “Core” and “Kitchen Sink”; QtCoreCore QtGuiCore QtCoreSink QtGuiSink QtWidgets and QtDeclarative would depend on all of these; are we gaining anything? Well: 1) The “Core” versions will be satisfyingly uncluttered. 2) Those who do not use QtWidgets or QtDeclarative can possibly depend on smaller libraries. > > also, a plan for splitting up qtbase wouldn't be entirely off the mark. > untangling tests and examples would be the major effort here. (At the risk of derailing the discussion (sorry Mitch)) No, we should follow Google and Facebook’s lead: large monolithic repos (as large as the infrastructure can handle), which can be updated atomically. Morten From chgans at gna.org Wed Apr 5 14:38:16 2017 From: chgans at gna.org (Ch'Gans) Date: Thu, 6 Apr 2017 00:38:16 +1200 Subject: [Development] Moving Qt's undo framework out of Qt Widgets In-Reply-To: References: Message-ID: On 6 April 2017 at 00:02, Morten Sørvig wrote: > > >> On 5 Apr 2017, at 12:37, Oswald Buddenhagen wrote: >> >> On Wed, Apr 05, 2017 at 09:24:15AM +0000, Mitch Curtis wrote: >>> So, should this get its own module, and if so, can widgets depend on >>> it? >>> >> an own module just for that seems over the top - i don't think we want >> to end up with 100 micro-libraries. >> >> however, splitting up qtcore has been raised multiple times, and >> putting this into one of the resulting libs would seem reasonable. for >> example, this seems conceptually quite related to item models. possibly >> also state machine. and animation. these are all things which initially >> elicit a "huh, this is core?" response, until you think a bit about it. >> GuiSupport may be a better name for it (i'm sure some will disagree). > > So both QtCore and QtGui could be split up into “Core” and “Kitchen Sink”; > > QtCoreCore QtGuiCore > QtCoreSink QtGuiSink You forgot QtCoreKitchen, QtGuiKitchen, QtCoreKitchenSinkSupport, QtGuiKitchenCoreSinkSupport and of course QtCoreKitchenGuiSinkCoreSupport! ;) I would even consider a new QtCoreGuiBridge module to help with decoupling GUI from Core and Sink from kitchen. Of course all class names would start with QAbstract, eg QAbstractCoreGuiKitchenSinkBridge. This goes without saying that to help with creating object of arbitrary concrete types a QCoreGuiKitchenSinkBridgeFactory is a must have! Along with a proper QCoreGuiKitchenSinkBridgeFactoryPluginInterface and for user's convenience (and the fun of it) a QCoreGuiKitchenSinkBridgeFactoryPluginLoader. -> [] Chris > > QtWidgets and QtDeclarative would depend on all of these; are we gaining > anything? Well: > > 1) The “Core” versions will be satisfyingly uncluttered. > 2) Those who do not use QtWidgets or QtDeclarative can possibly depend > on smaller libraries. > >> >> also, a plan for splitting up qtbase wouldn't be entirely off the mark. >> untangling tests and examples would be the major effort here. > > (At the risk of derailing the discussion (sorry Mitch)) No, we should > follow Google and Facebook’s lead: large monolithic repos (as large as > the infrastructure can handle), which can be updated atomically. > > Morten > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jesus.Fernandez at qt.io Wed Apr 5 15:01:21 2017 From: Jesus.Fernandez at qt.io (Jesus Fernandez) Date: Wed, 5 Apr 2017 15:01:21 +0200 Subject: [Development] New repository for WebGL Streaming QPA plugin Message-ID: <7576217.LGHH9SYOPy@linux-5lbc> Hi all! I have been working on a QPA plugin to send the GLES2.0 calls from a host computer over the network to a WebGL capable browser. Now it's approaching a state in which it could be usable. For this, we'll need a new public repository. Having a public and controlled repository could help the project to grow up significantly. The name could be Qt WebGL Streaming (qt/qtwebglstreaming). The current location of the project is https://git.qt.io/playground/qtwebglplugin -- Best regards, Jesus From gunnar.roth at gmx.de Wed Apr 5 16:22:26 2017 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Wed, 5 Apr 2017 16:22:26 +0200 Subject: [Development] New repository for WebGL Streaming QPA plugin In-Reply-To: <7576217.LGHH9SYOPy@linux-5lbc> References: <7576217.LGHH9SYOPy@linux-5lbc> Message-ID: An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Wed Apr 5 16:45:42 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 5 Apr 2017 16:45:42 +0200 Subject: [Development] Moving Qt's undo framework out of Qt Widgets In-Reply-To: References: Message-ID: <20170405144542.GR4621@troll08> On Wed, Apr 05, 2017 at 12:02:32PM +0000, Morten Sørvig wrote: > On 5 Apr 2017, at 12:37, Oswald Buddenhagen wrote: > > also, a plan for splitting up qtbase wouldn't be entirely off the > > mark. untangling tests and examples would be the major effort here. > > No, we should follow Google and Facebook’s lead: large monolithic > repos (as large as the infrastructure can handle), which can be > updated atomically. > that's kinda the point: the infrastructure (and tooling) can't handle it, at multiple levels. for the atomicity, see https://bugreports.qt.io/browse/QTQAINFRA-868 . From annulen at yandex.ru Wed Apr 5 16:57:45 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 05 Apr 2017 17:57:45 +0300 Subject: [Development] Moving Qt's undo framework out of Qt Widgets In-Reply-To: <20170405144542.GR4621@troll08> References: <20170405144542.GR4621@troll08> Message-ID: <18371491404265@web26g.yandex.ru> 05.04.2017, 17:46, "Oswald Buddenhagen" : > On Wed, Apr 05, 2017 at 12:02:32PM +0000, Morten Sørvig wrote: >>  On 5 Apr 2017, at 12:37, Oswald Buddenhagen wrote: >>  > also, a plan for splitting up qtbase wouldn't be entirely off the >>  > mark. untangling tests and examples would be the major effort here. >> >>  No, we should follow Google and Facebook’s lead: large monolithic >>  repos (as large as the infrastructure can handle), which can be >>  updated atomically. > > that's kinda the point: the infrastructure (and tooling) can't handle > it, at multiple levels. > for the atomicity, see https://bugreports.qt.io/browse/QTQAINFRA-868 . Right now it requires a lot of time and patience to get any patch integrated into qt5.git. If everything is in the same repo, the same will apply to patches for other modules :/ > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From laszlo.agocs at qt.io Wed Apr 5 17:18:24 2017 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Wed, 5 Apr 2017 15:18:24 +0000 Subject: [Development] New repository for WebGL Streaming QPA plugin In-Reply-To: References: <7576217.LGHH9SYOPy@linux-5lbc> Message-ID: Hi, To clarify, would a qt-labs repo work? As I understand the code still needs maturization. It can eventually be graduated to a proper Qt module later on. (this also means the repo would not be CI controlled for now, but I suspect that’s fine) It is a bit unfortunate that the platform plugin cannot be part of qtbase, but it involves a WebSockets dependency and some additional tooling so there’s not much choice left. Cheers, Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Gunnar Roth Sent: onsdag 5. april 2017 16.22 To: Jesus Fernandez Cc: development at qt-project.org Subject: Re: [Development] New repository for WebGL Streaming QPA plugin When i klick on this I camoe to a login page of gitlab. When trying to register I get 1 error prohibited this user from being saved: * Email domain is not authorized for sign-up I tried that with gmx.de and siemens.com Regards, Gunnar Roth Gesendet: Mittwoch, 05. April 2017 um 15:01 Uhr Von: "Jesus Fernandez" > An: development at qt-project.org Betreff: [Development] New repository for WebGL Streaming QPA plugin Hi all! I have been working on a QPA plugin to send the GLES2.0 calls from a host computer over the network to a WebGL capable browser. Now it's approaching a state in which it could be usable. For this, we'll need a new public repository. Having a public and controlled repository could help the project to grow up significantly. The name could be Qt WebGL Streaming (qt/qtwebglstreaming). The current location of the project is https://git.qt.io/playground/qtwebglplugin -- Best regards, Jesus _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Wed Apr 5 17:20:52 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 5 Apr 2017 15:20:52 +0000 Subject: [Development] New repository for WebGL Streaming QPA plugin In-Reply-To: References: <7576217.LGHH9SYOPy@linux-5lbc> , Message-ID: Hi, qt-labs sounds like a good fit to me, too. And having a repo under there under CI control is no problem at all. Simon On 5. Apr 2017, at 17:18, Laszlo Agocs > wrote: Hi, To clarify, would a qt-labs repo work? As I understand the code still needs maturization. It can eventually be graduated to a proper Qt module later on. (this also means the repo would not be CI controlled for now, but I suspect that’s fine) It is a bit unfortunate that the platform plugin cannot be part of qtbase, but it involves a WebSockets dependency and some additional tooling so there’s not much choice left. Cheers, Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Gunnar Roth Sent: onsdag 5. april 2017 16.22 To: Jesus Fernandez > Cc: development at qt-project.org Subject: Re: [Development] New repository for WebGL Streaming QPA plugin When i klick on this I camoe to a login page of gitlab. When trying to register I get 1 error prohibited this user from being saved: * Email domain is not authorized for sign-up I tried that with gmx.de and siemens.com Regards, Gunnar Roth Gesendet: Mittwoch, 05. April 2017 um 15:01 Uhr Von: "Jesus Fernandez" > An: development at qt-project.org Betreff: [Development] New repository for WebGL Streaming QPA plugin Hi all! I have been working on a QPA plugin to send the GLES2.0 calls from a host computer over the network to a WebGL capable browser. Now it's approaching a state in which it could be usable. For this, we'll need a new public repository. Having a public and controlled repository could help the project to grow up significantly. The name could be Qt WebGL Streaming (qt/qtwebglstreaming). The current location of the project is https://git.qt.io/playground/qtwebglplugin -- Best regards, Jesus _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Wed Apr 5 17:47:25 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 5 Apr 2017 17:47:25 +0200 Subject: [Development] New repository for WebGL Streaming QPA plugin In-Reply-To: References: <7576217.LGHH9SYOPy@linux-5lbc> Message-ID: <20170405154725.GA26547@troll08> On Wed, Apr 05, 2017 at 03:20:52PM +0000, Simon Hausmann wrote: > qt-labs sounds like a good fit to me, too. > given that the final destination is qt/, that's what should be done now. From oswald.buddenhagen at qt.io Wed Apr 5 17:51:40 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 5 Apr 2017 17:51:40 +0200 Subject: [Development] QList In-Reply-To: References: Message-ID: <20170405155140.GB26547@troll08> On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: > There's been a fair amount of talk about QList's future, so I'm curious: > so, now that the thread has finally died down, who volunteers to summarize is conclusions (and controversies) in a QUIP? i wouldn't want to actually read the 150 mails i skipped. your lucky number is ... 8! From markg85 at gmail.com Wed Apr 5 17:57:23 2017 From: markg85 at gmail.com (Mark Gaiser) Date: Wed, 5 Apr 2017 17:57:23 +0200 Subject: [Development] QList In-Reply-To: <20170405155140.GB26547@troll08> References: <20170405155140.GB26547@troll08> Message-ID: On Wed, Apr 5, 2017 at 5:51 PM, Oswald Buddenhagen wrote: > On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: >> There's been a fair amount of talk about QList's future, so I'm curious: >> > so, now that the thread has finally died down, who volunteers to > summarize is conclusions (and controversies) in a QUIP? i wouldn't want > to actually read the 150 mails i skipped. > > your lucky number is ... 8! 150? Your mail client misses a *few*. I count 212 ;) From oswald.buddenhagen at qt.io Wed Apr 5 18:58:53 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 5 Apr 2017 18:58:53 +0200 Subject: [Development] QList In-Reply-To: References: <20170405155140.GB26547@troll08> Message-ID: <20170405165853.GC26547@troll08> On Wed, Apr 05, 2017 at 05:57:23PM +0200, Mark Gaiser wrote: > On Wed, Apr 5, 2017 at 5:51 PM, Oswald Buddenhagen wrote: > > On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: > >> There's been a fair amount of talk about QList's future, so I'm curious: > >> > > so, now that the thread has finally died down, who volunteers to > > summarize is conclusions (and controversies) in a QUIP? i wouldn't want > > to actually read the 150 mails i skipped. > > > 150? Your mail client misses a *few*. > I count 212 ;) > 224. but i actually read the other ~70 mails before i got bored. ;) From eskil.abrahamsen-blomfeldt at qt.io Thu Apr 6 07:42:02 2017 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Thu, 6 Apr 2017 07:42:02 +0200 Subject: [Development] New repository for WebGL Streaming QPA plugin In-Reply-To: References: <7576217.LGHH9SYOPy@linux-5lbc> Message-ID: <8024617e-fd66-2abc-8653-6149d13cedd2@qt.io> Den 05.04.2017 17:18, skrev Laszlo Agocs: > > Hi, > > To clarify, would a qt-labs repo work? As I understand the code still > needs maturization. It can eventually be graduated to a proper Qt > module later on. (this also means the repo would not be CI controlled > for now, but I suspect that’s fine) > > It is a bit unfortunate that the platform plugin cannot be part of > qtbase, but it involves a WebSockets dependency and some additional > tooling so there’s not much choice left. > Hi, As you say, this would have just been put in Qt Base if it weren't for some meta-issues that are unrelated to the size of the feature or quality of it, so it makes no sense going via a qt-labs repository in my opinion. It is just a QPA plugin and mature enough that the code is currently in production in large-scale commercial projects, so I vote to put it in qt/. If it turns out that stabilization is needed, there is still time to do that, but I think the plugin is as ready for review in Qt as any other feature we regularly commit. -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Thu Apr 6 08:20:07 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 6 Apr 2017 06:20:07 +0000 Subject: [Development] New repository for WebGL Streaming QPA plugin In-Reply-To: <8024617e-fd66-2abc-8653-6149d13cedd2@qt.io> References: <7576217.LGHH9SYOPy@linux-5lbc> <8024617e-fd66-2abc-8653-6149d13cedd2@qt.io> Message-ID: <058878BA-F2BE-4999-8476-3CCA9C120DE4@qt.io> On 06 Apr 2017, at 07:42, Eskil Abrahamsen Blomfeldt > wrote: Den 05.04.2017 17:18, skrev Laszlo Agocs: Hi, To clarify, would a qt-labs repo work? As I understand the code still needs maturization. It can eventually be graduated to a proper Qt module later on. (this also means the repo would not be CI controlled for now, but I suspect that’s fine) It is a bit unfortunate that the platform plugin cannot be part of qtbase, but it involves a WebSockets dependency and some additional tooling so there’s not much choice left. Hi, As you say, this would have just been put in Qt Base if it weren't for some meta-issues that are unrelated to the size of the feature or quality of it, so it makes no sense going via a qt-labs repository in my opinion. It is just a QPA plugin and mature enough that the code is currently in production in large-scale commercial projects, so I vote to put it in qt/. If it turns out that stabilization is needed, there is still time to do that, but I think the plugin is as ready for review in Qt as any other feature we regularly commit. I don’t think it makes a lot of sense to put it into qt-labs now, just to move it to qt/ in a month or two. The code is actively being developed, and Jesus is committed to making this something we can ship as part of 5.10. So +1 for the repo in qt/. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Thu Apr 6 08:26:54 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 6 Apr 2017 06:26:54 +0000 Subject: [Development] QList In-Reply-To: <20170405155140.GB26547@troll08> References: <20170405155140.GB26547@troll08> Message-ID: <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> > On 05 Apr 2017, at 17:51, Oswald Buddenhagen wrote: > > On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: >> There's been a fair amount of talk about QList's future, so I'm curious: >> > so, now that the thread has finally died down, who volunteers to > summarize is conclusions (and controversies) in a QUIP? i wouldn't want > to actually read the 150 mails i skipped. Agree with Ossi. Summarising this in a QUIP would be very helpful, and reviewing that will hopefully then bring everybody on the same page. Cheers, Lars From ville.voutilainen at gmail.com Thu Apr 6 09:20:23 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 6 Apr 2017 10:20:23 +0300 Subject: [Development] QList In-Reply-To: <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> Message-ID: On 6 April 2017 at 09:26, Lars Knoll wrote: > >> On 05 Apr 2017, at 17:51, Oswald Buddenhagen wrote: >> >> On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: >>> There's been a fair amount of talk about QList's future, so I'm curious: >>> >> so, now that the thread has finally died down, who volunteers to >> summarize is conclusions (and controversies) in a QUIP? i wouldn't want >> to actually read the 150 mails i skipped. > > Agree with Ossi. Summarising this in a QUIP would be very helpful, and reviewing that will hopefully then bring everybody on the same page. It seems as if you're looking for a person who is reasonably apt at writing analysis/proposal papers, and bonus points if that person has summarized lengthy mailing list threads into such papers before, and further bonus points if that person has an irresistible urge to volunteer to do work after multiple people say "someone should do it". Okay, I will do it. :) From marc.mutz at kdab.com Thu Apr 6 10:25:25 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 6 Apr 2017 10:25:25 +0200 Subject: [Development] QList In-Reply-To: <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> Message-ID: <201704061025.26093.marc.mutz@kdab.com> On Thursday 06 April 2017 08:26:54 Lars Knoll wrote: > > On 05 Apr 2017, at 17:51, Oswald Buddenhagen > > wrote: > > > > On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: > >> There's been a fair amount of talk about QList's future, so I'm curious: > > so, now that the thread has finally died down, who volunteers to > > summarize is conclusions (and controversies) in a QUIP? i wouldn't want > > to actually read the 150 mails i skipped. > > Agree with Ossi. Summarising this in a QUIP would be very helpful, and > reviewing that will hopefully then bring everybody on the same page. IMO, There's no point in QUIPing this, yet, because while there's consensus to remove QList in the current form from Qt 6 APIs, there's no general exit strategy. I outlined one, but I don't feel it has gained anything near consensus, and no counter-proposals have been forthcoming. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ulf.hermann at qt.io Thu Apr 6 10:58:59 2017 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 6 Apr 2017 10:58:59 +0200 Subject: [Development] QList In-Reply-To: <201704061025.26093.marc.mutz@kdab.com> References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> <201704061025.26093.marc.mutz@kdab.com> Message-ID: > IMO, There's no point in QUIPing this, yet, because while there's consensus to > remove QList in the current form from Qt 6 APIs, there's no general exit > strategy. I outlined one, but I don't feel it has gained anything near > consensus, and no counter-proposals have been forthcoming. However, the way we are dealing with this now is not going to lead to a consensus anytime soon. Few people will read the >200 mails, and many of the mails include unrelated things. Summarizing what we have right now is definitely a good idea. If the resulting QUIP is not a consensus, then there are tools available to modify it until it is. Ulf From lars.knoll at qt.io Thu Apr 6 12:17:47 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 6 Apr 2017 10:17:47 +0000 Subject: [Development] QList In-Reply-To: References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> <201704061025.26093.marc.mutz@kdab.com> Message-ID: <15610E8E-C7EB-4EF2-B827-A1E988AA9D61@qt.io> > On 06 Apr 2017, at 10:58, Ulf Hermann wrote: > >> IMO, There's no point in QUIPing this, yet, because while there's consensus to >> remove QList in the current form from Qt 6 APIs, there's no general exit >> strategy. I outlined one, but I don't feel it has gained anything near >> consensus, and no counter-proposals have been forthcoming. > > However, the way we are dealing with this now is not going to lead to a consensus anytime soon. Few people will read the >200 mails, and many of the mails include unrelated things. Summarizing what we have right now is definitely a good idea. If the resulting QUIP is not a consensus, then there are tools available to modify it until it is. Exactly. The thread on the mailing lost forked into (partially bike shedding) discussions about many topics, and we won’t reach a conclusion continuing that way. Let’s start writing up things in a more structured way, that will hopefully lead us to a better picture on what people agree upon and where we have disagreements that need to be sorted out. Cheers, Lars From b.terrier at gmail.com Thu Apr 6 12:49:36 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Thu, 6 Apr 2017 12:49:36 +0200 Subject: [Development] SIGFPE in QQuickMenu and QBasicDrag Message-ID: Hi, I've started to work on a patch to fix QTBUG-45045 (https://bugreports.qt.io/browse/QTBUG-45045). The main issue is that the cursor position is compared to "int(qInf())" to check its validity. However casting infinity to int is undefined behavior and in some cases can trigger a SIGFPE and crash the process. For most users this generally does not happen because floating points exceptions are masked by default for x86 and x86_64 cpus. To fix this, the naive solution would be to replace "int(qInf())" by "std::numeric_limits::min()" as these two expressions evaluate to the same value (when SIGFPE is not triggered), but this does not solves the underlying issue. It seems the issue comes from the fact that "QPointF QGuiApplicationPrivate::lastCursorPosition" is initialized to "QPointF(qInf(), qInf())", so when "QCursor::pos()" is called and there is no screen and no cursor position was ever recorder, the value "QPointF(qInf(), qInf()).toPoint()" is returned. And because of the way "QPointF::toPoint()" is implemented, this is the same as "QPoint(qRound(qInf()), qRound(qInf()))" and "QPoint(int(qInf()), int(qInf()))". So in a way it makes sense to check against "int(qInf())" later in the code, except it is still undefined behavior. IMHO a solution could be to change "QPointF::toPoint()" so that for each coordinate -infinity is casted to std::numeric_limits::min() and +infinity is casted to std::numeric_limits::max(). What do you think about this? BR Benjamin Terrier From rjvbertin at gmail.com Thu Apr 6 23:46:55 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 06 Apr 2017 23:46:55 +0200 Subject: [Development] redistributing QPA and platform style plugins In-Reply-To: References: <1876998.PGiPlZ3921@bola> Message-ID: <1736226.IbJujbqxlG@portia.local> FWIW, I have bundled my modified Cocoa QPA and Macintosh style with the platform theme plugin I already had: https://cgit.kde.org/scratch/rjvbb/osx-integration.git/ The nice thing with QPA and platform theme plugins is that - a platform theme plugin calling itself cocoa overrides the one provided by libqcocoa.dylib (but can still initialise an instance of the native theme or its modified version for proxying purposes) - a 3rd party QPA plugin calling itself cocoa will override Qt's own version (or can, depending on its filename?). R From konstantin at podsvirov.pro Fri Apr 7 06:43:07 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 07 Apr 2017 07:43:07 +0300 Subject: [Development] New repository for WebGL Streaming QPA plugin In-Reply-To: <20170405154725.GA26547@troll08> References: <7576217.LGHH9SYOPy@linux-5lbc> <20170405154725.GA26547@troll08> Message-ID: <1287201491540187@web23o.yandex.ru> An HTML attachment was scrubbed... URL: From aha_1980 at gmx.de Fri Apr 7 06:49:14 2017 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 7 Apr 2017 06:49:14 +0200 Subject: [Development] Maintenance Tool with offline install function? Message-ID: <35c75476-8e6a-9430-034b-8b755168dae0@gmx.de> Hi all, Yesterday I installed a Qt 5.9 beta snapshot and I'm impressed how much the Maintenance Tool improved! The possibility to install Qt versions in parallel and to remove single components is awesome! There is one thing missing to make it perfect: Allow to store the downloaded archives local and install from that location later (The Cygwin setup allows this in a similar matter). This will surely help all the companies where computers have on internet access at all. So far I have always downloaded the offline installers (Windows mostly), but thats a pain if you need them in parallel or want to update Qt Creator at a time (I don't remember how often I have set up Qt versions and Kits in Creator). There is already a bugreport for this: https://bugreports.qt.io/browse/QTIFW-573 but there is no progress since two years. Thanks, and best regards, André From konstantin at podsvirov.pro Fri Apr 7 07:27:08 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 07 Apr 2017 08:27:08 +0300 Subject: [Development] Fwd: New repository for WebGL Streaming QPA plugin Message-ID: <1302131491542828@web29m.yandex.ru> An HTML attachment was scrubbed... URL: From announce at qt-project.org Fri Apr 7 12:33:08 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 7 Apr 2017 10:33:08 +0000 Subject: [Development] [Announce] Qt 5.9 Beta released In-Reply-To: References: Message-ID: Hi, I am happy to inform Qt 5.9 Beta is released today, see http://blog.qt.io/blog/2017/04/07/qt-5-9-beta-released/. As informed earlier beta binaries are available only via qt online installer (except QNX package for enterprise users which is still using offline installer & available in qt account) br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From sergio.martins at kdab.com Fri Apr 7 12:40:38 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Fri, 07 Apr 2017 11:40:38 +0100 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value Message-ID: <9767315cf8440e193a881c7853f2a228@kdab.com> Hi, Some time ago I documented the guidelines on passing by value vs const-ref: https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value This was discussed in #qt-labs at the time and informally +2'd there. But the reality is that passing small structs by value is not very popular and Qt's API mostly passes them by const-ref. I think this is a good time to have a more formal conversation, bikeshed+popcorn, then write a QUIP and hopefully change the API for Qt 6. The guideline is very simple: - If your type has a non-trivial copy-CTOR or non-trivial DTOR then pass by const-ref, no matter how small it is, to avoid calling those methods. *[1] - If your type has trivial CTOR and trivial DTOR, pass by value if it's small, otherwise const-ref. Small meaning <= 16 bytes. The idea is that by value allows the struct's members to be passed in CPU registers, see [2] for extensive research. The good news is, even if you don't care about raw performance, passing by value is more convenient, as you type less code, so IMO, more fun to use. [1] - Shared pointers should go by value though, I'll try to prove it in the QUIP. [2] - http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/ Cheers, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From annulen at yandex.ru Fri Apr 7 13:30:25 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 07 Apr 2017 14:30:25 +0300 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <9767315cf8440e193a881c7853f2a228@kdab.com> References: <9767315cf8440e193a881c7853f2a228@kdab.com> Message-ID: <3758281491564625@web20o.yandex.ru> 07.04.2017, 13:41, "Sergio Martins" : > Hi, > > Some time ago I documented the guidelines on passing by value vs > const-ref: > https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value > This was discussed in #qt-labs at the time and informally +2'd there. > > But the reality is that passing small structs by value is not very > popular and Qt's API mostly passes them by const-ref. > > I think this is a good time to have a more formal conversation, > bikeshed+popcorn, then write a QUIP and hopefully change the API for Qt > 6. > > The guideline is very simple: > - If your type has a non-trivial copy-CTOR or non-trivial DTOR then pass > by const-ref, no matter how small it is, to avoid calling those methods. > *[1] > - If your type has trivial CTOR and trivial DTOR, pass by value if it's > small, otherwise const-ref. Small meaning <= 16 bytes. I think such rule should be enforced by tooling, e.g. something like clazy. Btw, do you consider case when properties of type in question are changed in future Qt version, e.g. new fields or ctors are added (in case of non-public class/struct)? > > The idea is that by value allows the struct's members to be passed in > CPU registers, see [2] for extensive research. > > The good news is, even if you don't care about raw performance, passing > by value is more convenient, as you type less code, so IMO, more fun to > use. > > [1] - Shared pointers should go by value though, I'll try to prove it in > the QUIP. > [2] - > http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/ > > Cheers, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From nassian at bitshift-dynamics.com Fri Apr 7 13:39:22 2017 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Fri, 7 Apr 2017 13:39:22 +0200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <3758281491564625@web20o.yandex.ru> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <3758281491564625@web20o.yandex.ru> Message-ID: <48DFCE90-1889-4939-884F-126E84DF4028@bitshift-dynamics.com> I don't care, I always pass const-ref ;) Beste Grüße / Best regards, Alexander Nassian > Am 07.04.2017 um 13:30 schrieb Konstantin Tokarev : > > > > 07.04.2017, 13:41, "Sergio Martins" : >> Hi, >> >> Some time ago I documented the guidelines on passing by value vs >> const-ref: >> https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value >> This was discussed in #qt-labs at the time and informally +2'd there. >> >> But the reality is that passing small structs by value is not very >> popular and Qt's API mostly passes them by const-ref. >> >> I think this is a good time to have a more formal conversation, >> bikeshed+popcorn, then write a QUIP and hopefully change the API for Qt >> 6. >> >> The guideline is very simple: >> - If your type has a non-trivial copy-CTOR or non-trivial DTOR then pass >> by const-ref, no matter how small it is, to avoid calling those methods. >> *[1] >> - If your type has trivial CTOR and trivial DTOR, pass by value if it's >> small, otherwise const-ref. Small meaning <= 16 bytes. > > I think such rule should be enforced by tooling, e.g. something like clazy. > > Btw, do you consider case when properties of type in question are changed > in future Qt version, e.g. new fields or ctors are added (in case of non-public > class/struct)? > >> >> The idea is that by value allows the struct's members to be passed in >> CPU registers, see [2] for extensive research. >> >> The good news is, even if you don't care about raw performance, passing >> by value is more convenient, as you type less code, so IMO, more fun to >> use. >> >> [1] - Shared pointers should go by value though, I'll try to prove it in >> the QUIP. >> [2] - >> http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/ >> >> Cheers, >> -- >> Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - The Qt, C++ and OpenGL Experts >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com From lars.knoll at qt.io Fri Apr 7 15:02:55 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 7 Apr 2017 13:02:55 +0000 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <9767315cf8440e193a881c7853f2a228@kdab.com> References: <9767315cf8440e193a881c7853f2a228@kdab.com> Message-ID: > On 7 Apr 2017, at 12:40, Sergio Martins wrote: > > Hi, > > > Some time ago I documented the guidelines on passing by value vs const-ref: https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value > This was discussed in #qt-labs at the time and informally +2'd there. > > But the reality is that passing small structs by value is not very popular and Qt's API mostly passes them by const-ref. > > I think this is a good time to have a more formal conversation, bikeshed+popcorn, then write a QUIP and hopefully change the API for Qt 6. > > > The guideline is very simple: > - If your type has a non-trivial copy-CTOR or non-trivial DTOR then pass by const-ref, no matter how small it is, to avoid calling those methods. *[1] > - If your type has trivial CTOR and trivial DTOR, pass by value if it's small, otherwise const-ref. Small meaning <= 16 bytes. > > The idea is that by value allows the struct's members to be passed in CPU registers, see [2] for extensive research. Those rules sound about right. We can do this nowadays, as x86 will become rather irrelevant for Qt 6 (where passing structs by reference would probably be better in most cases due to the limited amount of available registers). There might be a little catch with regards to structs containing members that are 8 bytes in size (aka quint64). Are those getting passed in registers on 32bit ARM? Cheers, Lars > > > The good news is, even if you don't care about raw performance, passing by value is more convenient, as you type less code, so IMO, more fun to use. > > > [1] - Shared pointers should go by value though, I'll try to prove it in the QUIP. > [2] - http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/ > > > > > > Cheers, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Apr 7 17:21:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Apr 2017 08:21:20 -0700 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: References: <9767315cf8440e193a881c7853f2a228@kdab.com> Message-ID: <1668847.PXCT03TzNY@tjmaciei-mobl1> Em sexta-feira, 7 de abril de 2017, às 06:02:55 PDT, Lars Knoll escreveu: > Those rules sound about right. We can do this nowadays, as x86 will become > rather irrelevant for Qt 6 (where passing structs by reference would > probably be better in most cases due to the limited amount of available > registers). x86 doesn't pass in registers anyway. The best you'd get is the elements of the struct pushed on the stack, instead of pushed elsewhere on the stack and an address to the stack pushed on the stack. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Apr 7 17:28:51 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 7 Apr 2017 17:28:51 +0200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: References: <9767315cf8440e193a881c7853f2a228@kdab.com> Message-ID: <201704071728.51785.marc.mutz@kdab.com> On Friday 07 April 2017 15:02:55 Lars Knoll wrote: > There might be a little catch with regards to structs containing members > that are 8 bytes in size (aka quint64). Are those getting passed in > registers on 32bit ARM? Forget register passing. To a first approximation, it does not matter. If you pass by cref, you surely force the value on the stack, anyway. What pass-by-value has going for it is the elimination of memory, and with it the aliasing and const_cast problems that make the compiler's and developer's work hard. Please watch Chandler Carruth's BoostCon 2013 presentation for the pov of compiler writers (https://www.youtube.com/watch?v=eR34r7HOU14) and Lawrence Crowl's CppCon 2014 presentation for the pov of a developer (https://www.youtube.com/watch?v=17rtjq9r27M). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From chgans at gna.org Fri Apr 7 17:31:07 2017 From: chgans at gna.org (Ch'Gans) Date: Sat, 8 Apr 2017 03:31:07 +1200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <1668847.PXCT03TzNY@tjmaciei-mobl1> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <1668847.PXCT03TzNY@tjmaciei-mobl1> Message-ID: On 8 April 2017 at 03:21, Thiago Macieira wrote: > Em sexta-feira, 7 de abril de 2017, às 06:02:55 PDT, Lars Knoll escreveu: >> Those rules sound about right. We can do this nowadays, as x86 will become >> rather irrelevant for Qt 6 (where passing structs by reference would >> probably be better in most cases due to the limited amount of available >> registers). > > x86 doesn't pass in registers anyway. The best you'd get is the elements of > the struct pushed on the stack, instead of pushed elsewhere on the stack and > an address to the stack pushed on the stack. What about FPU registers? Qt API always pass 'qreal' by value... Chris > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Apr 7 17:45:33 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Apr 2017 08:45:33 -0700 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: References: <9767315cf8440e193a881c7853f2a228@kdab.com> <1668847.PXCT03TzNY@tjmaciei-mobl1> Message-ID: <1761217.2SK8arktMU@tjmaciei-mobl1> Em sexta-feira, 7 de abril de 2017, às 08:31:07 PDT, Ch'Gans escreveu: > > x86 doesn't pass in registers anyway. The best you'd get is the elements > > of > > the struct pushed on the stack, instead of pushed elsewhere on the stack > > and an address to the stack pushed on the stack. > > What about FPU registers? Qt API always pass 'qreal' by value... We're not talking about primitives. We're talking about structs that are very small and trivial. See for yourself: https://godbolt.org/g/pvwjWE Direct primitive passing is fine: https://godbolt.org/g/Ghj8US -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Apr 7 17:47:44 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 7 Apr 2017 17:47:44 +0200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <201704071728.51785.marc.mutz@kdab.com> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <201704071728.51785.marc.mutz@kdab.com> Message-ID: <201704071747.44473.marc.mutz@kdab.com> On Friday 07 April 2017 17:28:51 Marc Mutz wrote: > Crowl's CppCon 2014 presentation for the pov of a developer > (https://www.youtube.com/watch?v=17rtjq9r27M). Specifically https://youtu.be/17rtjq9r27M?t=1156 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From sergio.martins at kdab.com Fri Apr 7 18:35:22 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Fri, 07 Apr 2017 17:35:22 +0100 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: References: <9767315cf8440e193a881c7853f2a228@kdab.com> Message-ID: <4eaf92f8b7663081349ec9474afc3bd2@kdab.com> On 2017-04-07 14:02, Lars Knoll wrote: > There might be a little catch with regards to structs containing > members that are 8 bytes in size (aka quint64). Are those getting > passed in registers on 32bit ARM? struct struct_16Bytes { unsigned long long first, second; }; unsigned long long test(struct_16Bytes s) { return s.second; } Generates: mov r0, r2 ; Each member fills in two registers mov r1, r3 bx lr If I change the signature to: "test(const struct_16Bytes &s)", then it generates: ldr r2, [r0, #8] ; ldrs are slow, since they read from memory ldr r1, [r0, #12] mov r0, r2 bx lr (Tested on ARM 32bit, clang -target arm-none-linux-gnueabi) Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Fri Apr 7 19:10:38 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 7 Apr 2017 19:10:38 +0200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <1761217.2SK8arktMU@tjmaciei-mobl1> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <1668847.PXCT03TzNY@tjmaciei-mobl1> <1761217.2SK8arktMU@tjmaciei-mobl1> Message-ID: <96b02b66-d8db-3877-0543-9cf565b64951@kdab.com> Il 07/04/2017 17:45, Thiago Macieira ha scritto: > We're not talking about primitives. We're talking about structs that are very > small and trivial. See for yourself: > > https://godbolt.org/g/pvwjWE > > Direct primitive passing is fine: > > https://godbolt.org/g/Ghj8US Sorry, what do you mean "is fine"? What's not fine? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Fri Apr 7 19:54:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Apr 2017 10:54:23 -0700 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <96b02b66-d8db-3877-0543-9cf565b64951@kdab.com> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <1761217.2SK8arktMU@tjmaciei-mobl1> <96b02b66-d8db-3877-0543-9cf565b64951@kdab.com> Message-ID: <5673714.qGqS0UFU4U@tjmaciei-mobl1> Em sexta-feira, 7 de abril de 2017, às 10:10:38 PDT, Giuseppe D'Angelo escreveu: > Il 07/04/2017 17:45, Thiago Macieira ha scritto: > > We're not talking about primitives. We're talking about structs that are > > very small and trivial. See for yourself: > > > > https://godbolt.org/g/pvwjWE > > > > Direct primitive passing is fine: > > > > https://godbolt.org/g/Ghj8US > > Sorry, what do you mean "is fine"? What's not fine? Passing float or double by value means they get passed in the x87 registers. Passing float inside a struct means it's passed in the x86 stack instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nathan.osman at gmail.com Fri Apr 7 20:17:45 2017 From: nathan.osman at gmail.com (Nathan Osman) Date: Fri, 7 Apr 2017 11:17:45 -0700 Subject: [Development] What happened to the *-dbg packages in Ubuntu 17.04 Message-ID: Hi, I recently switched to the second beta of Kubuntu 17.04. I attempted to install the qtbase5-dbg package, only to discover that it was absent. In fact, not only was this package missing but all of the *-dbg packages for Qt components were missing. Is there another package that provides the debug symbols? Why were these packages removed? - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Apr 7 20:19:19 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 07 Apr 2017 21:19:19 +0300 Subject: [Development] What happened to the *-dbg packages in Ubuntu 17.04 In-Reply-To: References: Message-ID: <1758161491589159@web17j.yandex.ru> 07.04.2017, 21:18, "Nathan Osman" : > Hi, > > I recently switched to the second beta of Kubuntu 17.04. I attempted to install the qtbase5-dbg package, only to discover that it was absent. In fact, not only was this package missing but all of the *-dbg packages for Qt components were missing. > > Is there another package that provides the debug symbols? Why were these packages removed? Hi, Qt Project is not responsible for distro packages. Please ask your package maintainer. > > - Nathan > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From Shawn.Rutledge at qt.io Fri Apr 7 21:38:37 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 7 Apr 2017 19:38:37 +0000 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <5673714.qGqS0UFU4U@tjmaciei-mobl1> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <1761217.2SK8arktMU@tjmaciei-mobl1> <96b02b66-d8db-3877-0543-9cf565b64951@kdab.com> <5673714.qGqS0UFU4U@tjmaciei-mobl1> Message-ID: On Apr 7, 2017, at 19:54, Thiago Macieira wrote: > Em sexta-feira, 7 de abril de 2017, às 10:10:38 PDT, Giuseppe D'Angelo > escreveu: >> Il 07/04/2017 17:45, Thiago Macieira ha scritto: >>> We're not talking about primitives. We're talking about structs that are >>> very small and trivial. See for yourself: >>> >>> https://godbolt.org/g/pvwjWE >>> >>> Direct primitive passing is fine: >>> >>> https://godbolt.org/g/Ghj8US >> >> Sorry, what do you mean "is fine"? What's not fine? > > Passing float or double by value means they get passed in the x87 registers. SIMD registers you mean, or are those the same? At some point I read that the 387-era FPU instructions are way too slow by comparison nowadays, but I thought if that’s the case then probably the compilers are doing whatever is fastest by now... > Passing float inside a struct means it's passed in the x86 stack instead. No difference whether by value or by reference? The compiler couldn’t break up the struct and put different members in different registers? From rjvbertin at gmail.com Fri Apr 7 21:40:02 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 07 Apr 2017 12:40:02 -0700 (PDT) Subject: [Development] Qt 5.9.0 RC aborts on OS X 10.9 Message-ID: <1672823.UEsenGiBq4@portia.local> Hello, A somewhat unorthodox issue report. I encountered the error messages below after building the 5.9.0RC QMacStyle against Qt 5.8.0 (hence also reporting via the ML): 2017-04-07 21:26:41.315 oxygen-demo5[3673:d0b] +[NSGraphicsContext graphicsContextWithCGContext:flipped:]: unrecognized selector sent to class 0x7fff794b78f8 2017-04-07 21:26:41.317 oxygen-demo5[3673:d0b] +[NSGraphicsContext graphicsContextWithCGContext:flipped:]: unrecognized selector sent to class 0x7fff794b78f8 2017-04-07 21:26:41.323 oxygen-demo5[3673:d0b] ( 0 CoreFoundation 0x00007fff8a11e25c __exceptionPreprocess + 172 1 libobjc.A.dylib 0x00007fff8af92e75 objc_exception_throw + 43 2 CoreFoundation 0x00007fff8a12102d +[NSObject(NSObject) doesNotRecognizeSelector:] + 205 3 CoreFoundation 0x00007fff8a07c272 ___forwarding___ + 1010 4 CoreFoundation 0x00007fff8a07bdf8 _CF_forwarding_prep_0 + 120 5 libqaltmacstyle.dylib 0x000000010bb6d3ae _ZNK16QMacStylePrivate13drawFocusRingEP8QPainterRK5QRectiid + 1182 6 libqaltmacstyle.dylib 0x000000010bb7acb1 _ZNK9QMacStyle11drawControlEN6QStyle14ControlElementEPK12QStyleOptionP8QPainterPK7QWidget + 5281 7 libqaltmacstyle.dylib 0x000000010bb75c93 _ZNK9QMacStyle9styleHintEN6QStyle9StyleHintEPK12QStyleOptionPK7QWidgetP16QStyleHintReturn + 739 8 QtWidgets 0x0000000103be3674 _ZN18QFocusFramePrivate10updateSizeEv + 356 9 QtWidgets 0x0000000103be3489 _ZN18QFocusFramePrivate6updateEv + 41 10 libqaltmacstyle.dylib 0x000000010bb876c7 _ZN9QMacStyle5eventEP6QEvent + 567 This is when building on OS X 10.9.5 using the 10.9 SDK (which always worked better than using the 10.10 SDK). I'm not exactly certain when the graphicsContextWithCGContext:flipped selector was introduced; apparently in 10.10 but apparently in a later 10.10 version than represented by the 10.10 SDK on OS X 10.9 . IOW, I needed to protect the new selector with `#if QT_MACOS_PLATFORM_SDK_EQUAL_OR_ABOVE(__MAC_10_11)` and use the old version otherwise. HtH, René From giuseppe.dangelo at kdab.com Fri Apr 7 21:45:49 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 7 Apr 2017 21:45:49 +0200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <5673714.qGqS0UFU4U@tjmaciei-mobl1> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <1761217.2SK8arktMU@tjmaciei-mobl1> <96b02b66-d8db-3877-0543-9cf565b64951@kdab.com> <5673714.qGqS0UFU4U@tjmaciei-mobl1> Message-ID: <6388d26a-d6ca-7f10-27eb-f941a28888da@kdab.com> Il 07/04/2017 19:54, Thiago Macieira ha scritto: >> Sorry, what do you mean "is fine"? What's not fine? > Passing float or double by value means they get passed in the x87 registers. > Passing float inside a struct means it's passed in the x86 stack instead. This is a separate discussion, though. I.e. not "by value", not "by const ref", but "unpacked field by field". Unlike value/const-ref, which has also implications for the compiler (no aliasing, better value tracking, etc.), value/unpacked should be purely about optimizing for the ABI. And I still wonder: is any of this really an issue on modern superscalar, out of order CPU architectures? Does anyone know hard numbers, research papers, tooling, anything to show that unpacking gives actual benefits, because CPU vendors cannot or did not optimize for this case? I've tried to measure the difference of calling f(QStringView) vs. f(char16_t*, size_t) on Windows, and the results were simply lost in the variance. (And then whatever results I would've extracted, I'm sure they would likely be completely different on another CPU). My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Fri Apr 7 22:24:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Apr 2017 13:24:44 -0700 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: References: <9767315cf8440e193a881c7853f2a228@kdab.com> <5673714.qGqS0UFU4U@tjmaciei-mobl1> Message-ID: <6844465.RQdgE4WuFR@tjmaciei-mobl1> Em sexta-feira, 7 de abril de 2017, às 12:38:37 PDT, Shawn Rutledge escreveu: > > Passing float or double by value means they get passed in the x87 > > registers. > > SIMD registers you mean, or are those the same? At some point I read that > the 387-era FPU instructions are way too slow by comparison nowadays, but I > thought if that’s the case then probably the compilers are doing whatever > is fastest by now... No, I really mean the x87 registers. We're talking about the x86 ABI here, not the x86-64 or x32 ABI. Yes, they are mighty slow. But they are still used because that's what ABIs are for: retain compatibility. GCC and Clang, when generating code for generic x86, will use x87 instructions anyway. So you may say that the data is already in the x87 coprocessor. Might as well leave it there. But when compiling with -msse2 -mfpmath=sse (like we do QtCore and QtGui), the math itself is made with SSE instead, even if we have to pass arguments via x87 registers. To change that, we'd need -msseregparm, but that's an ABI- changing option. > > Passing float inside a struct means it's passed in the x86 stack instead. > > No difference whether by value or by reference? The compiler couldn’t break > up the struct and put different members in different registers? The difference between passing by value and by reference is whether the reference is included in the stack or not. See https://godbolt.org/g/cq643O. It could break up, but doesn't because the ABI doesn't allow for that. Modern ABIs (except for MS Windows) allow for that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ernst.maurer at gmail.com Fri Apr 7 22:56:24 2017 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Fri, 07 Apr 2017 20:56:24 +0000 Subject: [Development] qbs (qt creator submodule) failed to checkout Message-ID: I'm no an active developer, so I'm getting the source of Qt Creator probably one time per 2-4 months, and no one checkout was successful during last year.always the same error *Cloning into 'C:/dev/workspace/qt-creator/src/shared/qbs'...* *fatal: repository 'http://code.qt.io/cgit/qt-creator/qt-labs/qbs.git/ ' not found* *fatal: clone of 'http://code.qt.io/cgit/qt-creator/qt-labs/qbs.git ' into submodule path 'C:/dev/workspace/qt-creator/src/shared/qbs' failed* *Failed to clone 'src/shared/qbs'. Retry scheduled* Is the issue unfixed for so a long time? or I'm doing something wrong? this was a usual checkouts - latest version, as well as various tags Rgds, Ernst -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Apr 8 01:40:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Apr 2017 16:40:19 -0700 Subject: [Development] qbs (qt creator submodule) failed to checkout In-Reply-To: References: Message-ID: <2179809.gbAUdg757k@tjmaciei-mobl1> Em sexta-feira, 7 de abril de 2017, às 13:56:24 PDT, Ernst Maurer escreveu: > *fatal: repository 'http://code.qt.io/cgit/qt-creator/qt-labs/qbs.git/ > ' not found* The URL is wrong. What are you using to check out the submoudle? And what is your Qt Creator repository URL? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Apr 9 19:19:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 09 Apr 2017 10:19:50 -0700 Subject: [Development] Does anyone know anything about QPolygon or QPainterPath? (QTBUG-60024) Message-ID: <1627288.HMyY4bTpA7@tjmaciei-mobl1> https://bugreports.qt.io/browse/QTBUG-60024 All the commits in qpolygon.cpp or qpainterpath.cpp in the last 6 years are either doc updates, licence updates, or simple fixes (remove "register", make constructors explicit, etc.). This bug is about intersected(), but I have absolutely no clue about its implementation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gna.org Mon Apr 10 02:52:35 2017 From: chgans at gna.org (Ch'Gans) Date: Mon, 10 Apr 2017 12:52:35 +1200 Subject: [Development] Does anyone know anything about QPolygon or QPainterPath? (QTBUG-60024) In-Reply-To: <1627288.HMyY4bTpA7@tjmaciei-mobl1> References: <1627288.HMyY4bTpA7@tjmaciei-mobl1> Message-ID: On 10 April 2017 at 05:19, Thiago Macieira wrote: > https://bugreports.qt.io/browse/QTBUG-60024 > > All the commits in qpolygon.cpp or qpainterpath.cpp in the last 6 years are > either doc updates, licence updates, or simple fixes (remove "register", make > constructors explicit, etc.). > > This bug is about intersected(), but I have absolutely no clue about its > implementation. Hi, The only thing that I know about QPainterPath, QPolygonF and co, is that you should *never ever* use them to do geometry work. They simply don't work. I use QPainterPath and QPolygonF only for _rendering_ geometries. When it comes to manipulating geometry (predicates or construction), one is better off using Boost.Geometry, CGAL or the likes. Chris > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Apr 10 09:39:09 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 10 Apr 2017 07:39:09 +0000 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: References: Message-ID: Hi, Qt 5.9 is proceeding quite well and it is time to start planning Qt 5.10 schedule. We want to to release 5.10 before Christmas so we need to have Qt 5.10 FF at the beginning of August. I propose following initial schedule for Qt 5.10: - Qt 5.10 Feature Freeze: 8.8.2017 - Qt 5.10 Alpha Release: 31.8.2017 - First Qt 5.10 Beta Release 5.10.2017 - Qt 5.10 RC 16.11.2017 - Qt 5.10 final release 30.11.2017 br, Jani Heikkinen Release Manager The Qt Company From thiago.macieira at intel.com Mon Apr 10 17:45:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 10 Apr 2017 08:45:34 -0700 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: References: Message-ID: <1643490.9zMfjAF2Up@tjmaciei-mobl1> Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen escreveu: > Hi, > > Qt 5.9 is proceeding quite well and it is time to start planning Qt 5.10 > schedule. We want to to release 5.10 before Christmas so we need to have Qt > 5.10 FF at the beginning of August. I propose following initial schedule > for Qt 5.10: > > - Qt 5.10 Feature Freeze: 8.8.2017 > - Qt 5.10 Alpha Release: 31.8.2017 > - First Qt 5.10 Beta Release 5.10.2017 > - Qt 5.10 RC 16.11.2017 > - Qt 5.10 final release 30.11.2017 Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we have an idea of how much work it will be? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From roland.m.winklmeier at gmail.com Mon Apr 10 22:20:36 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Mon, 10 Apr 2017 22:20:36 +0200 Subject: [Development] [Announce] Qt 5.9 Beta released In-Reply-To: References: Message-ID: <7b48bb9e-415e-ce94-0f02-a96b792f7f29@gmail.com> Am 07.04.2017 um 12:33 schrieb List for announcements regarding Qt releases and development: > Hi, > > I am happy to inform Qt 5.9 Beta is released today, see http://blog.qt.io/blog/2017/04/07/qt-5-9-beta-released/. > As informed earlier beta binaries are available only via qt online installer (except QNX package for enterprise users which is still using offline installer & available in qt account) > > br, > Jani Heikkinen > Release Manager Sorry, if this question was answered already, but I couldn't find anything in the docs nor a final statement in the mailing list. Will there be official MSVC 2017 binaries available for the 5.9 release? I thought I read it will be, but there aren't any at the moment for the beta release. Cheers Roland From mwoehlke.floss at gmail.com Mon Apr 10 22:27:05 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 10 Apr 2017 16:27:05 -0400 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <9767315cf8440e193a881c7853f2a228@kdab.com> References: <9767315cf8440e193a881c7853f2a228@kdab.com> Message-ID: <58EBEA99.5080008@gmail.com> On 2017-04-07 06:40, Sergio Martins wrote: > Some time ago I documented the guidelines on passing by value vs > const-ref: > https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value > > But the reality is that passing small structs by value is not very > popular and Qt's API mostly passes them by const-ref. > > The guideline is very simple: > - If your type has a non-trivial copy-CTOR or non-trivial DTOR then pass > by const-ref, no matter how small it is, to avoid calling those methods. > *[1] > - If your type has trivial CTOR and trivial DTOR, pass by value if it's > small, otherwise const-ref. Small meaning <= 16 bytes. > > The idea is that by value allows the struct's members to be passed in > CPU registers, see [2] for extensive research. Option 2: Teach C++ to choose automatically if such types should be passed by value or by const-reference. This has the benefit that it can DTRT even when TRT varies by platform. (Option 3: Add a template class that implements Option 2? Is this possible?) -- Matthew From giuseppe.dangelo at kdab.com Mon Apr 10 22:32:29 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 10 Apr 2017 22:32:29 +0200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <58EBEA99.5080008@gmail.com> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <58EBEA99.5080008@gmail.com> Message-ID: <8f105e1d-0a00-7fe4-067d-2b453d62b298@kdab.com> Il 10/04/2017 22:27, Matthew Woehlke ha scritto: > (Option 3: Add a template class that implements Option 2? Is this possible?) "Possible", certainly, I think it's what boost::call_traits::param_type was meant to do. Whether we'd want something like that in our function signatures, that's another matter... Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From jani.heikkinen at qt.io Tue Apr 11 06:07:38 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 11 Apr 2017 04:07:38 +0000 Subject: [Development] [Announce] Qt 5.9 Beta released In-Reply-To: <7b48bb9e-415e-ce94-0f02-a96b792f7f29@gmail.com> References: , <7b48bb9e-415e-ce94-0f02-a96b792f7f29@gmail.com> Message-ID: Hi! Yes, we are targeting to get MSVC2017 binaries in as well but let's see if we can get all ready in time br, Jani ________________________________________ From: Development on behalf of Roland Winklmeier Sent: Monday, April 10, 2017 11:20 PM To: development at qt-project.org Subject: Re: [Development] [Announce] Qt 5.9 Beta released Am 07.04.2017 um 12:33 schrieb List for announcements regarding Qt releases and development: > Hi, > > I am happy to inform Qt 5.9 Beta is released today, see http://blog.qt.io/blog/2017/04/07/qt-5-9-beta-released/. > As informed earlier beta binaries are available only via qt online installer (except QNX package for enterprise users which is still using offline installer & available in qt account) > > br, > Jani Heikkinen > Release Manager Sorry, if this question was answered already, but I couldn't find anything in the docs nor a final statement in the mailing list. Will there be official MSVC 2017 binaries available for the 5.9 release? I thought I read it will be, but there aren't any at the moment for the beta release. Cheers Roland _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Apr 11 07:36:52 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 10 Apr 2017 22:36:52 -0700 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <58EBEA99.5080008@gmail.com> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <58EBEA99.5080008@gmail.com> Message-ID: <2114653.50mnE04kZn@tjmaciei-mobl1> Em segunda-feira, 10 de abril de 2017, às 13:27:05 PDT, Matthew Woehlke escreveu: > Option 2: Teach C++ to choose automatically if such types should be > passed by value or by const-reference. That's what I did to QVector. typedef typename std::conditional::value || std::is_pointer::value, T, const T &>::type parameter_type; value_type value(int i, parameter_type defaultValue) const Q_DECL_NOEXCEPT { return size_t(i) < d->size ? at(i) : defaultValue; } -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Tue Apr 11 07:49:28 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 11 Apr 2017 05:49:28 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <20170313113332.GP19298@troll08> References: <201703011338.47378.marc.mutz@kdab.com> <20170313113332.GP19298@troll08> Message-ID: <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> Hi, With Qt 5.9 beta released last week, I think we should close 5.8 branch now. Closing 5.8 will help getting Qt 5.9 out in time by pushing everything directly into 5.9 branch. This is already the case for most items, but some items are still pushed to 5.8 branch causing the need for continuous merges and delaying getting those fixes to 5.9. Running the merges and submodule updates also causes load to the CI, which is away from doing more frequent runs on 5.9 and dev. There has been a lot of discussion about this in the mailing lists, I think the two ones below sum it up quite well. Yours, Tuukka On 13/03/2017, 13.33, "Development on behalf of Oswald Buddenhagen" wrote: On Wed, Mar 01, 2017 at 01:38:47PM +0100, Marc Mutz wrote: > On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: > > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka > > > proposed. After some thinking I also agree that this is the best > > > course of action from where we are right now. > > > > This also implies that bug fixes should now get pushed to the 5.9 > > branch and we should close the 5.8 branch soon. > > I disagree. Even if you cannot produce releases from 5.8 anymore, > that's our stable branch. > that may be the case, but doesn't necessarily mean that you need to upstream your fixes there. closing it only affects other users of the 5.8 tip who want your fixes. probably not that many. otoh, the branch being open costs CI cycles and causes some forward merging effort, while benefitting a marginal number of people. another point is that most tqtc employees are actually following the management order and are neglecting 5.8 (for two months now), which means that it's by far not as stable as one would want it to be. so i guess it's time to give in and officially close the branch. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development On 01/03/2017, 21.58, "Development on behalf of Thiago Macieira" wrote: Em quarta-feira, 1 de março de 2017, às 04:38:47 PST, Marc Mutz escreveu: > > This also implies that bug fixes should now get pushed to the 5.9 branch > > and we should close the 5.8 branch soon. > > I disagree. Even if you cannot produce releases from 5.8 anymore, that's our > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can > close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? We usually switch the default branch between the beta and the RC, so the point is moot. 5.9 will be considered stable in a couple of weeks, so 5.8 can be closed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Tue Apr 11 09:26:44 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 09:26:44 +0200 Subject: [Development] Passing QSize, QPoint, QTime and other small structs by value In-Reply-To: <2114653.50mnE04kZn@tjmaciei-mobl1> References: <9767315cf8440e193a881c7853f2a228@kdab.com> <58EBEA99.5080008@gmail.com> <2114653.50mnE04kZn@tjmaciei-mobl1> Message-ID: <201704110926.45119.marc.mutz@kdab.com> On Tuesday 11 April 2017 07:36:52 Thiago Macieira wrote: > Em segunda-feira, 10 de abril de 2017, às 13:27:05 PDT, Matthew Woehlke > > escreveu: > > Option 2: Teach C++ to choose automatically if such types should be > > passed by value or by const-reference. > > That's what I did to QVector. > > typedef typename std::conditional::value || > std::is_pointer::value, T, const T &>::type parameter_type; > > value_type value(int i, parameter_type defaultValue) const > Q_DECL_NOEXCEPT { return size_t(i) < d->size ? at(i) : defaultValue; } Boost::call_traits::param_type and the above, however, only work in in non- deduced contexts. Iow: you cannot use it in a hypothetical typename auto sin(boost::call_traits::param_type x); auto sinX = sin(1.0); // ERROR: cannot deduce 'A' (this is another reason why still today one should write function templates as a pair of general template plus op()-in-template-class: you make the general template Q_ALWAYS_INLINE, and can specialize the class template's argument passing any way you like). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Tue Apr 11 09:30:51 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 09:30:51 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> Message-ID: <201704110930.51891.marc.mutz@kdab.com> On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: > There has been a lot of discussion about this in the mailing lists, I think > the two ones below sum it up quite well. They sum up *your* POV well. But up to a few weeks ago, more fixes went into 5.8 QtBase than changes into 5.9, even though TQC personell was asked to ignore 5.8. You can close 5.8 on all other modules, if you wish, but I'd ask to keep it open on QtBase, which has a lively development going on in 5.8 to this day. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Tue Apr 11 10:22:54 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 11 Apr 2017 11:22:54 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704110930.51891.marc.mutz@kdab.com> References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: On 11 April 2017 at 10:30, Marc Mutz wrote: > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: >> There has been a lot of discussion about this in the mailing lists, I think >> the two ones below sum it up quite well. > > They sum up *your* POV well. But up to a few weeks ago, more fixes went into > 5.8 QtBase than changes into 5.9, even though TQC personell was asked to > ignore 5.8. > > You can close 5.8 on all other modules, if you wish, but I'd ask to keep it > open on QtBase, which has a lively development going on in 5.8 to this day. Here's an anecdote: this https://codereview.qt-project.org/#/c/189229/ hasn't been merged to 5.9, as far as I can see. I find it curious that bugfixes from two weeks ago haven't trickled into 5.9 from 5.8 yet. Such matters may well raise the bar for users for working with 5.9 rather than with 5.8. From ville.voutilainen at gmail.com Tue Apr 11 10:34:20 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 11 Apr 2017 11:34:20 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: On 11 April 2017 at 11:22, Ville Voutilainen wrote: > On 11 April 2017 at 10:30, Marc Mutz wrote: >> On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: >>> There has been a lot of discussion about this in the mailing lists, I think >>> the two ones below sum it up quite well. >> >> They sum up *your* POV well. But up to a few weeks ago, more fixes went into >> 5.8 QtBase than changes into 5.9, even though TQC personell was asked to >> ignore 5.8. >> >> You can close 5.8 on all other modules, if you wish, but I'd ask to keep it >> open on QtBase, which has a lively development going on in 5.8 to this day. > > > Here's an anecdote: this https://codereview.qt-project.org/#/c/189229/ > hasn't been merged > to 5.9, as far as I can see. I find it curious that bugfixes from two > weeks ago haven't trickled > into 5.9 from 5.8 yet. Such matters may well raise the bar for users > for working with 5.9 rather than > with 5.8. To elaborate: I run a bleeding-edge compiler. It feels odd to me that the best branch to run it on is a non-bleeding-edge branch, it's quite the opposite. From tuukka.turunen at qt.io Tue Apr 11 10:47:52 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 11 Apr 2017 08:47:52 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: Hi Marc, I can understand your viewpoint, but unfortunately keeping 5.8 open does cause additional load to the systems as well as people. It would be great if you would rather focus into improving Qt 5.9 and making it good for our users than pushing stuff into a branch that has no further releases planned from it. Can you explain why you can not push your Qt Base changes to 5.9 like ~everyone else? Yours, Tuukka On 11/04/2017, 11.34, "Development on behalf of Ville Voutilainen" wrote: On 11 April 2017 at 11:22, Ville Voutilainen wrote: > On 11 April 2017 at 10:30, Marc Mutz wrote: >> On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: >>> There has been a lot of discussion about this in the mailing lists, I think >>> the two ones below sum it up quite well. >> >> They sum up *your* POV well. But up to a few weeks ago, more fixes went into >> 5.8 QtBase than changes into 5.9, even though TQC personell was asked to >> ignore 5.8. >> >> You can close 5.8 on all other modules, if you wish, but I'd ask to keep it >> open on QtBase, which has a lively development going on in 5.8 to this day. > > > Here's an anecdote: this https://codereview.qt-project.org/#/c/189229/ > hasn't been merged > to 5.9, as far as I can see. I find it curious that bugfixes from two > weeks ago haven't trickled > into 5.9 from 5.8 yet. Such matters may well raise the bar for users > for working with 5.9 rather than > with 5.8. To elaborate: I run a bleeding-edge compiler. It feels odd to me that the best branch to run it on is a non-bleeding-edge branch, it's quite the opposite. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From ville.voutilainen at gmail.com Tue Apr 11 10:55:55 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 11 Apr 2017 11:55:55 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: On 11 April 2017 at 11:47, Tuukka Turunen wrote: > > Hi Marc, > > I can understand your viewpoint, but unfortunately keeping 5.8 open does cause additional load to the systems as well as people. It would be great if you would rather focus into improving Qt 5.9 and making it good for our users than pushing stuff into a branch that has no further releases planned from it. > > Can you explain why you can not push your Qt Base changes to 5.9 like ~everyone else? I still hear suggestions along the lines of pushing stuff into 5.8, from which they "eventually get merged into 5.9 and dev". That merging seems to be an occasional manual process, though, so the overall situation is confusing indeed. At any rate, I think it would be wise to do a 5.8->5.9 merge before even considering closing 5.8, lest we lose bugfixes. From Simon.Hausmann at qt.io Tue Apr 11 11:00:22 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Apr 2017 09:00:22 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> , Message-ID: Hi, When closing a branch we'll always do the merge. So closing 5.8 will be followed by a last 5.8 -> 5.9 merge for sure. For qt5.git Liang has already done that, for Simon ________________________________ From: Development on behalf of Ville Voutilainen Sent: Tuesday, April 11, 2017 10:55:55 AM To: Tuukka Turunen Cc: Qt development mailing list Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 On 11 April 2017 at 11:47, Tuukka Turunen wrote: > > Hi Marc, > > I can understand your viewpoint, but unfortunately keeping 5.8 open does cause additional load to the systems as well as people. It would be great if you would rather focus into improving Qt 5.9 and making it good for our users than pushing stuff into a branch that has no further releases planned from it. > > Can you explain why you can not push your Qt Base changes to 5.9 like ~everyone else? I still hear suggestions along the lines of pushing stuff into 5.8, from which they "eventually get merged into 5.9 and dev". That merging seems to be an occasional manual process, though, so the overall situation is confusing indeed. At any rate, I think it would be wise to do a 5.8->5.9 merge before even considering closing 5.8, lest we lose bugfixes. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From cavendish.qi at gmail.com Tue Apr 11 11:08:49 2017 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 11 Apr 2017 11:08:49 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704110930.51891.marc.mutz@kdab.com> References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: On 11 April 2017 at 09:30, Marc Mutz wrote: > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: > > There has been a lot of discussion about this in the mailing lists, I > think > > the two ones below sum it up quite well. > > ...... > > You can close 5.8 on all other modules, if you wish, but I'd ask to keep it > open on QtBase, which has a lively development going on in 5.8 to this day. > Any new change in qtbase means need a new round of qt5.git integration and rebuild all other modules, because they depend on qtbase. Best Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From cavendish.qi at gmail.com Tue Apr 11 11:13:46 2017 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 11 Apr 2017 11:13:46 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: On 11 April 2017 at 10:22, Ville Voutilainen wrote: > On 11 April 2017 at 10:30, Marc Mutz wrote: > > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: > >> There has been a lot of discussion about this in the mailing lists, I > think > >> the two ones below sum it up quite well. > > > > They sum up *your* POV well. But up to a few weeks ago, more fixes went > into > > 5.8 QtBase than changes into 5.9, even though TQC personell was asked to > > ignore 5.8. > > > > You can close 5.8 on all other modules, if you wish, but I'd ask to keep > it > > open on QtBase, which has a lively development going on in 5.8 to this > day. > > > Here's an anecdote: this https://codereview.qt-project.org/#/c/189229/ > hasn't been merged > to 5.9, as far as I can see. I find it curious that bugfixes from two > weeks ago haven't trickled > into 5.9 from 5.8 yet. Such matters may well raise the bar for users > for working with 5.9 rather than > with 5.8. > > You could check which changes in 5.8 are not merged in 5.9 yet: https://gist.github.com/liangqi/afd4dea47e7ee84e017f4113844df5b1 There are only 6 changes in qtdeclarative. Here is the merge for you: https://codereview.qt-project.org/191380 I normally will do merge if more than 10 changes, asked by someone, or just before some releases(like 5.9 rc) and etc. Certainly, there will be merges when 5.8 branch were closed. Don't worry about that. Best Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Apr 11 11:00:29 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 11:00:29 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: Message-ID: <201704111100.29935.marc.mutz@kdab.com> On Tuesday 11 April 2017 10:47:52 Tuukka Turunen wrote: > Can you explain why you can not push your Qt Base changes to 5.9 like > ~everyone else? Because, at least in QtBase, everyone is pushing fixes to 5.8? You saw Thiago's stats. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Tue Apr 11 11:14:59 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 11:14:59 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: Message-ID: <201704111115.00022.marc.mutz@kdab.com> On Tuesday 11 April 2017 10:34:20 Ville Voutilainen wrote: > To elaborate: I run a bleeding-edge compiler. It feels odd to me that > the best branch to run it on > is a non-bleeding-edge branch, it's quite the opposite. I know GCC works differently, probably because you use a RCS that sucks at merging, but the Qt way was, and continues to be, to put (important) bug-fixes (incl. compile-fixes) into the stable branch, and merge them up. This is how Git works best, and apart from LTS, we strongly discourage cherry-picking. The problem at hand is now whether 5.8 continues to be the stable branch, even though no release is planned from it. I say yes, and Tuuka says no. As a compromise, I suggested to keep qtbase's 5.8 open, and close the other module's 5.8 branches. Repeating Thiago's stats from Mar 14th: $ git rev-list --no-merges --since=2.months.ago v5.8.0..origin/5.8 | wc -l 228 $ git rev-list --no-merges --since=2.months.ago origin/5.8..origin/5.9 | wc -l 346 $ git rev-list --no-merges --since=2.months.ago origin/5.9..origin/dev | wc -l 202 So, at this point, 5.9 receives more commits, but 5.8 is far from starved. It receives roughly half the commits 5.9 receives, also at shorter scales: $ git rev-list --no-merges --since=March.14th v5.8.0..origin/5.8 | wc -l 71 $ git rev-list --no-merges --since=March.14th origin/5.8..origin/5.9 | wc -l 156 $ git rev-list --no-merges --since=March.14th origin/5.9..origin/dev | wc -l 131 I see lots of advantages to keeping 5.8 open, but as usual, you will counter them with "CI is overloaded" and that'll be the end of the discussion. In January, TQC promised to increase the CI capacity. It's now three months later and you still use the same argument? This re-inforces the fear that we'll also not have a 5.9.1. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Tue Apr 11 11:18:12 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 11:18:12 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704111115.00022.marc.mutz@kdab.com> References: <201704111115.00022.marc.mutz@kdab.com> Message-ID: <201704111118.12759.marc.mutz@kdab.com> On Tuesday 11 April 2017 11:14:59 Marc Mutz wrote: > I see lots of advantages to keeping 5.8 open, but as usual, you will > counter them with "CI is overloaded" and that'll be the end of the > discussion. In January, TQC promised to increase the CI capacity. It's now > three months later and you still use the same argument? This re-inforces > the fear that we'll also not have a 5.9.1. Sorry, Ville, the 'you' in the above paragraph is not a personal one. It's meant to mean "TQC". -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Simon.Hausmann at qt.io Tue Apr 11 11:29:23 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Apr 2017 09:29:23 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704111115.00022.marc.mutz@kdab.com> References: , <201704111115.00022.marc.mutz@kdab.com> Message-ID: Hi, "In January, TQC promised to increase the CI capacity. It's now three months later and you still use the same argument? " Let's be very clear: The promise for increased capacity was for H1. http://lists.qt-project.org/pipermail/development/2017-February/028757.html We are working on moving to a new data center and purchasing new hardware. The project is scheduled for completion by the end of the first half of the year. It is more or less a binary switch from the Qt perspective, as the current architecture does not really allow us to incrementally grow the running system. Replacing the system is also taking man power. So the argument is valid and we are working on increasing the capacity. Simon ________________________________ From: Development on behalf of Marc Mutz Sent: Tuesday, April 11, 2017 11:14:59 AM To: Qt development mailing list Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 On Tuesday 11 April 2017 10:34:20 Ville Voutilainen wrote: > To elaborate: I run a bleeding-edge compiler. It feels odd to me that > the best branch to run it on > is a non-bleeding-edge branch, it's quite the opposite. I know GCC works differently, probably because you use a RCS that sucks at merging, but the Qt way was, and continues to be, to put (important) bug-fixes (incl. compile-fixes) into the stable branch, and merge them up. This is how Git works best, and apart from LTS, we strongly discourage cherry-picking. The problem at hand is now whether 5.8 continues to be the stable branch, even though no release is planned from it. I say yes, and Tuuka says no. As a compromise, I suggested to keep qtbase's 5.8 open, and close the other module's 5.8 branches. Repeating Thiago's stats from Mar 14th: $ git rev-list --no-merges --since=2.months.ago v5.8.0..origin/5.8 | wc -l 228 $ git rev-list --no-merges --since=2.months.ago origin/5.8..origin/5.9 | wc -l 346 $ git rev-list --no-merges --since=2.months.ago origin/5.9..origin/dev | wc -l 202 So, at this point, 5.9 receives more commits, but 5.8 is far from starved. It receives roughly half the commits 5.9 receives, also at shorter scales: $ git rev-list --no-merges --since=March.14th v5.8.0..origin/5.8 | wc -l 71 $ git rev-list --no-merges --since=March.14th origin/5.8..origin/5.9 | wc -l 156 $ git rev-list --no-merges --since=March.14th origin/5.9..origin/dev | wc -l 131 I see lots of advantages to keeping 5.8 open, but as usual, you will counter them with "CI is overloaded" and that'll be the end of the discussion. In January, TQC promised to increase the CI capacity. It's now three months later and you still use the same argument? This re-inforces the fear that we'll also not have a 5.9.1. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Tue Apr 11 11:32:20 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 11 Apr 2017 09:32:20 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704111100.29935.marc.mutz@kdab.com> References: <201704111100.29935.marc.mutz@kdab.com> Message-ID: Hi, No-one should be pushing to 5.8 any more, but I know that some still do. Closing 5.8 means it is easier to push to the right branch. We have talked this already many times over. Keeping 5.8 open brings little value, but causes load to machines, additional work for people and delay in getting the fixes to users (as it is 5.9 where beta snapshots are created from). For example, on March 1st Lars wrote: “Let’s conclude this topic now by moving on towards 5.9 as Tuukka proposed. After some thinking I also agree that this is the best course of action from where we are right now. This also implies that bug fixes should now get pushed to the 5.9 branch and we should close the 5.8 branch soon.” What I am now saying is that it is now time to do what has been discussed. We have Qt 5.9 beta out and there is constant focus in getting regular snapshots from 5.9. Yours, Tuukka On 11/04/2017, 12.00, "Development on behalf of Marc Mutz" wrote: On Tuesday 11 April 2017 10:47:52 Tuukka Turunen wrote: > Can you explain why you can not push your Qt Base changes to 5.9 like > ~everyone else? Because, at least in QtBase, everyone is pushing fixes to 5.8? You saw Thiago's stats. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Tue Apr 11 11:31:05 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 11:31:05 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <201704110930.51891.marc.mutz@kdab.com> Message-ID: <201704111131.06209.marc.mutz@kdab.com> On Tuesday 11 April 2017 11:08:49 Liang Qi wrote: > On 11 April 2017 at 09:30, Marc Mutz wrote: > > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: > > > There has been a lot of discussion about this in the mailing lists, I > > > > think > > > > > the two ones below sum it up quite well. > > > > ...... > > > > You can close 5.8 on all other modules, if you wish, but I'd ask to keep > > it open on QtBase, which has a lively development going on in 5.8 to > > this day. > > Any new change in qtbase means need a new round of qt5.git integration and > rebuild all other modules, because they depend on qtbase. No, it doesn't (have to) mean that. We usually do not change APIs in a stable branch. A stable branch is forwards and backwards compatible. If we close dependent modules and only keep QtBase open, it follows you cannot commit to dependent modules. In particular, you cannot adapt to changes in 5.8. Which means that we naturally restrict what changes can do into QtBase-5.8. Personally, I never had the need to change something in other modules when commiting something to QtBase-stable. So dependent modules don't need to be rebuilt. They can either run against an updated qtbase binary, or use the old qtbase snapshot for much longer. Something like once a month or so in 5.8 should not load the CI too much. You can schedule it for CET nights. The CI is idle then, anyway. Which brings me to the question: why is a new git5.git integration (for any branch) not attempted each night, automatically? Is the CI doing something else at that time? Shouldn't doing so increase the CI capacity by almost 50%, for free? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From aleixpol at kde.org Tue Apr 11 12:46:39 2017 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 11 Apr 2017 12:46:39 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704110930.51891.marc.mutz@kdab.com> References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: On Tue, Apr 11, 2017 at 9:30 AM, Marc Mutz wrote: > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: >> There has been a lot of discussion about this in the mailing lists, I think >> the two ones below sum it up quite well. > > They sum up *your* POV well. But up to a few weeks ago, more fixes went into > 5.8 QtBase than changes into 5.9, even though TQC personell was asked to > ignore 5.8. > > You can close 5.8 on all other modules, if you wish, but I'd ask to keep it > open on QtBase, which has a lively development going on in 5.8 to this day. What's the point of keeping 5.8 open if there's not going to be another 5.8 release? Aleix From annulen at yandex.ru Tue Apr 11 12:51:51 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 11 Apr 2017 13:51:51 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: <540061491907911@web39g.yandex.ru> 11.04.2017, 11:56, "Ville Voutilainen" : > On 11 April 2017 at 11:47, Tuukka Turunen wrote: >>  Hi Marc, >> >>  I can understand your viewpoint, but unfortunately keeping 5.8 open does cause additional load to the systems as well as people. It would be great if you would rather focus into improving Qt 5.9 and making it good for our users than pushing stuff into a branch that has no further releases planned from it. >> >>  Can you explain why you can not push your Qt Base changes to 5.9 like ~everyone else? > > I still hear suggestions along the lines of pushing stuff into 5.8, > from which they "eventually get merged into 5.9 and dev". That > merging seems to be an occasional manual process, though, so the > overall situation is confusing indeed. Note that you can ask lqi in #qt-labs to perform some particular merge if you need it. > At any rate, I think > it would be wise to do a 5.8->5.9 merge before even considering > closing 5.8, lest we lose bugfixes. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From giuseppe.dangelo at kdab.com Tue Apr 11 13:17:44 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 11 Apr 2017 13:17:44 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: Il 11/04/2017 12:46, Aleix Pol ha scritto: > What's the point of keeping 5.8 open if there's not going to be > another 5.8 release? Because of customer projects, Linux distributions, etc. that are currently on 5.8, and that want to benefit from the latest bug fixes and performance improvements without waiting 4-5 months for 5.9.1. Yes, they *will* skip any .0 release, and convincing customers to upgrade to a new minor release is definitely more complicated than convincing to upgrade to a new patch release (... which in this case translates to tracking the 5.8 branch). Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From tuukka.turunen at qt.io Tue Apr 11 13:36:55 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 11 Apr 2017 11:36:55 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: <7443ACFB-2D6A-4C58-899F-E069E11FA19D@qt.io> Hi, We have discussed this already multiple times and it is well known by everyone. Closing of the branch has been clearly decided, only item open has been the time. Now that we have 5.9 beta released, I think it clearly is the time to close 5.8 and fully focus into making Qt 5.9 good. The sooner we get 5.9.0 out, the sooner we can also get 5.9.1 out. And note that 5.9.0 contains every fix that would have been part of 5.8.1 and more – a lot more. No-one is happy about skipping patch releases for 5.8. This is a trade off done in order to get better Qt releases in the future. Keeping 5.8 branch open and pushing fixes there instead of 5.9 results in worse 5.9 than we could have by focusing to it. Every single merge from 5.8 to 5.9 is time away from people to work on 5.9 (and dev), from machines to be able to work on 5.9 (and dev), and from calendar time of having fixes on the hands of most of the users (i.e. getting them into a release of Qt or pre-releases of Qt). Yours, Tuukka On 11/04/2017, 14.17, "Development on behalf of Giuseppe D'Angelo" wrote: Il 11/04/2017 12:46, Aleix Pol ha scritto: > What's the point of keeping 5.8 open if there's not going to be > another 5.8 release? Because of customer projects, Linux distributions, etc. that are currently on 5.8, and that want to benefit from the latest bug fixes and performance improvements without waiting 4-5 months for 5.9.1. Yes, they *will* skip any .0 release, and convincing customers to upgrade to a new minor release is definitely more complicated than convincing to upgrade to a new patch release (... which in this case translates to tracking the 5.8 branch). Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts From annulen at yandex.ru Tue Apr 11 13:43:47 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 11 Apr 2017 14:43:47 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <7443ACFB-2D6A-4C58-899F-E069E11FA19D@qt.io> References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> <7443ACFB-2D6A-4C58-899F-E069E11FA19D@qt.io> Message-ID: <1004911491911027@web42j.yandex.ru> 11.04.2017, 14:37, "Tuukka Turunen" : > Hi, > > We have discussed this already multiple times and it is well known by everyone. Closing of the branch has been clearly decided, only item open has been the time. Now that we have 5.9 beta released, I think it clearly is the time to close 5.8 and fully focus into making Qt 5.9 good. The sooner we get 5.9.0 out, the sooner we can also get 5.9.1 out. And note that 5.9.0 contains every fix that would have been part of 5.8.1 and more – a lot more. > > No-one is happy about skipping patch releases for 5.8. This is a trade off done in order to get better Qt releases in the future. Keeping 5.8 branch open and pushing fixes there instead of 5.9 results in worse 5.9 than we could have by focusing to it. Every single merge from 5.8 to 5.9 is time away from people to work on 5.9 (and dev), from machines to be able to work on 5.9 (and dev), and from calendar time of having fixes on the hands of most of the users (i.e. getting them into a release of Qt or pre-releases of Qt). Maybe it's plausible to make 5.8.1 release just for QtBase? > > Yours, > >         Tuukka > > On 11/04/2017, 14.17, "Development on behalf of Giuseppe D'Angelo" wrote: > >     Il 11/04/2017 12:46, Aleix Pol ha scritto: >     > What's the point of keeping 5.8 open if there's not going to be >     > another 5.8 release? > >     Because of customer projects, Linux distributions, etc. that are >     currently on 5.8, and that want to benefit from the latest bug fixes and >     performance improvements without waiting 4-5 months for 5.9.1. > >     Yes, they *will* skip any .0 release, and convincing customers to >     upgrade to a new minor release is definitely more complicated than >     convincing to upgrade to a new patch release (... which in this case >     translates to tracking the 5.8 branch). > >     Cheers, >     -- >     Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer >     KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 >     KDAB - Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From ville.voutilainen at gmail.com Tue Apr 11 13:49:01 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 11 Apr 2017 14:49:01 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704111115.00022.marc.mutz@kdab.com> References: <201704111115.00022.marc.mutz@kdab.com> Message-ID: On 11 April 2017 at 12:14, Marc Mutz wrote: > On Tuesday 11 April 2017 10:34:20 Ville Voutilainen wrote: >> To elaborate: I run a bleeding-edge compiler. It feels odd to me that >> the best branch to run it on >> is a non-bleeding-edge branch, it's quite the opposite. > > I know GCC works differently, probably because you use a RCS that sucks at > merging, but the Qt way was, and continues to be, to put (important) bug-fixes > (incl. compile-fixes) into the stable branch, and merge them up. This is how > Git works best, and apart from LTS, we strongly discourage cherry-picking. The > problem at hand is now whether 5.8 continues to be the stable branch, even > though no release is planned from it. Well, the way GCC works may be due to hysterical raisins; today almost all of its developers use git, but it's unlikely that they would change the way they work. Why? Because the way things are done in GCC, trunk always gets every bug fix and also works as the first line of defense against regressions, and the released-branches are less likely to break, because not everything under the sun is pushed there. That sort of a model makes perfect sense to me (and I claim that's not just because I'm used to it, I say it *makes sense*), whereas the Qt model gets some getting used to. You say we discourage cherry-picking. Why? Is that not a fairly natural way to backport bugfixes from a bleeding-edge branch to a stabler branch? From tuukka.turunen at qt.io Tue Apr 11 13:52:36 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 11 Apr 2017 11:52:36 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1004911491911027@web42j.yandex.ru> References: <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> <7443ACFB-2D6A-4C58-899F-E069E11FA19D@qt.io> <1004911491911027@web42j.yandex.ru> Message-ID: <44D5DD41-5DD3-4B18-AE95-DA84623F5FF5@qt.io> > On 11/04/2017, 14.43, "Konstantin Tokarev" wrote: > > Maybe it's plausible to make 5.8.1 release just for QtBase? No. That is not possible. This has also been discussed before. There is still a lot of work left to do for getting Qt 5.9 ready. That is what we should focus into as that is what benefits Qt the best overall. We need to provide a solid release that receives multiple patch releases. Yours, Tuukka From marc.mutz at kdab.com Tue Apr 11 14:16:08 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 14:16:08 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <201704111115.00022.marc.mutz@kdab.com> Message-ID: <201704111416.09405.marc.mutz@kdab.com> On Tuesday 11 April 2017 13:49:01 Ville Voutilainen wrote: > You say we discourage cherry-picking. Why? Is that not a fairly > natural way to backport > bugfixes from a bleeding-edge branch to a stabler branch? Afaict, it's because it's against the workflow of the RCS. Are you proposing a everything-to-dev-cherry-pick-into-older-branches-only model? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Tue Apr 11 14:25:21 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Apr 2017 14:25:21 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <44D5DD41-5DD3-4B18-AE95-DA84623F5FF5@qt.io> References: <1004911491911027@web42j.yandex.ru> <44D5DD41-5DD3-4B18-AE95-DA84623F5FF5@qt.io> Message-ID: <201704111425.21999.marc.mutz@kdab.com> On Tuesday 11 April 2017 13:52:36 Tuukka Turunen wrote: > > On 11/04/2017, 14.43, "Konstantin Tokarev" wrote: > > Maybe it's plausible to make 5.8.1 release just for QtBase? > > No. That is not possible. This has also been discussed before. Yes, it is possible, you've done it before. And no, it has not been "discussed". I raised the question, and no-one answered. Why this semblance of a discussion, anyway? Why don't you just go ahead and pull the plug on 5.8? It's not like the Qt Project (or what's left of it) has any say in this, you made that abundantly clear in the past. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Tue Apr 11 14:45:41 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 11 Apr 2017 15:45:41 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704111416.09405.marc.mutz@kdab.com> References: <201704111115.00022.marc.mutz@kdab.com> <201704111416.09405.marc.mutz@kdab.com> Message-ID: On 11 April 2017 at 15:16, Marc Mutz wrote: > On Tuesday 11 April 2017 13:49:01 Ville Voutilainen wrote: >> You say we discourage cherry-picking. Why? Is that not a fairly >> natural way to backport >> bugfixes from a bleeding-edge branch to a stabler branch? > > Afaict, it's because it's against the workflow of the RCS. So, we think it's better to forward-merge everything from stable to dev, rather than cherry-pick from dev to stable? > Are you proposing a everything-to-dev-cherry-pick-into-older-branches-only > model? I'm not proposing it yet, but such models seem plenty attractive to me. From annulen at yandex.ru Tue Apr 11 14:57:13 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 11 Apr 2017 15:57:13 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <201704111115.00022.marc.mutz@kdab.com> <201704111416.09405.marc.mutz@kdab.com> Message-ID: <1651681491915433@web19g.yandex.ru> 11.04.2017, 15:45, "Ville Voutilainen" : > On 11 April 2017 at 15:16, Marc Mutz wrote: >>  On Tuesday 11 April 2017 13:49:01 Ville Voutilainen wrote: >>>  You say we discourage cherry-picking. Why? Is that not a fairly >>>  natural way to backport >>>  bugfixes from a bleeding-edge branch to a stabler branch? >> >>  Afaict, it's because it's against the workflow of the RCS. > > So, we think it's better to forward-merge everything from stable to > dev, rather than > cherry-pick from dev to stable? In git cherry-picking results in duplication of commits between branches, that have similar content but different hashes. Also, in case of conflicts merge can result in way less work than cherry-picking, as in O(N) vs O(1) > >>  Are you proposing a everything-to-dev-cherry-pick-into-older-branches-only >>  model? > > I'm not proposing it yet, but such models seem plenty attractive to me. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From bstottle at ford.com Tue Apr 11 15:09:34 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Tue, 11 Apr 2017 13:09:34 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 Message-ID: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> > On 4/11/17, 7:36 AM, "Development on behalf of Tuukka Turunen" wrote: > every fix that would have been part of 5.8.1 and more – a lot more. The reason for pushing to the 5.8 branch is because it *is* stable. And since it has "... a lot more", the 5.9 branch is not stable. Whether The Qt Company will generate any packaged versions on the 5.8 branch after the 5.8.0 release is really not the point, is it? For those that are building from source and who have requirements for stability vs. new features, doesn't there need to be a stable HEAD to push to? If the 5.8 branch is closed, those developers will be forced to move to 5.9 beta, or be required to find, cherry-pick and validate commits onto 5.8 themselves, right? Leaving the branch open, with CI runs on changes, seems like the only way to keep a known stable HEAD available until the known stable HEAD is on the 5.9 branch. Regards, Brett From Kai.Koehne at qt.io Tue Apr 11 15:42:26 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 11 Apr 2017 13:42:26 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704111425.21999.marc.mutz@kdab.com> References: <1004911491911027@web42j.yandex.ru> <44D5DD41-5DD3-4B18-AE95-DA84623F5FF5@qt.io> <201704111425.21999.marc.mutz@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Marc Mutz > Sent: Tuesday, April 11, 2017 2:25 PM > To: development at qt-project.org > Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch > releases during H1/17 > > On Tuesday 11 April 2017 13:52:36 Tuukka Turunen wrote: > > > On 11/04/2017, 14.43, "Konstantin Tokarev" > wrote: > > > Maybe it's plausible to make 5.8.1 release just for QtBase? > > > > No. That is not possible. This has also been discussed before. > > Yes, it is possible, you've done it before. And no, it has not been "discussed". > I raised the question, and no-one answered. When did we ever do a release of qtbase, without any other modules? > Why this semblance of a discussion, anyway? Why don't you just go ahead > and pull the plug on 5.8? Because _you_ started the discussion again. Tuukka just suggested to execute the decision we've made weeks ago now. > It's not like the Qt Project (or what's left of it) has > any say in this, you made that abundantly clear in the past. Lars as Chief Maintainer sent out a mail about this, so this is the official stance of the Qt Project on this. Seriously, can we please move on? This is in no way productive. Kai From tuukka.turunen at qt.io Tue Apr 11 15:48:32 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 11 Apr 2017 13:48:32 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> Message-ID: <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io> > On 11/04/2017, 16.09, "Stottlemyer, Brett (B.S.)" wrote: > > > On 4/11/17, 7:36 AM, "Development on behalf of Tuukka Turunen" wrote: > > every fix that would have been part of 5.8.1 and more – a lot more. > > The reason for pushing to the 5.8 branch is because it *is* stable. And since it has "... a lot more", the 5.9 branch is not stable. I was actually not referring to features, but the fact that quite a lot of bug fixes have been pushed to 5.9 and these are not present in 5.8 branch. > Whether The Qt Company will generate any packaged versions on the 5.8 branch after > the 5.8.0 release is really not the point, is it? > For those that are building from source and who have requirements for stability vs. new features, doesn't there need to be a stable HEAD to push to? If the 5.8 branch is closed, those developers will be forced to move > to 5.9 beta, or be required to find, cherry-pick and validate commits onto 5.8 themselves, right? Leaving the branch open, with CI runs on changes, seems like the only way to keep a known stable HEAD available until > the known stable HEAD is on the 5.9 branch. The problem with pushing some fixes to 5.8 is that we need to do merges up (which need effort from people, machine cycles and calendar time). This is the penalty we take when there are patch releases coming from the stable branch. It is a major impact to the next release. Now that there are no patch releases planned, the benefit from pushing to 5.8 then merging to 5.9 does not exist. That is the key point – we need to create a stable base for users, catch up with lost time due to 5.8 delay, and to be able to implement a major change in CI so that we can make patch releases easier in the future. So this is not about changing the approach in general – just a temporary action to be able to reach the abovementioned goals. Yours, Tuukka From bstottle at ford.com Tue Apr 11 16:58:55 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Tue, 11 Apr 2017 14:58:55 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io> Message-ID: > On 4/11/17, 9:49 AM, "Development on behalf of Tuukka Turunen" wrote: > Now that there are no patch releases planned, the benefit from pushing to 5.8 then merging to 5.9 does not exist. I feel there should always be a stable HEAD that you can push a fix to and expect to be able retrieve and do a rebuild with that fix. Is that unreasonable? Right now, the only branch that meets that criteria is 5.8, so I disagree there is no benefit to it. Whether it is worth the effort is a different question. I'm simply trying to make the point that the value doesn't go to zero because there isn't another planned release from that branch. Regards, Brett From Simon.Hausmann at qt.io Tue Apr 11 17:13:42 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Apr 2017 15:13:42 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io>, Message-ID: <7E68DBDC-3E0D-4B2C-8822-C8723AA37605@qt.io> Hi, I think that what you are asking for is reasonable. I think the set of sha1s of qt5.git satisfy that requirement to the best of the project's ability. Why would the tip of the 5.8 branch of all modules be superior to for example the sha1s of qt5's 5.9 branch at this point? For users of the product we can only point to tags. For developers all active branches should be good enough. I find it hard to imagine introducing a third "level" that is good enough for "some" but clearly not all. Unless there is a consensus to define and introduce this new way of identifying a development branch. Simon On 11. Apr 2017, at 16:59, Stottlemyer, Brett (B.S.) wrote: >> On 4/11/17, 9:49 AM, "Development on behalf of Tuukka Turunen" wrote: >> Now that there are no patch releases planned, the benefit from pushing to 5.8 then merging to 5.9 does not exist. > > I feel there should always be a stable HEAD that you can push a fix to and expect to be able retrieve and do a rebuild with that fix. Is that unreasonable? > > Right now, the only branch that meets that criteria is 5.8, so I disagree there is no benefit to it. > > Whether it is worth the effort is a different question. I'm simply trying to make the point that the value doesn't go to zero because there isn't another planned release from that branch. > > Regards, > Brett > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Apr 11 17:36:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 11 Apr 2017 08:36:20 -0700 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201704110930.51891.marc.mutz@kdab.com> References: <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> <201704110930.51891.marc.mutz@kdab.com> Message-ID: <2590143.eEXPxr9O43@tjmaciei-mobl1> Em terça-feira, 11 de abril de 2017, às 00:30:51 PDT, Marc Mutz escreveu: > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: > > There has been a lot of discussion about this in the mailing lists, I > > think > > the two ones below sum it up quite well. > > They sum up *your* POV well. But up to a few weeks ago, more fixes went into > 5.8 QtBase than changes into 5.9, even though TQC personell was asked to > ignore 5.8. > > You can close 5.8 on all other modules, if you wish, but I'd ask to keep it > open on QtBase, which has a lively development going on in 5.8 to this day. While I agree that not releasing 5.8.1 was a big mistake, leaving 5.8 open serves no purpose. Let's close it and focus on getting 5.9 out ASAP. And not make the same mistake for the 5.10 timeframe. Anecdote from IRC last night: 23:10 < engys> Isn't that easy to get a nice qt build done from git this days. Released Qt 5.8.0 version had a MySQL utf8 Bug that should be fixed with 5.8.1 -> https://bugreports.qt.io/browse/QTBUG-591 but there is no 5.8.1 because Qt directly go to 5.9 23:13 < engys> Then this qmake dummy.cpp under mkspecs in Qt 5.8 that take place in every project. Is this dummy.cpp also in 5.9? 23:22 < engys> So there is no official bugfree 5.8 binary out there because they are from 2017-01-20 and the MySQL patchset is from 2017-02-27 23:23 < engys> Qt 5.7 was a much nicer release! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bstottle at ford.com Tue Apr 11 18:16:32 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Tue, 11 Apr 2017 16:16:32 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <7E68DBDC-3E0D-4B2C-8822-C8723AA37605@qt.io> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io>, <7E68DBDC-3E0D-4B2C-8822-C8723AA37605@qt.io> Message-ID: <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> On Tuesday, April 11, 2017 11:14 AM, Simon Hausmann wrote: > I think that what you are asking for is reasonable. I think the set of sha1s of qt5.git satisfy that requirement to the best of the project's ability. In this case I think they do not, based on all of the commits to the 5.8 branches that aren't included in the v5.8.0 tag (last available). If those were to be included in a 5.8.1 release, I would agree with you. > Why would the tip of the 5.8 branch of all modules be superior to for example the sha1s of qt5's 5.9 branch at this point? Are you saying 5.9 Beta is more stable than the HEAD of the 5.8 branches? At some point the 5.9 branches will be more stable, but I don't see any reason to believe it is true now. > For users of the product we can only point to tags. For developers all active branches should be good enough. I > find it hard to imagine introducing a third "level" that is good enough for "some" but clearly not all. Unless there > is a consensus to define and introduce this new way of identifying a development branch. Right, but doesn't that imply keeping 5.8 active until 5.9 is at least as stable? How is it "a new way"? Brett From Simon.Hausmann at qt.io Tue Apr 11 18:27:15 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Apr 2017 16:27:15 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io>, <7E68DBDC-3E0D-4B2C-8822-C8723AA37605@qt.io>, <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> Message-ID: <40192F88-36DB-4D2E-A493-EAB87BD496E5@qt.io> Hi, How do you define "stable"? The best criteria I have to offer at this point is a pass of all tests of all modules in a combination. That is a qt5 build and that is why it is - by the metric of test failures - more stable at the untested combination of branch tips of the modules. That is the criteria for developers of Qt. For the users of Qt only tags go further, because they come after release test automation- an additional step of QA. Simon > On 11. Apr 2017, at 18:16, Stottlemyer, Brett (B.S.) wrote: > >> On Tuesday, April 11, 2017 11:14 AM, Simon Hausmann wrote: >> I think that what you are asking for is reasonable. I think the set of sha1s of qt5.git satisfy that requirement to the best of the project's ability. > > In this case I think they do not, based on all of the commits to the 5.8 branches that aren't included in the v5.8.0 tag (last available). If those were to be included in a 5.8.1 release, I would agree with you. > >> Why would the tip of the 5.8 branch of all modules be superior to for example the sha1s of qt5's 5.9 branch at this point? > > Are you saying 5.9 Beta is more stable than the HEAD of the 5.8 branches? At some point the 5.9 branches will be more stable, but I don't see any reason to believe it is true now. > >> For users of the product we can only point to tags. For developers all active branches should be good enough. I >> find it hard to imagine introducing a third "level" that is good enough for "some" but clearly not all. Unless there >> is a consensus to define and introduce this new way of identifying a development branch. > > Right, but doesn't that imply keeping 5.8 active until 5.9 is at least as stable? How is it "a new way"? > > Brett > From robin.burchell at crimson.no Tue Apr 11 18:43:28 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Tue, 11 Apr 2017 18:43:28 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <7E68DBDC-3E0D-4B2C-8822-C8723AA37605@qt.io> <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> Message-ID: <1491929008.3852327.941468248.39325613@webmail.messagingengine.com> On Tue, Apr 11, 2017, at 06:16 PM, Stottlemyer, Brett (B.S.) wrote: > On Tuesday, April 11, 2017 11:14 AM, Simon Hausmann wrote: > > I think that what you are asking for is reasonable. I think the set of sha1s of qt5.git satisfy that requirement to the best of the project's ability. > > In this case I think they do not, based on all of the commits to the 5.8 > branches that aren't included in the v5.8.0 tag (last available). If > those were to be included in a 5.8.1 release, I would agree with you. qt5's 5.9 branch will contain a known-good configuration that built and passed tests for everything in it that the 5.9 branch of each individual repository won't offer you. I think you misunderstood this - I think that Simon was saying that the branches (not the tags) of qt5.git should be considered to be fairly stable for the people working on Qt itself (although obviously, qt5/dev will be more bleeding-edge than qt5/). > > For users of the product we can only point to tags. For developers all active branches should be good enough. I > > find it hard to imagine introducing a third "level" that is good enough for "some" but clearly not all. Unless there > > is a consensus to define and introduce this new way of identifying a development branch. > > Right, but doesn't that imply keeping 5.8 active until 5.9 is at least as > stable? How is it "a new way"? We have three targets: dev, the stable branch (more or less 5.9, since 5.8.1 is DOA) and the LTS (5.6). Adding an additional "level" there as you seem to be proposing with a "more-stable-than-stable" would be something I would consider new. -- Robin Burchell robin at crimson.no From thiago.macieira at intel.com Tue Apr 11 19:47:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 11 Apr 2017 10:47:26 -0700 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <40192F88-36DB-4D2E-A493-EAB87BD496E5@qt.io> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> <40192F88-36DB-4D2E-A493-EAB87BD496E5@qt.io> Message-ID: <6519475.jgpAaFCuBv@tjmaciei-mobl1> Em terça-feira, 11 de abril de 2017, às 09:27:15 PDT, Simon Hausmann escreveu: > The best criteria I have to offer at this point is a pass of all tests of > all modules in a combination. That is a qt5 build and that is why it is - > by the metric of test failures - more stable at the untested combination of > branch tips of the modules. Well, there is one more criterion: the release testing. Qt 5.8 has passed through that stage, 5.9 has not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue Apr 11 19:49:41 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Apr 2017 17:49:41 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <6519475.jgpAaFCuBv@tjmaciei-mobl1> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> <40192F88-36DB-4D2E-A493-EAB87BD496E5@qt.io>, <6519475.jgpAaFCuBv@tjmaciei-mobl1> Message-ID: Hi, The 5.9 beta has passed at least RTA. The 5.8.0 tag has as well as public release testing, the 5.8 branch has passed none of it. Simon > On 11. Apr 2017, at 19:47, Thiago Macieira wrote: > >> Em terça-feira, 11 de abril de 2017, às 09:27:15 PDT, Simon Hausmann escreveu: >> The best criteria I have to offer at this point is a pass of all tests of >> all modules in a combination. That is a qt5 build and that is why it is - >> by the metric of test failures - more stable at the untested combination of >> branch tips of the modules. > > Well, there is one more criterion: the release testing. Qt 5.8 has passed > through that stage, 5.9 has not. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From bstottle at ford.com Tue Apr 11 20:11:48 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Tue, 11 Apr 2017 18:11:48 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1491929008.3852327.941468248.39325613@webmail.messagingengine.com> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <7E68DBDC-3E0D-4B2C-8822-C8723AA37605@qt.io> <21a77d97793d4c1f83e677ffe43c63e2@nafcmb35.exchange.ford.com> <1491929008.3852327.941468248.39325613@webmail.messagingengine.com> Message-ID: <5fb1b81b5ae54ea9a10d088219329bcc@nafcmb35.exchange.ford.com> On Tuesday, April 11, 2017 12:27 PM, Simon Hausmann wrote: > How do you define "stable"? I appreciate the value of CI, including the value of CI against the entire set of modules, not just the modules in isolation. At the same time, another important measure of stability is "burn-in", i.e., getting time running something and gaining confidence it won't break. Under a broad set of use-cases, not just what is covered by CI. The commits to 5.8, without the addition of new features, give a sense of burned-in stability. I don't have that confidence in 5.9, particularly when it is in beta status. On Tuesday, April 11, 2017 12:43 PM, Robin Burchell wrote: > We have three targets: dev, the stable branch (more or less 5.9, since 5.8.1 is DOA) and the LTS (5.6). Adding an additional > "level" there as you seem to be proposing with a "more-stable-than-stable" would be something I would consider new. Well said, thanks. I guess it boils down to whether you think 5.9 is stable or not. I guess you can tell how I feel about it ;-) I still see value in being able to push/pull a fix without having to pull in the new 5.9 features with it. For the people on this ML. Regards, Brett -----Original Message----- From: Development [mailto:development-bounces+bstottle=ford.com at qt-project.org] On Behalf Of Robin Burchell Sent: Tuesday, April 11, 2017 12:43 PM To: development at qt-project.org Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 On Tue, Apr 11, 2017, at 06:16 PM, Stottlemyer, Brett (B.S.) wrote: > On Tuesday, April 11, 2017 11:14 AM, Simon Hausmann wrote: > > I think that what you are asking for is reasonable. I think the set of sha1s of qt5.git satisfy that requirement to the best of the project's ability. > > In this case I think they do not, based on all of the commits to the > 5.8 branches that aren't included in the v5.8.0 tag (last available). > If those were to be included in a 5.8.1 release, I would agree with you. qt5's 5.9 branch will contain a known-good configuration that built and passed tests for everything in it that the 5.9 branch of each individual repository won't offer you. I think you misunderstood this - I think that Simon was saying that the branches (not the tags) of qt5.git should be considered to be fairly stable for the people working on Qt itself (although obviously, qt5/dev will be more bleeding-edge than qt5/). > > For users of the product we can only point to tags. For developers > > all active branches should be good enough. I find it hard to imagine > > introducing a third "level" that is good enough for "some" but clearly not all. Unless there is a consensus to define and introduce this new way of identifying a development branch. > > Right, but doesn't that imply keeping 5.8 active until 5.9 is at least > as stable? How is it "a new way"? We have three targets: dev, the stable branch (more or less 5.9, since 5.8.1 is DOA) and the LTS (5.6). Adding an additional "level" there as you seem to be proposing with a "more-stable-than-stable" would be something I would consider new. -- Robin Burchell robin at crimson.no _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Apr 11 21:37:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 11 Apr 2017 12:37:40 -0700 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <6519475.jgpAaFCuBv@tjmaciei-mobl1> Message-ID: <1746948.8kIbBxfVfR@tjmaciei-mobl1> On terça-feira, 11 de abril de 2017 10:49:41 PDT Simon Hausmann wrote: > Hi, > > The 5.9 beta has passed at least RTA. The 5.8.0 tag has as well as public > release testing, the 5.8 branch has passed none of it. True, but the 5.8 branch only has bugfixes on top of a released tag, whereas the 5.9 branch has new features and bugfixes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue Apr 11 21:58:28 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Apr 2017 19:58:28 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1746948.8kIbBxfVfR@tjmaciei-mobl1> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <6519475.jgpAaFCuBv@tjmaciei-mobl1> , <1746948.8kIbBxfVfR@tjmaciei-mobl1> Message-ID: <118A1FA7-E45C-49D2-AF3C-D4B1CB188D2C@qt.io> Hi, You're right. I think to the users that want to try out a development branch that is an important difference. I hope to the developers of Qt it is not something that prevents them from developing though - the context being whether the question which branch to use as basis for development. Simon > On 11. Apr 2017, at 21:37, Thiago Macieira wrote: > >> On terça-feira, 11 de abril de 2017 10:49:41 PDT Simon Hausmann wrote: >> Hi, >> >> The 5.9 beta has passed at least RTA. The 5.8.0 tag has as well as public >> release testing, the 5.8 branch has passed none of it. > > True, but the 5.8 branch only has bugfixes on top of a released tag, whereas > the 5.9 branch has new features and bugfixes. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Wed Apr 12 09:23:53 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 12 Apr 2017 07:23:53 +0000 Subject: [Development] Qt Beta Tags in Jira Message-ID: Hi, Since we are using rolling Beta releases I took the liberty of creating numbered Beta release version tags in the Jira Qt Project. Please use the most appropriate version tag. Most likely the next unreleased Beta tag is the right one of choice. -- Alex From giuseppe.dangelo at kdab.com Thu Apr 13 00:11:48 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 13 Apr 2017 00:11:48 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io> References: <95275ce4955b4243b51f713ba5d143df@nafcmb35.exchange.ford.com> <74D59E53-50ED-4D6E-9853-6444C5672F4D@qt.io> Message-ID: <20cf987e-0991-7e35-3c9f-e4439f6de708@kdab.com> Il 11/04/2017 15:48, Tuukka Turunen ha scritto: >> The reason for pushing to the 5.8 branch is because it *is* stable. And since it has "... a lot more", the 5.9 branch is not stable. > I was actually not referring to features, but the fact that quite a lot of bug fixes have been pushed to 5.9 and these are not present in 5.8 branch. Just so that this is not overlooked: such fixes were pushed, approved and merged against the Qt Project Commit Policy. Anyhow, I think we'll have to agree to disagree, let's close 5.8, focus on the 5.9 release and move on. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From randy.oreilly at colorado.edu Thu Apr 13 07:24:39 2017 From: randy.oreilly at colorado.edu (Randall O'Reilly) Date: Thu, 13 Apr 2017 14:24:39 +0900 Subject: [Development] As Qt contemplates its future.. Message-ID: In the context of all this recent discussion about modernizing Qt to accommodate updates to C++, has anyone given any thought to the radical idea of creating a brand new product using Go? Go (golang) is rapidly gaining in popularity, and seems to embody everything that is great about Qt (simplicity, elegance, strong concern for readability, etc), and it has many features of Qt built directly into the language (reflection, i.e., moc, goroutines and channels for signal / slot functionality). One of its main limitations is lack of a dominant, fully-featured GUI toolkit. There are existing bindings to Qt and QML, but it seems like creating a brand new native GUI framework in the Qt mold could be a great opportunity to make a huge impact on a language that has a bright future. All the lessons learned as Qt has evolved over the years could be consolidated into a fresh new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / Vulkan, etc) as the underlying renderer, or something like that… Obviously a huge undertaking, but something that could produce transformative effects for future programmers (whereas it seems that continued improvements to the C++ product are likely to be much more incremental). Maybe some funding from Google could be obtained to support such an endeavor? - Randy From annulen at yandex.ru Thu Apr 13 09:25:37 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 13 Apr 2017 10:25:37 +0300 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: Message-ID: <1958601492068337@web29o.yandex.ru> 13.04.2017, 08:25, "Randall O'Reilly" : > In the context of all this recent discussion about modernizing Qt to accommodate updates to C++, has anyone given any thought to the radical idea of creating a brand new product using Go? Go (golang) is rapidly gaining in popularity, and seems to embody everything that is great about Qt (simplicity, elegance, strong concern for readability, etc), and it has many features of Qt built directly into the language (reflection, i.e., moc, goroutines and channels for signal / slot functionality). One of its main limitations is lack of a dominant, fully-featured GUI toolkit. There are existing bindings to Qt and QML, but it seems like creating a brand new native GUI framework in the Qt mold could be a great opportunity to make a huge impact on a language that has a bright future. All the lessons learned as Qt has evolved over the years could be consolidated into a fresh new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / Vulkan, etc) as the underlying renderer, or something like that… Obviously a huge undertaking, but something that could produce transformative effects for future programmers (whereas it seems that continued improvements to the C++ product are likely to be much more incremental). Maybe some funding from Google could be obtained to support such an endeavor? I think binding like this may work for you: https://github.com/therecipe/qt > > - Randy > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From krnekit at gmail.com Thu Apr 13 11:31:44 2017 From: krnekit at gmail.com (Nikita Krupenko) Date: Thu, 13 Apr 2017 12:31:44 +0300 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: Message-ID: <2257337.m0j1eRqRdy@localhost.localdomain> On четверг, 13 апреля 2017 г. 08:24:39 EEST Randall O'Reilly wrote: > In the context of all this recent discussion about modernizing Qt to > accommodate updates to C++, has anyone given any thought to the radical > idea of creating a brand new product using Go? Go (golang) is rapidly > gaining in popularity, and seems to embody everything that is great about > Qt (simplicity, elegance, strong concern for readability, etc), and it has > many features of Qt built directly into the language (reflection, i.e., > moc, goroutines and channels for signal / slot functionality). One of its > main limitations is lack of a dominant, fully-featured GUI toolkit. There > are existing bindings to Qt and QML, but it seems like creating a brand new > native GUI framework in the Qt mold could be a great opportunity to make a > huge impact on a language that has a bright future. All the lessons > learned as Qt has evolved over the years could be consolidated into a fresh > new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / > Vulkan, etc) as the underlying renderer, or something like that… Obviously > a huge undertaking, but something that could produce transformative effects > for future programmers (whereas it seems that continued improvements to the > C++ product are likely to be much more incremental). Maybe some funding > from Google could be obtained to support such an endeavor? > > - Randy Why Go? Isn't Rust more close to the C++ niche? From annulen at yandex.ru Thu Apr 13 12:24:46 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 13 Apr 2017 13:24:46 +0300 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <2257337.m0j1eRqRdy@localhost.localdomain> References: <2257337.m0j1eRqRdy@localhost.localdomain> Message-ID: <209381492079086@web53g.yandex.ru> 13.04.2017, 12:32, "Nikita Krupenko" : > On четверг, 13 апреля 2017 г. 08:24:39 EEST Randall O'Reilly wrote: >>  In the context of all this recent discussion about modernizing Qt to >>  accommodate updates to C++, has anyone given any thought to the radical >>  idea of creating a brand new product using Go? Go (golang) is rapidly >>  gaining in popularity, and seems to embody everything that is great about >>  Qt (simplicity, elegance, strong concern for readability, etc), and it has >>  many features of Qt built directly into the language (reflection, i.e., >>  moc, goroutines and channels for signal / slot functionality). One of its >>  main limitations is lack of a dominant, fully-featured GUI toolkit. There >>  are existing bindings to Qt and QML, but it seems like creating a brand new >>  native GUI framework in the Qt mold could be a great opportunity to make a >>  huge impact on a language that has a bright future. All the lessons >>  learned as Qt has evolved over the years could be consolidated into a fresh >>  new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / >>  Vulkan, etc) as the underlying renderer, or something like that… Obviously >>  a huge undertaking, but something that could produce transformative effects >>  for future programmers (whereas it seems that continued improvements to the >>  C++ product are likely to be much more incremental). Maybe some funding >>  from Google could be obtained to support such an endeavor? >> >>  - Randy > > Why Go? Isn't Rust more close to the C++ niche? Rust does not have even GCC frontend, so is even less portable than C++ > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Thu Apr 13 12:25:39 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 13 Apr 2017 13:25:39 +0300 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <209381492079086@web53g.yandex.ru> References: <2257337.m0j1eRqRdy@localhost.localdomain> <209381492079086@web53g.yandex.ru> Message-ID: <214901492079139@web53g.yandex.ru> 13.04.2017, 13:25, "Konstantin Tokarev" : > 13.04.2017, 12:32, "Nikita Krupenko" : >>  On четверг, 13 апреля 2017 г. 08:24:39 EEST Randall O'Reilly wrote: >>>   In the context of all this recent discussion about modernizing Qt to >>>   accommodate updates to C++, has anyone given any thought to the radical >>>   idea of creating a brand new product using Go? Go (golang) is rapidly >>>   gaining in popularity, and seems to embody everything that is great about >>>   Qt (simplicity, elegance, strong concern for readability, etc), and it has >>>   many features of Qt built directly into the language (reflection, i.e., >>>   moc, goroutines and channels for signal / slot functionality). One of its >>>   main limitations is lack of a dominant, fully-featured GUI toolkit. There >>>   are existing bindings to Qt and QML, but it seems like creating a brand new >>>   native GUI framework in the Qt mold could be a great opportunity to make a >>>   huge impact on a language that has a bright future. All the lessons >>>   learned as Qt has evolved over the years could be consolidated into a fresh >>>   new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / >>>   Vulkan, etc) as the underlying renderer, or something like that… Obviously >>>   a huge undertaking, but something that could produce transformative effects >>>   for future programmers (whereas it seems that continued improvements to the >>>   C++ product are likely to be much more incremental). Maybe some funding >>>   from Google could be obtained to support such an endeavor? >>> >>>   - Randy >> >>  Why Go? Isn't Rust more close to the C++ niche? > > Rust does not have even GCC frontend, so is even less portable than C++ Ooops, I meant "than Go" > >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From jani.heikkinen at qt.io Thu Apr 13 13:48:06 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 13 Apr 2017 11:48:06 +0000 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: <1643490.9zMfjAF2Up@tjmaciei-mobl1> References: <1643490.9zMfjAF2Up@tjmaciei-mobl1> Message-ID: After short internal discussion here is my proposal for those patch level releases: - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3 release target August 2017 - Branch '5.9.1' from '5.9' at the end of July/beginning of August, 5.9.1 release target September 2017 - Branch '5.9.2' from '5.9' Nov 2017 - Branch '5.6.4' from '5.6' Jan 2018 br, Jani > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Thiago Macieira > Sent: maanantaina 10. huhtikuuta 2017 18.46 > To: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Qt 5.10 schedule proposal > > Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen > escreveu: > > Hi, > > > > Qt 5.9 is proceeding quite well and it is time to start planning Qt > > 5.10 schedule. We want to to release 5.10 before Christmas so we need > > to have Qt > > 5.10 FF at the beginning of August. I propose following initial > > schedule for Qt 5.10: > > > > - Qt 5.10 Feature Freeze: 8.8.2017 > > - Qt 5.10 Alpha Release: 31.8.2017 > > - First Qt 5.10 Beta Release 5.10.2017 > > - Qt 5.10 RC 16.11.2017 > > - Qt 5.10 final release 30.11.2017 > > Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we have > an idea of how much work it will be? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From randy.oreilly at colorado.edu Thu Apr 13 14:02:59 2017 From: randy.oreilly at colorado.edu (Randall O'Reilly) Date: Thu, 13 Apr 2017 21:02:59 +0900 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <214901492079139@web53g.yandex.ru> References: <2257337.m0j1eRqRdy@localhost.localdomain> <209381492079086@web53g.yandex.ru> <214901492079139@web53g.yandex.ru> Message-ID: With the recent language explosion, there are now languages to fit everyone’s biases and aesthetics. This also means that there is an endless potential for language wars, which I’m sure nobody wants to rehash on this list. My point is just that Go represents a particular set of choices that I think is very compatible with a certain (possibly large) segment of the Qt user-base — those who favor clarity, simplicity, readability, over e.g., extreme performance optimization or having every different kind of possible language feature at one’s disposal (aka “language bloat”). As C++ is seemingly in a constant state of reinvention lately, and is now massively bloated and unwieldy in some people’s estimation, it might be an opportune moment to consider a “reboot” — a fresh new framework unburdened by all that cruft. My sense is that Go has made some really excellent (and hard) choices that benefit from all the different language experiments and experience (and especially the limitations of C++), and that one major thing holding it back is lack of a decent GUI framework, so that Qt could really make a big difference there. Furthermore, Qt itself has a kind of bloat problem of its own, having evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now 3D), so it could possibly benefit from a fresh start / reboot as well. Perhaps building from the ground-up on a core scenegraph framework that can support 2D *and* 3D, with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax to do the widget etc painting in a resolution-independent, style-based manner (no more high-dpi hassles — future proof resolution independence).. I’m sure everyone could come up with a good wish list based on all the experience with Qt so far :) - Randy > On Apr 13, 2017, at 7:25 PM, Konstantin Tokarev wrote: > > > > 13.04.2017, 13:25, "Konstantin Tokarev" : >> 13.04.2017, 12:32, "Nikita Krupenko" : >>> On четверг, 13 апреля 2017 г. 08:24:39 EEST Randall O'Reilly wrote: >>>> In the context of all this recent discussion about modernizing Qt to >>>> accommodate updates to C++, has anyone given any thought to the radical >>>> idea of creating a brand new product using Go? Go (golang) is rapidly >>>> gaining in popularity, and seems to embody everything that is great about >>>> Qt (simplicity, elegance, strong concern for readability, etc), and it has >>>> many features of Qt built directly into the language (reflection, i.e., >>>> moc, goroutines and channels for signal / slot functionality). One of its >>>> main limitations is lack of a dominant, fully-featured GUI toolkit. There >>>> are existing bindings to Qt and QML, but it seems like creating a brand new >>>> native GUI framework in the Qt mold could be a great opportunity to make a >>>> huge impact on a language that has a bright future. All the lessons >>>> learned as Qt has evolved over the years could be consolidated into a fresh >>>> new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / >>>> Vulkan, etc) as the underlying renderer, or something like that… Obviously >>>> a huge undertaking, but something that could produce transformative effects >>>> for future programmers (whereas it seems that continued improvements to the >>>> C++ product are likely to be much more incremental). Maybe some funding >>>> from Google could be obtained to support such an endeavor? >>>> >>>> - Randy >>> >>> Why Go? Isn't Rust more close to the C++ niche? >> >> Rust does not have even GCC frontend, so is even less portable than C++ > > Ooops, I meant "than Go" > >> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Regards, >> Konstantin >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From bogdan.vatra at kdab.com Thu Apr 13 14:11:01 2017 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Thu, 13 Apr 2017 15:11:01 +0300 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: References: <1643490.9zMfjAF2Up@tjmaciei-mobl1> Message-ID: <3423732.0hmkbpeNVN@zmeu> It's just me or did you forgot to add 5.8.1? Cheers, BogDan. On joi, 13 aprilie 2017 11:48:06 EEST Jani Heikkinen wrote: > After short internal discussion here is my proposal for those patch level > releases: > > - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3 > release target August 2017 - Branch '5.9.1' from '5.9' at the end of > July/beginning of August, 5.9.1 release target September 2017 - Branch > '5.9.2' from '5.9' Nov 2017 > - Branch '5.6.4' from '5.6' Jan 2018 > > br, > Jani > > > -----Original Message----- > > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > > project.org] On Behalf Of Thiago Macieira > > Sent: maanantaina 10. huhtikuuta 2017 18.46 > > To: development at qt-project.org; releasing at qt-project.org > > Subject: Re: [Development] Qt 5.10 schedule proposal > > > > Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen > > > > escreveu: > > > Hi, > > > > > > Qt 5.9 is proceeding quite well and it is time to start planning Qt > > > 5.10 schedule. We want to to release 5.10 before Christmas so we need > > > to have Qt > > > 5.10 FF at the beginning of August. I propose following initial > > > schedule for Qt 5.10: > > > > > > - Qt 5.10 Feature Freeze: 8.8.2017 > > > - Qt 5.10 Alpha Release: 31.8.2017 > > > - First Qt 5.10 Beta Release 5.10.2017 > > > - Qt 5.10 RC 16.11.2017 > > > - Qt 5.10 final release 30.11.2017 > > > > Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we > > have an idea of how much work it will be? > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Thu Apr 13 14:30:50 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 13 Apr 2017 15:30:50 +0300 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: <3423732.0hmkbpeNVN@zmeu> References: <1643490.9zMfjAF2Up@tjmaciei-mobl1> <3423732.0hmkbpeNVN@zmeu> Message-ID: <4008781492086650@web32j.yandex.ru> 13.04.2017, 15:11, "Bogdan Vatra" : > It's just me or did you forgot to add 5.8.1? I think I hear how Mr. Turunen is pulling his hair out reading this :) > > Cheers, > BogDan. > > On joi, 13 aprilie 2017 11:48:06 EEST Jani Heikkinen wrote: >>  After short internal discussion here is my proposal for those patch level >>  releases: >> >>      - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3 >>  release target August 2017 - Branch '5.9.1' from '5.9' at the end of >>  July/beginning of August, 5.9.1 release target September 2017 - Branch >>  '5.9.2' from '5.9' Nov 2017 >>      - Branch '5.6.4' from '5.6' Jan 2018 >> >>  br, >>  Jani >> >>  > -----Original Message----- >>  > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- >>  > project.org] On Behalf Of Thiago Macieira >>  > Sent: maanantaina 10. huhtikuuta 2017 18.46 >>  > To: development at qt-project.org; releasing at qt-project.org >>  > Subject: Re: [Development] Qt 5.10 schedule proposal >>  > >>  > Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen >>  > >>  > escreveu: >>  > > Hi, >>  > > >>  > > Qt 5.9 is proceeding quite well and it is time to start planning Qt >>  > > 5.10 schedule. We want to to release 5.10 before Christmas so we need >>  > > to have Qt >>  > > 5.10 FF at the beginning of August. I propose following initial >>  > > schedule for Qt 5.10: >>  > > >>  > > - Qt 5.10 Feature Freeze: 8.8.2017 >>  > > - Qt 5.10 Alpha Release: 31.8.2017 >>  > > - First Qt 5.10 Beta Release 5.10.2017 >>  > > - Qt 5.10 RC 16.11.2017 >>  > > - Qt 5.10 final release 30.11.2017 >>  > >>  > Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we >>  > have an idea of how much work it will be? >>  > >>  > -- >>  > Thiago Macieira - thiago.macieira (AT) intel.com >>  > >>  > Software Architect - Intel Open Source Technology Center >>  > >>  > _______________________________________________ >>  > Development mailing list >>  > Development at qt-project.org >>  > http://lists.qt-project.org/mailman/listinfo/development >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From tuukka.turunen at qt.io Thu Apr 13 14:34:27 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 13 Apr 2017 12:34:27 +0000 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: <4008781492086650@web32j.yandex.ru> References: <1643490.9zMfjAF2Up@tjmaciei-mobl1> <3423732.0hmkbpeNVN@zmeu> <4008781492086650@web32j.yandex.ru> Message-ID: <19618DC5-7EF3-4FFD-A96B-30E1A1E950A4@qt.io> On 13/04/2017, 15.30, "Development on behalf of Konstantin Tokarev" wrote: 13.04.2017, 15:11, "Bogdan Vatra" : > It's just me or did you forgot to add 5.8.1? I think I hear how Mr. Turunen is pulling his hair out reading this :) Yes, quite right. Yours, Tuukka > > Cheers, > BogDan. > > On joi, 13 aprilie 2017 11:48:06 EEST Jani Heikkinen wrote: >> After short internal discussion here is my proposal for those patch level >> releases: >> >> - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3 >> release target August 2017 - Branch '5.9.1' from '5.9' at the end of >> July/beginning of August, 5.9.1 release target September 2017 - Branch >> '5.9.2' from '5.9' Nov 2017 >> - Branch '5.6.4' from '5.6' Jan 2018 >> >> br, >> Jani >> >> > -----Original Message----- >> > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- >> > project.org] On Behalf Of Thiago Macieira >> > Sent: maanantaina 10. huhtikuuta 2017 18.46 >> > To: development at qt-project.org; releasing at qt-project.org >> > Subject: Re: [Development] Qt 5.10 schedule proposal >> > >> > Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen >> > >> > escreveu: >> > > Hi, >> > > >> > > Qt 5.9 is proceeding quite well and it is time to start planning Qt >> > > 5.10 schedule. We want to to release 5.10 before Christmas so we need >> > > to have Qt >> > > 5.10 FF at the beginning of August. I propose following initial >> > > schedule for Qt 5.10: >> > > >> > > - Qt 5.10 Feature Freeze: 8.8.2017 >> > > - Qt 5.10 Alpha Release: 31.8.2017 >> > > - First Qt 5.10 Beta Release 5.10.2017 >> > > - Qt 5.10 RC 16.11.2017 >> > > - Qt 5.10 final release 30.11.2017 >> > >> > Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we >> > have an idea of how much work it will be? >> > >> > -- >> > Thiago Macieira - thiago.macieira (AT) intel.com >> > >> > Software Architect - Intel Open Source Technology Center >> > >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From bogdan.vatra at kdab.com Thu Apr 13 14:36:32 2017 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Thu, 13 Apr 2017 15:36:32 +0300 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: <19618DC5-7EF3-4FFD-A96B-30E1A1E950A4@qt.io> References: <4008781492086650@web32j.yandex.ru> <19618DC5-7EF3-4FFD-A96B-30E1A1E950A4@qt.io> Message-ID: <1697071.68sCSC0O20@zmeu> On joi, 13 aprilie 2017 12:34:27 EEST Tuukka Turunen wrote: > On 13/04/2017, 15.30, "Development on behalf of Konstantin Tokarev" > annulen at yandex.ru> wrote: > > > 13.04.2017, 15:11, "Bogdan Vatra" : > > > It's just me or did you forgot to add 5.8.1? > > > I think I hear how Mr. Turunen is pulling his hair out reading this :) > > Yes, quite right. > My colleagues told me all the story, what I don't understand is why 5.8 branch is not closed. I just pushed quite a few patches in that branch ... BogDan. From tuukka.turunen at qt.io Thu Apr 13 15:27:07 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 13 Apr 2017 13:27:07 +0000 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: <1697071.68sCSC0O20@zmeu> References: <4008781492086650@web32j.yandex.ru> <19618DC5-7EF3-4FFD-A96B-30E1A1E950A4@qt.io>, <1697071.68sCSC0O20@zmeu> Message-ID: Hi, As discussed earlier this week 5.8 branch will be closed now, in essence as soon as Oswald gets to it. Yours, Tuukka ________________________________ From: bogdan.vatra at kdab.com on behalf of Bogdan Vatra Sent: Thursday, April 13, 2017 3:36:32 PM To: Tuukka Turunen Cc: Konstantin Tokarev; development at qt-project.org Subject: Re: [Development] Qt 5.10 schedule proposal On joi, 13 aprilie 2017 12:34:27 EEST Tuukka Turunen wrote: > On 13/04/2017, 15.30, "Development on behalf of Konstantin Tokarev" > annulen at yandex.ru> wrote: > > > 13.04.2017, 15:11, "Bogdan Vatra" : > > > It's just me or did you forgot to add 5.8.1? > > > I think I hear how Mr. Turunen is pulling his hair out reading this :) > > Yes, quite right. > My colleagues told me all the story, what I don't understand is why 5.8 branch is not closed. I just pushed quite a few patches in that branch ... BogDan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Thu Apr 13 15:32:20 2017 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 13 Apr 2017 15:32:20 +0200 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: References: <1643490.9zMfjAF2Up@tjmaciei-mobl1> Message-ID: On Thu, Apr 13, 2017 at 1:48 PM, Jani Heikkinen wrote: > After short internal discussion here is my proposal for those patch level releases: > > - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3 release target August 2017 > - Branch '5.9.1' from '5.9' at the end of July/beginning of August, 5.9.1 release target September 2017 > - Branch '5.9.2' from '5.9' Nov 2017 > - Branch '5.6.4' from '5.6' Jan 2018 > > br, > Jani > > >> -----Original Message----- >> From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- >> project.org] On Behalf Of Thiago Macieira >> Sent: maanantaina 10. huhtikuuta 2017 18.46 >> To: development at qt-project.org; releasing at qt-project.org >> Subject: Re: [Development] Qt 5.10 schedule proposal >> >> Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen >> escreveu: >> > Hi, >> > >> > Qt 5.9 is proceeding quite well and it is time to start planning Qt >> > 5.10 schedule. We want to to release 5.10 before Christmas so we need >> > to have Qt >> > 5.10 FF at the beginning of August. I propose following initial >> > schedule for Qt 5.10: >> > >> > - Qt 5.10 Feature Freeze: 8.8.2017 >> > - Qt 5.10 Alpha Release: 31.8.2017 >> > - First Qt 5.10 Beta Release 5.10.2017 >> > - Qt 5.10 RC 16.11.2017 >> > - Qt 5.10 final release 30.11.2017 >> >> Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we have >> an idea of how much work it will be? On another thread it was discussed as per assumption that the stable branch (i.e. 5.9 in this case) can always be used. Would it be feasible to shorten minor release periods? People will end up using it anyway and the Qt project better make it easy to use a controlled version rather than a random HEAD from the stable branch. Furthermore, I don't think it's enough to wait 3 months to get a stable release, we want people to have an incentive to submit upstream and fix stuff in Qt rather than adding workarounds in their solutions. Aleix From alex at vikingsoft.eu Thu Apr 13 16:44:09 2017 From: alex at vikingsoft.eu (Alejandro Exojo) Date: Thu, 13 Apr 2017 16:44:09 +0200 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: <214901492079139@web53g.yandex.ru> Message-ID: <2199347.krAWCK5yzG@walt> On Thursday 13 April 2017 21:02:59 Randall O'Reilly wrote: > This also means that there is an endless potential for language wars, which > I’m sure nobody wants to rehash on this list. Are you sure? Because in the next sentences seem like you exactly started to fight for one side. You said that C++ "is now massively bloated and unwieldy in some people’s estimation". And you send that to the mailing list of developers of a C++ framework, without wanting to start a war? Really? :-) -- Viking Software, Qt and C++ developers for hire http://www.vikingsoft.eu From thiago.macieira at intel.com Thu Apr 13 21:38:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 13 Apr 2017 12:38:16 -0700 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <2199347.krAWCK5yzG@walt> References: <2199347.krAWCK5yzG@walt> Message-ID: <8728469.scljckuvJz@tjmaciei-mobl1> Em quinta-feira, 13 de abril de 2017, às 07:44:09 PDT, Alejandro Exojo escreveu: > On Thursday 13 April 2017 21:02:59 Randall O'Reilly wrote: > > This also means that there is an endless potential for language wars, > > which > > I’m sure nobody wants to rehash on this list. > > Are you sure? Because in the next sentences seem like you exactly started to > fight for one side. You said that C++ "is now massively bloated and > unwieldy in some people’s estimation". And you send that to the mailing > list of developers of a C++ framework, without wanting to start a war? > Really? :-) He did qualify it as "in some people's estimations", as opposed to saying that as a general accepted truth, which we'd have disagreed on. We can't disagree that some people think that C++ is bloated and unwieldy, I know several people who think that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Apr 13 21:47:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 13 Apr 2017 12:47:50 -0700 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: References: <1643490.9zMfjAF2Up@tjmaciei-mobl1> Message-ID: <3355729.XLYieY6BcX@tjmaciei-mobl1> Interleaving your two emails: > - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3 > release target August 2017 > - Qt 5.10 Feature Freeze: 8.8.2017 > - Qt 5.10 Alpha Release: 31.8.2017 > - Branch '5.9.1' from '5.9' at the end of July/beginning of August, > 5.9.1 release target September 2017 > - First Qt 5.10 Beta Release 5.10.2017 > - Qt 5.10 RC 16.11.2017 > - Branch '5.9.2' from '5.9' Nov 2017 > - Qt 5.10 final release 30.11.2017 > - Branch '5.6.4' from '5.6' Jan 2018 Any chance to pull in 5.6.3 release to the first half of the year? We've already got the first 5.9 beta out, so the release should happen hopefully by the end of May. We should be able to branch 5.6.3 and release sooner than August. That would also help alleviate the work of both a 5.6.3 and 5.10 alpha close together. At this time, 5.6.3 has 405 patches in qtbase, versus 530 that went there for 5.6.2. I'd rather release with fewer than more, as it decreases the chance of being difficult to achieve a release. And the more we wait, the more there will be of them. And it would place 5.6.3 more or less half-way between 5.6.2 (Nov 2016) and 5.6.4 (Feb 2018). The rest seems fine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Martin.Smith at qt.io Fri Apr 14 08:36:08 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 14 Apr 2017 06:36:08 +0000 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <8728469.scljckuvJz@tjmaciei-mobl1> References: <2199347.krAWCK5yzG@walt>,<8728469.scljckuvJz@tjmaciei-mobl1> Message-ID: >He did qualify it as "in some people's estimations"... But you can do that with almost any statement that is false and turn it into a statement that is true. "in some people's estimations" anthropogenic global warming is a hoax. "in some people's estimations" Obama is a Muslim. "in some people's estimations" Trump is a great president. OTOH, Nokia believed Symbian would be on top forever. martin ________________________________________ From: Development on behalf of Thiago Macieira Sent: Thursday, April 13, 2017 9:38:16 PM To: development at qt-project.org Subject: Re: [Development] As Qt contemplates its future.. Em quinta-feira, 13 de abril de 2017, às 07:44:09 PDT, Alejandro Exojo escreveu: > On Thursday 13 April 2017 21:02:59 Randall O'Reilly wrote: > > This also means that there is an endless potential for language wars, > > which > > I’m sure nobody wants to rehash on this list. > > Are you sure? Because in the next sentences seem like you exactly started to > fight for one side. You said that C++ "is now massively bloated and > unwieldy in some people’s estimation". And you send that to the mailing > list of developers of a C++ framework, without wanting to start a war? > Really? :-) He did qualify it as "in some people's estimations", as opposed to saying that as a general accepted truth, which we'd have disagreed on. We can't disagree that some people think that C++ is bloated and unwieldy, I know several people who think that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Sat Apr 15 00:23:01 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 14 Apr 2017 22:23:01 +0000 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: <2257337.m0j1eRqRdy@localhost.localdomain> <209381492079086@web53g.yandex.ru> <214901492079139@web53g.yandex.ru> Message-ID: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> > On 13 Apr 2017, at 14:02, Randall O'Reilly wrote: > > With the recent language explosion, there are now languages to fit everyone’s biases and aesthetics. This explosion is possible because of common language backends and VMs like the JVM, CLR or LLVM. (Hacking gcc to add a new language would’ve been much harder.) So, hopefully that means that you don’t have to champion Go itself as the language of the century and plan on rewriting all of Qt in Go, right? As long as you can generate LLVM-IR somehow from your favorite language at this juncture, you share a foundation with plenty of other languages, so maybe modules written in one could interoperate with modules written in another? Depends on the ABI though. The Rust guys make the point that it’s necessary to rewrite lots of old stuff in Rust in order to have all the security that it can guarantee. But with Go, is there such a mandate? To me so far, Go seems incrementally better but not quite a revolution; fine to try for new projects but maybe not worth the effort of rewriting old code. And of course I’ve been around the block before with this idea that such-and-such needs to be rewritten in such-and-such new-hotness language. The next rewrite ends up more bloated and slow than the last… that seems to be the rule. One big obstacle I’ve been seeing for years is the shortage of C++ API for the QtQuick scene graph, and the difficulty of separating the scene graph to be independent of QML. If you want to have one language for your application (which isn’t QML, Javascript or C++) then you need scene graph bindings to at least be possible. And the usual reason we give is that we don’t have public API so that we remain free to change it. But it’s still an obstacle for making bindings. IMO we’ve got to get to the point where at least the private APIs are complete enough and reasonable enough to use, so you could maintain a scene graph binding for another language alongside Qt, and iterate along with it. Or else rewrite the scene graph, but that seems like needless work, doesn’t it? You can search GitHub and find plenty of scene graphs, but how many of them can do internationalized antialiased text using an atlas (not pre-rendering whole words or lines with freetype), and how many of them do batching like Qt's? Next, why does Go not use LLVM by default? Why do QML and V4 not use it, for that matter? I was hoping we’d do it that way, but we didn’t. I think it would have saved some work, and gained some interoperability, and a lot of tooling possibilities. > This also means that there is an endless potential for language wars, which I’m sure nobody wants to rehash on this list. My point is just that Go represents a particular set of choices that I think is very compatible with a certain (possibly large) segment of the Qt user-base — those who favor clarity, simplicity, readability, over e.g., extreme performance optimization or having every different kind of possible language feature at one’s disposal (aka “language bloat”). As C++ is seemingly in a constant state of reinvention lately, and is now massively bloated and unwieldy in some people’s estimation, it might be an opportune moment to consider a “reboot” — a fresh new framework unburdened by all that cruft. My sense is that Go has made some really excellent (and hard) choices that benefit from all the different language experiments and experience (and especially the limitations of C++), and that one major thing holding it back is lack of a decent GUI framework, so that Qt could really make a big difference there. Furthermore, Qt itself has a kind of bloat problem of its own, having evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now 3D), so it could possibly benefit from a fresh start / reboot as well. > > Perhaps building from the ground-up on a core scenegraph framework that can support 2D *and* 3D, and usually it would be pointed out that a 3D engine is terrible overkill for 2D UIs. But now we’re coming out with that third choice anyway, Qt 3D Studio. So maybe we’ll get there after all, and find out whether or not a 3D scene graph is practical for ordinary everyday UIs. Of course if there ends up being a good reason to have a true 3D UI in most everyday ordinary applications, then the 3D scene graph is not overkill I guess. > with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax to do the widget etc painting in a resolution-independent, style-based manner (no more high-dpi hassles — future proof resolution independence).. What I want in addition to purely scalable graphics is to do all the rendering on the GPU: no more pre-chewing of all the vertices by the parent CPU before feeding it to the little baby GPU cores. It would be worth whatever upheaval is necessary to get there, IMO. And by the time we figure out how, maybe we won’t have to worry about limited back ends like OpenGL ES anymore. From giuseppe.dangelo at kdab.com Sat Apr 15 00:49:35 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sat, 15 Apr 2017 00:49:35 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? Message-ID: Howdy, I'm looking for a resolution regarding the problem of including Standard Library headers from Qt ones. Most notably, I'd like to find a solution for the problems of: * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes; * defining qHash over suitable Standard Library datatypes; * defining std::hash specializations for suitable Qt datatypes; * ... (A separate discussion is whether introducing those declarations in Qt 5.x would constitute an acceptable SIC / BIC. I'm not fully sure the relative QUIP solves this.) So, how and where should we add such definitions? The biggest issue to solve would be the fact that, in order to provide definitions for types from the Standard Library, one needs to include *a lot* of Standard Library headers from Qt ones (think of the qHash overloads). Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From randy.oreilly at colorado.edu Sat Apr 15 07:38:25 2017 From: randy.oreilly at colorado.edu (Randall O'Reilly) Date: Sat, 15 Apr 2017 14:38:25 +0900 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> References: <2257337.m0j1eRqRdy@localhost.localdomain> <209381492079086@web53g.yandex.ru> <214901492079139@web53g.yandex.ru> <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> Message-ID: On Apr 15, 2017, at 7:23 AM, Shawn Rutledge wrote: > > >> On 13 Apr 2017, at 14:02, Randall O'Reilly wrote: >> >> With the recent language explosion, there are now languages to fit everyone’s biases and aesthetics. > > This explosion is possible because of common language backends and VMs like the JVM, CLR or LLVM. (Hacking gcc to add a new language would’ve been much harder.) So, hopefully that means that you don’t have to champion Go itself as the language of the century and plan on rewriting all of Qt in Go, right? As long as you can generate LLVM-IR somehow from your favorite language at this juncture, you share a foundation with plenty of other languages, so maybe modules written in one could interoperate with modules written in another? Depends on the ABI though. > > The Rust guys make the point that it’s necessary to rewrite lots of old stuff in Rust in order to have all the security that it can guarantee. But with Go, is there such a mandate? To me so far, Go seems incrementally better but not quite a revolution; fine to try for new projects but maybe not worth the effort of rewriting old code. And of course I’ve been around the block before with this idea that such-and-such needs to be rewritten in such-and-such new-hotness language. The next rewrite ends up more bloated and slow than the last… that seems to be the rule. The “let a 1000 flowers bloom” kind of interoperability definitely seems appealing for avoiding the seemingly impossible task of having a significant % developers agree on a single language, but then you end up with a tower of babble, which has problems of its own — a jumble of dependencies and everyone has to learn all these different languages to be able to fix things, etc. The single most significant problem with the current babble situation, which definitely drives so much of Qt’s design and debates, comes down to the limitations with the linker, and the consequent need for strict binary compatibility. This forces separation of .h and .cpp (write everything 2x) and then PIMPL on top of that (now write everything 4x!). And then which version of STL to include — none!? One of the major innovations in Go is that it avoids all of those problems. You only ever write things once, in one place (no .h vs. .cpp), and, like an interpreted language, the only distribution mechanism *is the source itself*. There is no such thing as binary compatibility. To make this viable, the Go compiler is insanely fast and so you can just rebuild *everything* from scratch extremely quickly. This is presumably why they didn’t use LLVM etc. Dependency hell is essentially eliminated. So, Go is indeed a pretty radical departure from the current standards. You CAN link to C but not directly to C++ — requires SWIG to call C++.. For people who have “drunk the kool-aid” of Go, it seems not “just another language” but really a complete reinvention of the whole process, trying to capture as many of the “best of” features of things like python AND C++, etc.. A real tradeoff however is that it is MUCH nicer to work with native Go toolkits instead of importing external ones.. hence my advocacy of Qt potentially investing some effort here. > One big obstacle I’ve been seeing for years is the shortage of C++ API for the QtQuick scene graph, and the difficulty of separating the scene graph to be independent of QML. If you want to have one language for your application (which isn’t QML, Javascript or C++) then you need scene graph bindings to at least be possible. And the usual reason we give is that we don’t have public API so that we remain free to change it. > But it’s still an obstacle for making bindings. IMO we’ve got to get to the point where at least the private APIs are complete enough and reasonable enough to use, so you could maintain a scene graph binding for another language alongside Qt, and iterate along with it. Or else rewrite the scene graph, but that seems like needless work, doesn’t it? Yet another instance of the problem solved (or at least reduced) by Go! Everything is exposed. Nothing is hidden. API is all with interfaces that are designed to be clean and minimal — changing the impl doesn’t break anything so you don’t need to hide it, as long as people just use the proper interfaces (which are well documented etc). > You can search GitHub and find plenty of scene graphs, but how many of them can do internationalized antialiased text using an atlas (not pre-rendering whole words or lines with freetype), and how many of them do batching like Qt’s? Yes indeed — the nascent efforts in Go have all run up against the above kinds of problems — again, Qt could really make a difference here! > Next, why does Go not use LLVM by default? Why do QML and V4 not use it, for that matter? I was hoping we’d do it that way, but we didn’t. I think it would have saved some work, and gained some interoperability, and a lot of tooling possibilities. see above.. >> This also means that there is an endless potential for language wars, which I’m sure nobody wants to rehash on this list. My point is just that Go represents a particular set of choices that I think is very compatible with a certain (possibly large) segment of the Qt user-base — those who favor clarity, simplicity, readability, over e.g., extreme performance optimization or having every different kind of possible language feature at one’s disposal (aka “language bloat”). As C++ is seemingly in a constant state of reinvention lately, and is now massively bloated and unwieldy in some people’s estimation, it might be an opportune moment to consider a “reboot” — a fresh new framework unburdened by all that cruft. My sense is that Go has made some really excellent (and hard) choices that benefit from all the different language experiments and experience (and especially the limitations of C++), and that one major thing holding it back is lack of a decent GUI framework, so that Qt could really make a big difference there. Furthermore, Qt itself has a kind of bloat problem of its own, having evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now 3D), so it could possibly benefit from a fresh start / reboot as well. >> >> Perhaps building from the ground-up on a core scenegraph framework that can support 2D *and* 3D, > > and usually it would be pointed out that a 3D engine is terrible overkill for 2D UIs. But now we’re coming out with that third choice anyway, Qt 3D Studio. So maybe we’ll get there after all, and find out whether or not a 3D scene graph is practical for ordinary everyday UIs. Of course if there ends up being a good reason to have a true 3D UI in most everyday ordinary applications, then the 3D scene graph is not overkill I guess. Once you have a scenegraph, it would seem like just having 2D be a natural subset of 3D would be awesome — not everyone needs 3D probably but for those who do, having the full power of the “regular” widget gui at your disposal in 3D would be amazing. And maybe indeed people will develop all kinds of nice new things once 3D is just an easy extension on top of what they are already doing. In my case, we have big neural networks that really need 3D, and it would really be awesome having this kind of inter-operability. >> with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax to do the widget etc painting in a resolution-independent, style-based manner (no more high-dpi hassles — future proof resolution independence).. > > What I want in addition to purely scalable graphics is to do all the rendering on the GPU: no more pre-chewing of all the vertices by the parent CPU before feeding it to the little baby GPU cores. It would be worth whatever upheaval is necessary to get there, IMO. And by the time we figure out how, maybe we won’t have to worry about limited back ends like OpenGL ES anymore. +1 :) And to further address the above point about “why just rewrite stuff in another language” — indeed the ONLY time it really makes sense is if you are doing a major redesign anyway — that’s why it seems like this might be a particularly good time to make the leap to Go at the same time.. - Randy From marc.mutz at kdab.com Sat Apr 15 08:15:44 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 15 Apr 2017 08:15:44 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: References: Message-ID: <201704150815.44150.marc.mutz@kdab.com> On Saturday 15 April 2017 00:49:35 Giuseppe D'Angelo wrote: > * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes; I can only think of std::pair here, and it's done already, in qhashfunctions.h Specifically, we can say nothing about any of the std containers, as they are free to choose their own implementation. E.g. a std::string with SSO is not trvially relocatable. std::pair is special, since the standard prescibes a layout for it. > * defining qHash over suitable Standard Library datatypes; This is the hard one. One could come up with wrappers for each std header, and add qHash() there, but realisically, I don't think it's worth it. If you have std keys, use std types. This dependency inversion is yet another reason to stop providing std facilities in Qt (as soon as we realistically can). > * defining std::hash specializations for suitable Qt datatypes; This is simple, from a header pov: you only need to #include . The problem here is that, absent std::basic_string_view, you have no way to hash arbitrary memory (without first constructing a std::string, that is). The underlying issue is that any user-specialisation of std::hash should delegate to a stdlib-provided one, because implementations are free to add seeding, and, lacking an extra argument, the only way to incorporate the seed is to call a library-provided specialisation. So while it's trivial to add std::hash specialisations for something like QVector, QSizePolicy or QPoint (but not QPointF, because its op== is broken), I currently don't see how we could add them for QString or QByteArray, at least without looping over std::hash, which imo is a no-no. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Sat Apr 15 11:12:01 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 15 Apr 2017 11:12:01 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: <201704150815.44150.marc.mutz@kdab.com> References: <201704150815.44150.marc.mutz@kdab.com> Message-ID: <201704151112.01275.marc.mutz@kdab.com> On Saturday 15 April 2017 08:15:44 Marc Mutz wrote: > So while it's trivial to add std::hash specialisations for something like > [...] QSizePolicy https://codereview.qt-project.org/191742 How to document such things with qdoc is a different question.... -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Sat Apr 15 14:40:40 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sat, 15 Apr 2017 14:40:40 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: <201704150815.44150.marc.mutz@kdab.com> References: <201704150815.44150.marc.mutz@kdab.com> Message-ID: <65e08d54-7657-591e-e005-d41474d3a29f@kdab.com> Il 15/04/2017 08:15, Marc Mutz ha scritto: > On Saturday 15 April 2017 00:49:35 Giuseppe D'Angelo wrote: >> * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes; > > I can only think of std::pair here, and it's done already, in qhashfunctions.h > > Specifically, we can say nothing about any of the std containers, as they are > free to choose their own implementation. E.g. a std::string with SSO is not > trvially relocatable. > > std::pair is special, since the standard prescibes a layout for it. There may be others: std::complex comes to mind; or maybe std::array; or maybe other stuff that's going to be added later. We got a Get Out of Jail Free card with std::pair because was already included from qglobal.h, what do we do for the others? > >> * defining qHash over suitable Standard Library datatypes; > > This is the hard one. One could come up with wrappers for each std header, and > add qHash() there, but realisically, I don't think it's worth it. If you have > std keys, use std types. > > This dependency inversion is yet another reason to stop providing std > facilities in Qt (as soon as we realistically can). This is kind of a harsh resolution. Are people fine with it? The danger is of course downstreams defining their own qHash(std::...) all over the place. And we can't universally recommend unordered associative containers from std (or even deprecate QHash!) because of the next point... > >> * defining std::hash specializations for suitable Qt datatypes; > > This is simple, from a header pov: you only need to #include . I definitely think std::hash specializations should be added for all suitable types; and mandating a specialization of std::hash should also be part of the coding policies. Yet, how many datatypes in Qt offer std::hash right now? > The problem here is that, absent std::basic_string_view, you have no way to > hash arbitrary memory (without first constructing a std::string, that is). > > The underlying issue is that any user-specialisation of std::hash should > delegate to a stdlib-provided one, because implementations are free to add > seeding, and, lacking an extra argument, the only way to incorporate the seed > is to call a library-provided specialisation. > > So while it's trivial to add std::hash specialisations for something like > QVector, QSizePolicy or QPoint (but not QPointF, because its op== is broken), > I currently don't see how we could add them for QString or QByteArray, at > least without looping over std::hash, which imo is a no-no. Not to mention that * combining the results of looping over std::hash may well not yeild the same results of applying std::hash over the whole sequence; * there isn't a hash combiner in the std (so we'd still be needing ours); * it's not guaranteed that the hashing algorithm used by std::hash on a type's internal representation is also the best algorithm for the values that that type can actually represent (but rolling your own algorithm, and not using std::hash, makes you lose the seeding or any other goodies done by the implementation). There's a huge discussion in N3980. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Sat Apr 15 15:56:14 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 15 Apr 2017 15:56:14 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: <65e08d54-7657-591e-e005-d41474d3a29f@kdab.com> References: <201704150815.44150.marc.mutz@kdab.com> <65e08d54-7657-591e-e005-d41474d3a29f@kdab.com> Message-ID: <201704151556.14028.marc.mutz@kdab.com> On Saturday 15 April 2017 14:40:40 Giuseppe D'Angelo wrote: > Il 15/04/2017 08:15, Marc Mutz ha scritto: > > On Saturday 15 April 2017 00:49:35 Giuseppe D'Angelo wrote: > >> * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes; > > > > I can only think of std::pair here, and it's done already, in > > qhashfunctions.h > > > > Specifically, we can say nothing about any of the std containers, as they > > are free to choose their own implementation. E.g. a std::string with SSO > > is not trvially relocatable. > > > > std::pair is special, since the standard prescibes a layout for it. > > There may be others: std::complex comes to mind; or maybe std::array; or > maybe other stuff that's going to be added later. We got a Get Out of > Jail Free card with std::pair because was already included > from qglobal.h, what do we do for the others? > > >> * defining qHash over suitable Standard Library datatypes; > > > > This is the hard one. One could come up with wrappers for each std > > header, and add qHash() there, but realisically, I don't think it's > > worth it. If you have std keys, use std types. > > > > This dependency inversion is yet another reason to stop providing std > > facilities in Qt (as soon as we realistically can). > > This is kind of a harsh resolution. > > Are people fine with it? The danger > is of course downstreams defining their own qHash(std::...) all over the > place. And we can't universally recommend unordered associative > containers from std (or even deprecate QHash!) because of the next point... > > >> * defining std::hash specializations for suitable Qt datatypes; > > > > This is simple, from a header pov: you only need to #include > > . > > I definitely think std::hash specializations should be added for all > suitable types; and mandating a specialization of std::hash should also > be part of the coding policies. Yet, how many datatypes in Qt offer > std::hash right now? Well, we don't really know, yet, if all of our supported platforms support std::hash. Being a specialisation, someone needs to provide the primary template... I'm hoping that we *can* depend on std:hash being available by now. The problem, of course, is QNX. > > The problem here is that, absent std::basic_string_view, you have no way > > to hash arbitrary memory (without first constructing a std::string, that > > is). > > > > The underlying issue is that any user-specialisation of std::hash should > > delegate to a stdlib-provided one, because implementations are free to > > add seeding, and, lacking an extra argument, the only way to incorporate > > the seed is to call a library-provided specialisation. > > > > So while it's trivial to add std::hash specialisations for something like > > QVector, QSizePolicy or QPoint (but not QPointF, because its op== is > > broken), I currently don't see how we could add them for QString or > > QByteArray, at least without looping over std::hash, which imo is > > a no-no. > > Not to mention that > * combining the results of looping over std::hash may well not > yeild the same results of applying std::hash over the whole > sequence; That's a SEP. The standard, unlike Qt, allows to pass user-defined hashing functions everywhere they are used, so it's trivial to define your own hashing function and use it. The main problem with qHash() is that there's _only_ qHash(), and nothing else. > * there isn't a hash combiner in the std (so we'd still be needing ours); It's not "ours", it's boost::hash_combine :) And we can't use it, because it calls qHash() instead of taking a hash function as a parameter. But we can use boost::hash_combine if we finally get over it and just use it instead of reimplementing everything from boost all over. > * it's not guaranteed that the hashing algorithm used by std::hash on a > type's internal representation is also the best algorithm for the values > that that type can actually represent (but rolling your own algorithm, > and not using std::hash, makes you lose the seeding or any other goodies > done by the implementation). There's a huge discussion in N3980. I know Howard's ideas about hashing, and I agree with them. In Qt, we largely ignore the issue of hash collisions for a given type and just hash its members, combining with boost::hash_combine, and hope for the best. As such, the problem described in Paragraph 5 of https://isocpp.org/files/papers/n3980.html#Solution1B, if it is, indeed, the one you're referring to, is the same for qHash() and std::hash. Only a Hinnant-like hashing interface that takes the hash function as a parameter would solve that. Are you suggesting to skip supporting std::hash and go directly to providing Hinnant's interface in Qt instead? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From charleyb123 at gmail.com Sat Apr 15 16:10:16 2017 From: charleyb123 at gmail.com (charleyb123 .) Date: Sat, 15 Apr 2017 08:10:16 -0600 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: <201704151556.14028.marc.mutz@kdab.com> References: <201704150815.44150.marc.mutz@kdab.com> <65e08d54-7657-591e-e005-d41474d3a29f@kdab.com> <201704151556.14028.marc.mutz@kdab.com> Message-ID: Marc: > I know Howard's ideas about hashing, and I agree with them. In Qt, we > largely > ignore the issue of hash collisions for a given type and just hash its > members, combining with boost::hash_combine, and hope for the best. As > such, > the problem described in Paragraph 5 of > https://isocpp.org/files/papers/n3980.html#Solution1B, if it is, indeed, > the > one you're referring to, is the same for qHash() and std::hash. Only a > Hinnant-like hashing interface that takes the hash function as a parameter > would solve that. > > Are you suggesting to skip supporting std::hash and go directly to > providing > Hinnant's interface in Qt instead? > I'm party-crashing the discussion, but +1. (1) Skip std::hash, it's the wrong interface. (2) Use a transactional hash interface (very performant and composable) We implemented the Hinnant-style interface a long time ago throughout a very large codebase, it works best when consistently supported across the codebase, IMHO it's a vastly superior way to go. For the casual reader, this implies a "transactional" approach to hashing: (1) "Start/init" the hash (2) Go nuts accumulating state into the hash (3) Finalize the hash (for example, can be "lazy" when hash-value is extracted) The problem with "std::hash" is that it lumps all three steps into one step, which is horrible and expensive in many/most real-world applications requiring hashing of non-trivial state. The Hinnant-style interface works great when all APIs take a "QtHashBuilder" (or whatever). Qt has tons of experience with consistent APIs like that, for example, see recent discussions on QStringBuilder or similar. --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Sat Apr 15 17:52:13 2017 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 15 Apr 2017 17:52:13 +0200 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> References: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> Message-ID: <9215414.19W6c8CN33@maurice> On Samstag, 15. April 2017 00:23:01 CEST Shawn Rutledge wrote: [...] > The Rust guys make the point that it’s necessary to rewrite lots of old > stuff in Rust in order to have all the security that it can guarantee. No, that's a common myth. I've heard people say: "There is no point in making/using rust bindings for Qt since that would 'void' the point of Rust because Qt itself is not written in a memory safe language." But that's wrong. When you are writing code in rust, your code will be safer. Sure, it might call into a library that is written in an unsafe language, or that is using the unsafe keyword, but that is not your code, and it is the responsibility of the library author to fix these bugs. You can rely on the libraries, kernel, compiler, etc. to be safe because other people have already spent countless hours fixing bugs and reviewing code. There is still value in writing in Rust because it will be easier for you to make YOUR code safer. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Sat Apr 15 18:28:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 15 Apr 2017 09:28:16 -0700 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> Message-ID: <6169817.IK04xeHo7i@tjmaciei-mobl1> Em sexta-feira, 14 de abril de 2017, às 22:38:25 PDT, Randall O'Reilly escreveu: > One of the major innovations in Go is that it avoids all of those problems. > You only ever write things once, in one place (no .h vs. .cpp), and, like > an interpreted language, the only distribution mechanism *is the source > itself*. There is no such thing as binary compatibility. Because there's no such thing as binary distribution in the first place. That means you cannot provide a component without the source. If we insisted on all Qt users simply recompiling every time that Qt changed, then we could apply the same to C++ and only retain source compatibility. That is, after all, what Boost does. By the way, is it even possible to distribute a binary application? [cut] > hence my advocacy of Qt potentially investing some effort here. Seems like we already have a binding to Go. What else do we need? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From randy.oreilly at colorado.edu Sat Apr 15 19:14:45 2017 From: randy.oreilly at colorado.edu (Randall O'Reilly) Date: Sun, 16 Apr 2017 02:14:45 +0900 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <6169817.IK04xeHo7i@tjmaciei-mobl1> References: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> <6169817.IK04xeHo7i@tjmaciei-mobl1> Message-ID: On Apr 16, 2017, at 1:28 AM, Thiago Macieira wrote: > > Em sexta-feira, 14 de abril de 2017, às 22:38:25 PDT, Randall O'Reilly > escreveu: >> One of the major innovations in Go is that it avoids all of those problems. >> You only ever write things once, in one place (no .h vs. .cpp), and, like >> an interpreted language, the only distribution mechanism *is the source >> itself*. There is no such thing as binary compatibility. > > Because there's no such thing as binary distribution in the first place. That > means you cannot provide a component without the source. If we insisted on all > Qt users simply recompiling every time that Qt changed, then we could apply > the same to C++ and only retain source compatibility. That is, after all, what > Boost does. That’s why the Go folks worry so much about super-fast compile times.. > By the way, is it even possible to distribute a binary application? Yes, the final product of the compilation process is a (fat) static binary. > [cut] >> hence my advocacy of Qt potentially investing some effort here. > > Seems like we already have a binding to Go. What else do we need? Yeah, but it’s not native Go, so it doesn’t really advance anything. Potentially a usable stop-gap but given the limitations with the way that Go and C++ interface, I doubt many people using Go would find it a satisfying solution. The proposal is that this is an opportunity for “next gen Qt” not a plea for a port of the existing product.. Cheers, - Randy From thiago.macieira at intel.com Sat Apr 15 20:18:46 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 15 Apr 2017 11:18:46 -0700 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: <6169817.IK04xeHo7i@tjmaciei-mobl1> Message-ID: <26651259.qY57mu68lu@tjmaciei-mobl1> Em sábado, 15 de abril de 2017, às 10:14:45 PDT, Randall O'Reilly escreveu: > > Because there's no such thing as binary distribution in the first place. > > That means you cannot provide a component without the source. If we > > insisted on all Qt users simply recompiling every time that Qt changed, > > then we could apply the same to C++ and only retain source compatibility. > > That is, after all, what Boost does. > > That’s why the Go folks worry so much about super-fast compile times.. > > > By the way, is it even possible to distribute a binary application? > > Yes, the final product of the compilation process is a (fat) static binary. Oh, great! Super easy to fix a security issue or even a simple bug in a tiny component. Just rebuild the world! > > Seems like we already have a binding to Go. What else do we need? > > Yeah, but it’s not native Go, so it doesn’t really advance anything. > Potentially a usable stop-gap but given the limitations with the way that > Go and C++ interface, I doubt many people using Go would find it a > satisfying solution. The proposal is that this is an opportunity for “next > gen Qt” not a plea for a port of the existing product.. We're NOT going to rewrite Qt in Go. That's simply not going to happen. The best you can expect is an officially supported Go binding, with some extra goodies. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sat Apr 15 21:00:48 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 15 Apr 2017 22:00:48 +0300 Subject: [Development] As Qt contemplates its future.. In-Reply-To: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> References: <2257337.m0j1eRqRdy@localhost.localdomain> <209381492079086@web53g.yandex.ru> <214901492079139@web53g.yandex.ru> <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> Message-ID: <5384351492282848@web27g.yandex.ru> 15.04.2017, 01:23, "Shawn Rutledge" : >>  On 13 Apr 2017, at 14:02, Randall O'Reilly wrote: >> >>  With the recent language explosion, there are now languages to fit everyone’s biases and aesthetics. > > This explosion is possible because of common language backends and VMs like the JVM, CLR or LLVM. (Hacking gcc to add a new language would’ve been much harder.) So, hopefully that means that you don’t have to champion Go itself as the language of the century and plan on rewriting all of Qt in Go, right? As long as you can generate LLVM-IR somehow from your favorite language at this juncture, you share a foundation with plenty of other languages, so maybe modules written in one could interoperate with modules written in another? Depends on the ABI though. > > The Rust guys make the point that it’s necessary to rewrite lots of old stuff in Rust in order to have all the security that it can guarantee. But with Go, is there such a mandate? To me so far, Go seems incrementally better but not quite a revolution; fine to try for new projects but maybe not worth the effort of rewriting old code. And of course I’ve been around the block before with this idea that such-and-such needs to be rewritten in such-and-such new-hotness language. The next rewrite ends up more bloated and slow than the last… that seems to be the rule. > > One big obstacle I’ve been seeing for years is the shortage of C++ API for the QtQuick scene graph, and the difficulty of separating the scene graph to be independent of QML. If you want to have one language for your application (which isn’t QML, Javascript or C++) then you need scene graph bindings to at least be possible. And the usual reason we give is that we don’t have public API so that we remain free to change it. But it’s still an obstacle for making bindings. IMO we’ve got to get to the point where at least the private APIs are complete enough and reasonable enough to use, so you could maintain a scene graph binding for another language alongside Qt, and iterate along with it. Or else rewrite the scene graph, but that seems like needless work, doesn’t it? You can search GitHub and find plenty of scene graphs, but how many of them can do internationalized antialiased text using an atlas (not pre-rendering whole words or lines with freetype), and how many of them do batching like Qt's? > > Next, why does Go not use LLVM by default? Why do QML and V4 not use it, for that matter? I was hoping we’d do it that way, but we didn’t. I think it would have saved some work, and gained some interoperability, and a lot of tooling possibilities. Concerning QML/V4: this is a good idea actually. If QML is changed to use AOT compilation as the only mode, it might work very well. > >>  This also means that there is an endless potential for language wars, which I’m sure nobody wants to rehash on this list. My point is just that Go represents a particular set of choices that I think is very compatible with a certain (possibly large) segment of the Qt user-base — those who favor clarity, simplicity, readability, over e.g., extreme performance optimization or having every different kind of possible language feature at one’s disposal (aka “language bloat”). As C++ is seemingly in a constant state of reinvention lately, and is now massively bloated and unwieldy in some people’s estimation, it might be an opportune moment to consider a “reboot” — a fresh new framework unburdened by all that cruft. My sense is that Go has made some really excellent (and hard) choices that benefit from all the different language experiments and experience (and especially the limitations of C++), and that one major thing holding it back is lack of a decent GUI framework, so that Qt could really make a big difference there. Furthermore, Qt itself has a kind of bloat problem of its own, having evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now 3D), so it could possibly benefit from a fresh start / reboot as well. >> >>  Perhaps building from the ground-up on a core scenegraph framework that can support 2D *and* 3D, > > and usually it would be pointed out that a 3D engine is terrible overkill for 2D UIs. But now we’re coming out with that third choice anyway, Qt 3D Studio. So maybe we’ll get there after all, and find out whether or not a 3D scene graph is practical for ordinary everyday UIs. Of course if there ends up being a good reason to have a true 3D UI in most everyday ordinary applications, then the 3D scene graph is not overkill I guess. > >>  with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax to do the widget etc painting in a resolution-independent, style-based manner (no more high-dpi hassles — future proof resolution independence).. > > What I want in addition to purely scalable graphics is to do all the rendering on the GPU: no more pre-chewing of all the vertices by the parent CPU before feeding it to the little baby GPU cores. It would be worth whatever upheaval is necessary to get there, IMO. And by the time we figure out how, maybe we won’t have to worry about limited back ends like OpenGL ES anymore. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From kevin.kofler at chello.at Sat Apr 15 22:06:31 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 15 Apr 2017 22:06:31 +0200 Subject: [Development] As Qt contemplates its future.. References: <2257337.m0j1eRqRdy@localhost.localdomain> <209381492079086@web53g.yandex.ru> <214901492079139@web53g.yandex.ru> <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> Message-ID: Randall O'Reilly wrote: > One of the major innovations in Go is that it avoids all of those > problems. You only ever write things once, in one place (no .h vs. .cpp), > and, like an interpreted language, the only distribution mechanism *is the > source itself*. There is no such thing as binary compatibility. I see only two possibilities here: either things will move to a more traditional distribution model (and we are already getting there slowly, GCCGo has supported shared libraries for a while, now the official compiler also does so), or Go will remain a niche language and a second-class citizen in real-world Free Software distributions. Shipping libraries as source-only and distributing only static binaries just does not scale. It is not realistic for something of the size of Qt. And it is also just not how distros work. Kevin Kofler From kevin.kofler at chello.at Sat Apr 15 22:18:06 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 15 Apr 2017 22:18:06 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? References: <201704150815.44150.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > The underlying issue is that any user-specialisation of std::hash should > delegate to a stdlib-provided one, because implementations are free to add > seeding, and, lacking an extra argument, the only way to incorporate the > seed is to call a library-provided specialisation. > > So while it's trivial to add std::hash specialisations for something like > QVector, QSizePolicy or QPoint (but not QPointF, because its op== is > broken), I currently don't see how we could add them for QString or > QByteArray, at least without looping over std::hash, which imo is a > no-no. Why not have the std::hash implementation for Qt types just call qHash(foo, qGlobalQHashSeed())? Who cares about the STL's seeding if you can just use your own? Kevin Kofler From marc.mutz at kdab.com Sun Apr 16 13:26:00 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 16 Apr 2017 13:26:00 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: References: <201704151556.14028.marc.mutz@kdab.com> Message-ID: <201704161326.00076.marc.mutz@kdab.com> On Saturday 15 April 2017 16:10:16 charleyb123 . wrote: > > > Marc: > > I know Howard's ideas about hashing, and I agree with them. In Qt, we > > largely > > ignore the issue of hash collisions for a given type and just hash its > > members, combining with boost::hash_combine, and hope for the best. As > > such, > > the problem described in Paragraph 5 of > > https://isocpp.org/files/papers/n3980.html#Solution1B, if it is, indeed, > > the > > one you're referring to, is the same for qHash() and std::hash. Only a > > Hinnant-like hashing interface that takes the hash function as a > > parameter would solve that. > > > > Are you suggesting to skip supporting std::hash and go directly to > > providing > > Hinnant's interface in Qt instead? > > I'm party-crashing the discussion, but +1. > > (1) Skip std::hash, it's the wrong interface. > (2) Use a transactional hash interface (very performant and composable) I'm sympathetic to this. The problem I see is that while adding hash_append() overloads is easy to do, and requires no header included, some of the value of Hinnant's proposal is std::is_uniquely_represented, which, as a type trait, needs some header to provide a primary template. Is there some definite reference implementation that we could check for (with QT_HAS_INCLUDE())? Thanks, Marc > We implemented the Hinnant-style interface a long time ago throughout a > very large codebase, it works best when consistently supported across the > codebase, IMHO it's a vastly superior way to go. > > For the casual reader, this implies a "transactional" approach to hashing: > > (1) "Start/init" the hash > (2) Go nuts accumulating state into the hash > (3) Finalize the hash (for example, can be "lazy" when hash-value is > extracted) > > The problem with "std::hash" is that it lumps all three steps into one > step, which is horrible and expensive in many/most real-world applications > requiring hashing of non-trivial state. > > The Hinnant-style interface works great when all APIs take a > "QtHashBuilder" (or whatever). Qt has tons of experience with consistent > APIs like that, for example, see recent discussions on QStringBuilder or > similar. > > --charley -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From markg85 at gmail.com Sun Apr 16 15:56:16 2017 From: markg85 at gmail.com (Mark Gaiser) Date: Sun, 16 Apr 2017 15:56:16 +0200 Subject: [Development] QHash iteration vs std::unordered_map Message-ID: Hi, Take this simple example: QHash test = { {10, "aaa"}, {20, "bbb"}, {30, "ccc"} }; for (const auto &entry: qAsConst(test)) { qDebug() << entry; } It returns: "aaa" "ccc" "bbb" and the std::unordered_map version: std::unordered_map test = { {10, "aaa"}, {20, "bbb"}, {30, "ccc"} }; for (const auto &entry: test) { qDebug() << entry; } it returns: std::pair(30,"ccc") std::pair(10,"aaa") std::pair(20,"bbb") As you can see, the QHash iteration directly returns the value. The std::unordered_map returns a std::par with the key and value for the current iteration (in it's respective first and second members). Both approaches probably have arguments in favor and against. What i'm curious about is why there is a difference at all? I'm curious because the behavior is a bit unexpected when compared to std::unordered_map. I would have guessed QHash to follow the same logic as std::unordered_map, only with a Qt syntax. So for instance a return of QPair(...), not the value directly. Thanks, Mark From apoenitz at t-online.de Sun Apr 16 15:15:00 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sun, 16 Apr 2017 15:15:00 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: References: Message-ID: <20170416131500.GC2491@klara.mpi.htwm.de> On Sat, Apr 15, 2017 at 12:49:35AM +0200, Giuseppe D'Angelo wrote: > Howdy, > > I'm looking for a resolution regarding the problem of including Standard > Library headers from Qt ones. Most notably, I'd like to find a solution > for the problems of: > > * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes; > * defining qHash over suitable Standard Library datatypes; > * defining std::hash specializations for suitable Qt datatypes; > * ... > > (A separate discussion is whether introducing those declarations in Qt > 5.x would constitute an acceptable SIC / BIC. I'm not fully sure the > relative QUIP solves this.) > > So, how and where should we add such definitions? Lacking heavy qualification I don't see much of a "we" here anymore. Instead, I see a divide between people who just use, and intent to be able to use in the future, Qt, and people who consider the Qt (Core, even) code base as their personal playground. A while ago, it was *much* cheaper to #include than , and the resulting faster compile times were seen as one of the benefits of Qt, independent of the added utility of the actual class. Thanks to the the contributions of some "we", "we" (other) ended up in a situation where the utility of Qt was continuously reduced (small translation unit were one them), or removed (say, algorithms operating on full containers). > The biggest issue to solve would be the fact that, in order to provide > definitions for types from the Standard Library, one needs to include > *a lot* of Standard Library headers from Qt ones (think of the qHash > overloads). If this were meant to be a serious process, you'd start with making a point on what benefits a user would have from solving what you call "problems" and let people judge whether this is something that helps or hurts them. I call myself a "plain user of Qt" more often than not, and I have never seen any of the issues from your list close to anything that I'd consider a serious issue in real life. Since the flurry of last years' microoptimizations in the QString and algorithm area had measurably negative impact on me (like time I had to spend to work around SC breakages), but no measurable positive impact (should I have witnessed any performance gains?) I reserve the right to be sceptical here, unless something resembling a proof of the opposite shows up. Andre' From mardy at users.sourceforge.net Sun Apr 16 16:41:27 2017 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Sun, 16 Apr 2017 17:41:27 +0300 Subject: [Development] Adding Q_GADGET here and there Message-ID: <53946074-d565-bf06-0e84-a75df5c57393@users.sourceforge.net> Hi all, I'm about to use QMimeType in my application, and I'd found it useful if it were a Q_GADGET. Can I just go on and submit a patch to add that, or are there some cons (a small increase on the library size, I assume)? In general: is it a good idea to add Q_GADGET to non QObject classes within the Qt source code? Ciao, Alberto From corentin.jabot at gmail.com Sun Apr 16 16:44:31 2017 From: corentin.jabot at gmail.com (Corentin) Date: Sun, 16 Apr 2017 14:44:31 +0000 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: Message-ID: Funny, a friend at kdab asked me about that exact question a few minutes ago. The reason for the difference is most certainly an historical one ( and can't be changed because it would break quite a bit of code ). If you want the same behavior, you can create a proxy for your associative container instance, with a custom iterator whose operator*() returns a std pair ( or a QPair ) - quite a bit of boilterplate code. Le dim. 16 avr. 2017 à 15:57, Mark Gaiser a écrit : > Hi, > > Take this simple example: > > QHash test = { > {10, "aaa"}, > {20, "bbb"}, > {30, "ccc"} > }; > > for (const auto &entry: qAsConst(test)) { > qDebug() << entry; > } > > It returns: > "aaa" > "ccc" > "bbb" > > and the std::unordered_map version: > std::unordered_map test = { > {10, "aaa"}, > {20, "bbb"}, > {30, "ccc"} > }; > > for (const auto &entry: test) { > qDebug() << entry; > } > > it returns: > std::pair(30,"ccc") > std::pair(10,"aaa") > std::pair(20,"bbb") > > As you can see, the QHash iteration directly returns the value. The > std::unordered_map returns a std::par with the key and value for the > current iteration (in it's respective first and second members). Both > approaches probably have arguments in favor and against. What i'm > curious about is why there is a difference at all? > > I'm curious because the behavior is a bit unexpected when compared to > std::unordered_map. I would have guessed QHash to follow the same > logic as std::unordered_map, only with a Qt syntax. So for instance a > return of QPair(...), not the value directly. > > Thanks, > Mark > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markg85 at gmail.com Sun Apr 16 17:05:21 2017 From: markg85 at gmail.com (Mark Gaiser) Date: Sun, 16 Apr 2017 17:05:21 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: Message-ID: On Sun, Apr 16, 2017 at 4:44 PM, Corentin wrote: > Funny, a friend at kdab asked me about that exact question a few minutes > ago. > The reason for the difference is most certainly an historical one ( and > can't be changed because it would break quite a bit of code ). > > If you want the same behavior, you can create a proxy for your associative > container instance, with a custom iterator whose operator*() returns a std > pair ( or a QPair ) - quite a bit of boilterplate code. It probably does come down to historic reasons, but that would be strange as well. I doubt that the C++ committee changed what is returned by operator*() (correct me if i'm wrong) so i'm inclined to think that the std:: stuff is returning it as an std::pair for quite a while now. That again makes me wonder, why did Qt diverge from that? And... if Qt plans to change it in Qt6? > > > > > Le dim. 16 avr. 2017 à 15:57, Mark Gaiser a écrit : >> >> Hi, >> >> Take this simple example: >> >> QHash test = { >> {10, "aaa"}, >> {20, "bbb"}, >> {30, "ccc"} >> }; >> >> for (const auto &entry: qAsConst(test)) { >> qDebug() << entry; >> } >> >> It returns: >> "aaa" >> "ccc" >> "bbb" >> >> and the std::unordered_map version: >> std::unordered_map test = { >> {10, "aaa"}, >> {20, "bbb"}, >> {30, "ccc"} >> }; >> >> for (const auto &entry: test) { >> qDebug() << entry; >> } >> >> it returns: >> std::pair(30,"ccc") >> std::pair(10,"aaa") >> std::pair(20,"bbb") >> >> As you can see, the QHash iteration directly returns the value. The >> std::unordered_map returns a std::par with the key and value for the >> current iteration (in it's respective first and second members). Both >> approaches probably have arguments in favor and against. What i'm >> curious about is why there is a difference at all? >> >> I'm curious because the behavior is a bit unexpected when compared to >> std::unordered_map. I would have guessed QHash to follow the same >> logic as std::unordered_map, only with a Qt syntax. So for instance a >> return of QPair(...), not the value directly. >> >> Thanks, >> Mark >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Sun Apr 16 17:08:54 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Sun, 16 Apr 2017 18:08:54 +0300 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: Message-ID: Very unlikely I'd say. Hashes are used all over the place in ppl' code and making this change will break way too much to be sensible. On Sun, Apr 16, 2017 at 6:05 PM, Mark Gaiser wrote: > On Sun, Apr 16, 2017 at 4:44 PM, Corentin > wrote: > > Funny, a friend at kdab asked me about that exact question a few minutes > > ago. > > The reason for the difference is most certainly an historical one ( and > > can't be changed because it would break quite a bit of code ). > > > > If you want the same behavior, you can create a proxy for your > associative > > container instance, with a custom iterator whose operator*() returns a > std > > pair ( or a QPair ) - quite a bit of boilterplate code. > > It probably does come down to historic reasons, but that would be > strange as well. > I doubt that the C++ committee changed what is returned by operator*() > (correct me if i'm wrong) so i'm inclined to think that the > std:: stuff is returning it as an std::pair for quite a > while now. > That again makes me wonder, why did Qt diverge from that? > > And... if Qt plans to change it in Qt6? > > > > > > > > > > > Le dim. 16 avr. 2017 à 15:57, Mark Gaiser a écrit : > >> > >> Hi, > >> > >> Take this simple example: > >> > >> QHash test = { > >> {10, "aaa"}, > >> {20, "bbb"}, > >> {30, "ccc"} > >> }; > >> > >> for (const auto &entry: qAsConst(test)) { > >> qDebug() << entry; > >> } > >> > >> It returns: > >> "aaa" > >> "ccc" > >> "bbb" > >> > >> and the std::unordered_map version: > >> std::unordered_map test = { > >> {10, "aaa"}, > >> {20, "bbb"}, > >> {30, "ccc"} > >> }; > >> > >> for (const auto &entry: test) { > >> qDebug() << entry; > >> } > >> > >> it returns: > >> std::pair(30,"ccc") > >> std::pair(10,"aaa") > >> std::pair(20,"bbb") > >> > >> As you can see, the QHash iteration directly returns the value. The > >> std::unordered_map returns a std::par with the key and value for the > >> current iteration (in it's respective first and second members). Both > >> approaches probably have arguments in favor and against. What i'm > >> curious about is why there is a difference at all? > >> > >> I'm curious because the behavior is a bit unexpected when compared to > >> std::unordered_map. I would have guessed QHash to follow the same > >> logic as std::unordered_map, only with a Qt syntax. So for instance a > >> return of QPair(...), not the value directly. > >> > >> Thanks, > >> Mark > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.jabot at gmail.com Sun Apr 16 17:31:40 2017 From: corentin.jabot at gmail.com (Corentin) Date: Sun, 16 Apr 2017 15:31:40 +0000 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: Message-ID: Qt wasn't initially designed with STL compatibility in mind ( in the early 2000, STL support was poor on most platforms and Qt actually predates c++98 - though QMap do not, I think). - I would argue that STL compatibility is still an issue more often than not, but it's another discussion :) As for a change in Qt6... It would result in *a lot* of hard-to-track source breakages, so I hope not ( one solution would be to offer a powerful refactoring tool). Le dim. 16 avr. 2017 à 17:06, Mark Gaiser a écrit : > On Sun, Apr 16, 2017 at 4:44 PM, Corentin > wrote: > > Funny, a friend at kdab asked me about that exact question a few minutes > > ago. > > The reason for the difference is most certainly an historical one ( and > > can't be changed because it would break quite a bit of code ). > > > > If you want the same behavior, you can create a proxy for your > associative > > container instance, with a custom iterator whose operator*() returns a > std > > pair ( or a QPair ) - quite a bit of boilterplate code. > > It probably does come down to historic reasons, but that would be > strange as well. > I doubt that the C++ committee changed what is returned by operator*() > (correct me if i'm wrong) so i'm inclined to think that the > std:: stuff is returning it as an std::pair for quite a > while now. > That again makes me wonder, why did Qt diverge from that? > > And... if Qt plans to change it in Qt6? > > > > > > > > > > > Le dim. 16 avr. 2017 à 15:57, Mark Gaiser a écrit : > >> > >> Hi, > >> > >> Take this simple example: > >> > >> QHash test = { > >> {10, "aaa"}, > >> {20, "bbb"}, > >> {30, "ccc"} > >> }; > >> > >> for (const auto &entry: qAsConst(test)) { > >> qDebug() << entry; > >> } > >> > >> It returns: > >> "aaa" > >> "ccc" > >> "bbb" > >> > >> and the std::unordered_map version: > >> std::unordered_map test = { > >> {10, "aaa"}, > >> {20, "bbb"}, > >> {30, "ccc"} > >> }; > >> > >> for (const auto &entry: test) { > >> qDebug() << entry; > >> } > >> > >> it returns: > >> std::pair(30,"ccc") > >> std::pair(10,"aaa") > >> std::pair(20,"bbb") > >> > >> As you can see, the QHash iteration directly returns the value. The > >> std::unordered_map returns a std::par with the key and value for the > >> current iteration (in it's respective first and second members). Both > >> approaches probably have arguments in favor and against. What i'm > >> curious about is why there is a difference at all? > >> > >> I'm curious because the behavior is a bit unexpected when compared to > >> std::unordered_map. I would have guessed QHash to follow the same > >> logic as std::unordered_map, only with a Qt syntax. So for instance a > >> return of QPair(...), not the value directly. > >> > >> Thanks, > >> Mark > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.jabot at gmail.com Sun Apr 16 18:32:53 2017 From: corentin.jabot at gmail.com (Corentin) Date: Sun, 16 Apr 2017 16:32:53 +0000 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: <20170416131500.GC2491@klara.mpi.htwm.de> References: <20170416131500.GC2491@klara.mpi.htwm.de> Message-ID: I think that part of the issue is that the way the STL should be treated is a bit of a polarizing issue. Of course, there are technical considerations, such as some STL implementations being lacking on older platforms, but mostly Qt and the STL have some overlaps, and people can't agree on how to handle said overlaps. I personally consider that the STL is as much part of C++ than the core language and any api should therefore be as much compatible with it as possible. Redundant algorithms & utilities ( mutex, shared pointer, etc ), should probably not exist at all at this point, though they used to make sense. As such, Qt containers should work properly with any STL types, and Qt types should work well with the STL constructs, containers, types and algorithms. Most people use Qt as a framework and play by Qt's rules, but for others Qt may just be the UI layer, an other library in the stack. Both use cases should be catered to. More on point: * You don't actually need to include anything from the STL to implement std::hash. * For qHash, maybe one or more qt_stl.h headers that would include the required stl headers. Forward declare when possible ( probably not often, sadly ). Compilations times may, for the time being, be an issue but I don't think Qt can or should work around them. I would also prefer a solution that is independent of the order of the includes. Since the flurry of last years' microoptimizations in the QString and > algorithm area had measurably negative impact on me (like time I had to > spend to work around SC breakages), but no measurable positive impact > (should I have witnessed any performance gains?) I reserve the right to > be sceptical here, unless something resembling a proof of the opposite > shows up. > Micro-optimizations on such low level classes are always worth it. > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Sun Apr 16 19:51:46 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 16 Apr 2017 19:51:46 +0200 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: References: <20170416131500.GC2491@klara.mpi.htwm.de> Message-ID: <01a144d7-dba7-0d69-cccd-70959d4dda26@kdab.com> Il 16/04/2017 18:32, Corentin ha scritto: > > More on point: > * You don't actually need to include anything from the STL to > implement std::hash. You actually do: you need to see the primary template for std::hash (otherwise you can't specialize it). Also, how to implement it is another burden (see the other discussion). > * For qHash, maybe one or more qt_stl.h headers that would include > the required stl headers. Forward declare when possible ( probably not > often, sadly ). Compilations times may, for the time being, be an issue > but I don't think Qt can or should work around them. > > I would also prefer a solution that is independent of the order of the > includes. A central STL header would work for qHash (apart from the huge compilation times, as it'll need to include a *lot* of stuff), but I'm scared that it would quickly become a maintenance nightmare. It would be a bit dangerous for Q_DECLARE_TYPEINFO: such a declaration might change the ABI for a type (so, for instance, if you include qt_stl.h in a TU and forget in another TU and only include the STL header, now the two TUs are binary incompatible between each other...). Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Sun Apr 16 19:55:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Apr 2017 10:55:21 -0700 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: References: <20170416131500.GC2491@klara.mpi.htwm.de> Message-ID: <1770579.L7vtUfY4Qb@tjmaciei-mobl1> Em domingo, 16 de abril de 2017, às 09:32:53 PDT, Corentin escreveu: > Redundant algorithms & utilities ( mutex, shared pointer, etc ), > should probably not exist at all at this point, though they used to make > sense. Note that we don't consider redundant when the Qt type provides significant advantage over the Standard Library one, be it performance or convenience. One example is QMutex, which is MUCH faster than std::mutex in all platforms. I'm also proposing to add QRandomDevice to Qt 5.10 because we can make it better than std::random_device. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Apr 16 17:53:52 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Apr 2017 08:53:52 -0700 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: Message-ID: <10085874.vcRdT34mlR@tjmaciei-mobl1> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu: > That again makes me wonder, why did Qt diverge from that? We didn't diverge. We never had that. The Qt style predates the Standard Library having relevance in Qt. When the first QHash-like class was added, it was just like that. Also remember that at the time, you wouldn't think of a Standard Library associative container as such. It was just a sequential container that held a std::pair, with some convenience functions for searching the first of the pair. Returning a pair was a consequence of that. I don't know if it was intentional thinking, or it just happened. > And... if Qt plans to change it in Qt6? No, cannot due to source compatibility. Ever. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Sun Apr 16 20:13:26 2017 From: olivier at woboq.com (Olivier Goffart) Date: Sun, 16 Apr 2017 20:13:26 +0200 Subject: [Development] Adding Q_GADGET here and there In-Reply-To: <53946074-d565-bf06-0e84-a75df5c57393@users.sourceforge.net> References: <53946074-d565-bf06-0e84-a75df5c57393@users.sourceforge.net> Message-ID: <2898248.6xxIf1ZGPM@maurice> On Sonntag, 16. April 2017 16:41:27 CEST Alberto Mardegan wrote: > Hi all, > I'm about to use QMimeType in my application, and I'd found it useful > if it were a Q_GADGET. Can I just go on and submit a patch to add that, > or are there some cons (a small increase on the library size, I assume)? > > In general: is it a good idea to add Q_GADGET to non QObject classes > within the Qt source code? Q_GADGET's overhead is basically the cost of the QMetaObject. So it's there, but it's quite small. If there is an use for a class to be a Q_GADGET, I think it should be added. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From ville.voutilainen at gmail.com Sun Apr 16 20:54:03 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sun, 16 Apr 2017 21:54:03 +0300 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: <01a144d7-dba7-0d69-cccd-70959d4dda26@kdab.com> References: <20170416131500.GC2491@klara.mpi.htwm.de> <01a144d7-dba7-0d69-cccd-70959d4dda26@kdab.com> Message-ID: On 16 April 2017 at 20:51, Giuseppe D'Angelo wrote: > Il 16/04/2017 18:32, Corentin ha scritto: >> >> More on point: >> * You don't actually need to include anything from the STL to >> implement std::hash. > > You actually do: you need to see the primary template for > std::hash (otherwise you can't specialize it). Also, how to implement it > is another burden (see the other discussion). You don't need to include a header to do that: namespace std { template struct hash; } Now you can specialize hash for your own types. I don't think that violates any rule; it's not adding a declaration to namespace std, as that declaration is already there. From marc.mutz at kdab.com Sun Apr 16 21:08:44 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 16 Apr 2017 21:08:44 +0200 Subject: [Development] =?utf-8?q?How_to_include_Standard_Library_headers_?= =?utf-8?q?from_Qt_ones=3F?= In-Reply-To: References: <20170416131500.GC2491@klara.mpi.htwm.de> <01a144d7-dba7-0d69-cccd-70959d4dda26@kdab.com> Message-ID: On 2017-04-16 20:54, Ville Voutilainen wrote: > On 16 April 2017 at 20:51, Giuseppe D'Angelo > wrote: >> Il 16/04/2017 18:32, Corentin ha scritto: >>> >>> More on point: >>> * You don't actually need to include anything from the STL to >>> implement std::hash. >> >> You actually do: you need to see the primary template for >> std::hash (otherwise you can't specialize it). Also, how to implement >> it >> is another burden (see the other discussion). > > You don't need to include a header to do that: > > namespace std { > template struct hash; > } > > Now you can specialize hash for your own types. > > I don't think that violates any rule; it's not adding a declaration to > namespace std, as that > declaration is already there. Does the standard guarantee that this is the declaration for std::hash? For vector etc, implementations are allowed to add extra, defaulted template arguments. If an implementation makes use of that, e.g. to have a void slot there for SFINAE, then the above declaration is wrong. Also, it's not enough to have a std::hash primary template; you also need the std::hash specialisations for built-in (and enum) types, otherwise yoou may end up with "specialised after instantiation" errors, though that could be worked around by making std::hash::op() a template. I use that trick already for std::hash, to pick up any constexpr the underlying std::hash specialisation may provide. Thanks, Marc From samuel.gaist at edeltech.ch Sun Apr 16 21:48:26 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 16 Apr 2017 21:48:26 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <10085874.vcRdT34mlR@tjmaciei-mobl1> References: <10085874.vcRdT34mlR@tjmaciei-mobl1> Message-ID: <4A3EF1EB-A813-4FC5-960D-8E4085FF5CB8@edeltech.ch> > On 16 Apr 2017, at 17:53, Thiago Macieira wrote: > > Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu: >> That again makes me wonder, why did Qt diverge from that? > > We didn't diverge. We never had that. The Qt style predates the Standard > Library having relevance in Qt. When the first QHash-like class was added, it > was just like that. > > Also remember that at the time, you wouldn't think of a Standard Library > associative container as such. It was just a sequential container that held a > std::pair, with some convenience functions for searching the first of the pair. > Returning a pair was a consequence of that. I don't know if it was intentional > thinking, or it just happened. > >> And... if Qt plans to change it in Qt6? > > No, cannot due to source compatibility. Ever. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi, Just in case, there’s a work in progress at https://codereview.qt-project.org/#/c/151511/ to add these "missing" iterators to QHash and QMap. Cheers, Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From markg85 at gmail.com Mon Apr 17 00:09:16 2017 From: markg85 at gmail.com (Mark Gaiser) Date: Mon, 17 Apr 2017 00:09:16 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <10085874.vcRdT34mlR@tjmaciei-mobl1> References: <10085874.vcRdT34mlR@tjmaciei-mobl1> Message-ID: On Sun, Apr 16, 2017 at 5:53 PM, Thiago Macieira wrote: > Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu: >> That again makes me wonder, why did Qt diverge from that? > > We didn't diverge. We never had that. The Qt style predates the Standard > Library having relevance in Qt. When the first QHash-like class was added, it > was just like that. With regards to QHash vs std::unordered_map, yes. But STL also has std::map which certainly predates Qt and also gives back an std::pair. > > Also remember that at the time, you wouldn't think of a Standard Library > associative container as such. It was just a sequential container that held a > std::pair, with some convenience functions for searching the first of the pair. > Returning a pair was a consequence of that. I don't know if it was intentional > thinking, or it just happened. > >> And... if Qt plans to change it in Qt6? > > No, cannot due to source compatibility. Ever. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From markg85 at gmail.com Mon Apr 17 00:16:54 2017 From: markg85 at gmail.com (Mark Gaiser) Date: Mon, 17 Apr 2017 00:16:54 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <4A3EF1EB-A813-4FC5-960D-8E4085FF5CB8@edeltech.ch> References: <10085874.vcRdT34mlR@tjmaciei-mobl1> <4A3EF1EB-A813-4FC5-960D-8E4085FF5CB8@edeltech.ch> Message-ID: On Sun, Apr 16, 2017 at 9:48 PM, Samuel Gaist wrote: > >> On 16 Apr 2017, at 17:53, Thiago Macieira wrote: >> >> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu: >>> That again makes me wonder, why did Qt diverge from that? >> >> We didn't diverge. We never had that. The Qt style predates the Standard >> Library having relevance in Qt. When the first QHash-like class was added, it >> was just like that. >> >> Also remember that at the time, you wouldn't think of a Standard Library >> associative container as such. It was just a sequential container that held a >> std::pair, with some convenience functions for searching the first of the pair. >> Returning a pair was a consequence of that. I don't know if it was intentional >> thinking, or it just happened. >> >>> And... if Qt plans to change it in Qt6? >> >> No, cannot due to source compatibility. Ever. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > Hi, > > Just in case, there’s a work in progress at > > https://codereview.qt-project.org/#/c/151511/ > > to add these "missing" iterators to QHash and QMap. Ohh, that's great! One question. Would it be possible and sane to - by default - provide it as the patch implements it there, but with the addition of a define that can influence the behavior of the iterators? For instance a "QT_STL_COMPATIBLE_ITERATORS" (just made that up, doesn't exist) when defined gives the iterators begin/constBegin/cbegin/enc/constEnd/cend STL compatible output (so give an std::pair with key and value)? When not defined (the default i guess) it falls back to what Qt uses now. Providing this option makes the Qt containers easier to use with STL algorithms. From thiago.macieira at intel.com Mon Apr 17 00:55:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Apr 2017 15:55:44 -0700 Subject: [Development] How to include Standard Library headers from Qt ones? In-Reply-To: References: <01a144d7-dba7-0d69-cccd-70959d4dda26@kdab.com> Message-ID: <7390410.s96I7bziW1@tjmaciei-mobl1> Em domingo, 16 de abril de 2017, às 11:54:03 PDT, Ville Voutilainen escreveu: > On 16 April 2017 at 20:51, Giuseppe D'Angelo wrote: > > Il 16/04/2017 18:32, Corentin ha scritto: > >> More on point: > >> * You don't actually need to include anything from the STL to > >> > >> implement std::hash. > > > > You actually do: you need to see the primary template for > > std::hash (otherwise you can't specialize it). Also, how to implement it > > is another burden (see the other discussion). > > You don't need to include a header to do that: > > namespace std { > template struct hash; > } That doesn't work if it's std::__1::hash. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Apr 17 01:00:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Apr 2017 16:00:39 -0700 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: <10085874.vcRdT34mlR@tjmaciei-mobl1> Message-ID: <2839605.949fGYFrym@tjmaciei-mobl1> Em domingo, 16 de abril de 2017, às 15:09:16 PDT, Mark Gaiser escreveu: > On Sun, Apr 16, 2017 at 5:53 PM, Thiago Macieira > > wrote: > > Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu: > >> That again makes me wonder, why did Qt diverge from that? > > > > We didn't diverge. We never had that. The Qt style predates the Standard > > Library having relevance in Qt. When the first QHash-like class was added, > > it was just like that. > > With regards to QHash vs std::unordered_map, yes. > But STL also has std::map which certainly predates Qt and also gives > back an std::pair. I was referring to std::map and QDict. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Apr 17 00:59:55 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Apr 2017 15:59:55 -0700 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: <4A3EF1EB-A813-4FC5-960D-8E4085FF5CB8@edeltech.ch> Message-ID: <2606882.HqgOjlLZyd@tjmaciei-mobl1> Em domingo, 16 de abril de 2017, às 15:16:54 PDT, Mark Gaiser escreveu: > Ohh, that's great! > > One question. Would it be possible and sane to - by default - provide > it as the patch implements it there, but with the addition of a define > that can influence the behavior of the iterators? Most llikely no. Just look at the problem that QT_STRICT_ITERATORS causes. We shouldn't make the same mistake again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Shawn.Rutledge at qt.io Mon Apr 17 01:39:26 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Sun, 16 Apr 2017 23:39:26 +0000 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: <0709AD4C-0D67-41E8-BB0A-CA5658172DF9@qt.io> <6169817.IK04xeHo7i@tjmaciei-mobl1> Message-ID: <74915777-95C3-41BB-9841-417BECC30391@qt.io> On Apr 15, 2017, at 19:14, Randall O'Reilly wrote: > On Apr 16, 2017, at 1:28 AM, Thiago Macieira wrote: >> >> Em sexta-feira, 14 de abril de 2017, às 22:38:25 PDT, Randall O'Reilly >> escreveu: >>> One of the major innovations in Go is that it avoids all of those problems. >>> You only ever write things once, in one place (no .h vs. .cpp), and, like >>> an interpreted language, the only distribution mechanism *is the source >>> itself*. There is no such thing as binary compatibility. >> >> Because there's no such thing as binary distribution in the first place. That >> means you cannot provide a component without the source. If we insisted on all >> Qt users simply recompiling every time that Qt changed, then we could apply >> the same to C++ and only retain source compatibility. That is, after all, what >> Boost does. > > That’s why the Go folks worry so much about super-fast compile times.. I like that. I like how it’s so easy to import libraries of source code from github that you didn’t even need to download ahead of time, let alone have them installed as dependencies. But how much optimizing can such a compiler afford to do, if speed is the main priority? And static linking is both a blessing and a curse. >> By the way, is it even possible to distribute a binary application? > > Yes, the final product of the compilation process is a (fat) static binary. Well that gets me thinking more about the memory cost of that. If you run KDE or any other big collection of independent Qt programs at the same time, then if they are statically linked, each one may be smaller than the whole set of Qt dynamic libs that you’d end up loading if you are using dynamic libs, but some code is being duplicated among those static binaries too. Whereas if you dynamically link, Qt takes up a decent sized chunk of memory, but at least each program that links with it can be small, if it doesn’t have much unique code of its own. So the more Qt programs you multitask with, the more the dynamic libs make sense, even if there are some functions that none of those programs use. Now you will say you’ve got this many gigs of RAM and you don’t care. Well, there is still the cost of cache misses. It impacts performance when your OS is switching to a different process, and the processor has to fetch the same code from a different memory address just because it’s a different copy. And you’re still neglecting the smaller embedded systems which don’t have as much RAM. And there’s the general inelegance of letting software expand to fill its container, even doing the same old jobs we knew how to implement much more efficiently 20 years ago. I don’t think the fat static binaries are what I want too many of on my system, until somebody figures out how to do de-duplication of blocks of code, either at the granularity of some arbitrary block size, or better yet, have the runtime linker (or the kernel maybe?) break up programs and dynamic libs into individual functions, hash the machine code for each function, and deduplicate them on that basis. (I wrote up QTBUG-59619 for discussion about that recently.) Does anybody know of any research being done on that? It is relevant both on disk and in memory. Top priority is for collections of programs to share common functions, and yet it’s easier if it’s already been done on the SSD, so that less work needs to be done at load time. So one answer is use today’s deduplicating filesystems like btrfs, xfs or ZFS, because the kernel already knows not to load the same block from disk twice into two memory blocks… yeah I already thought of that, of course. I do use ZFS, but the usual advice is you probably can’t afford to use deduplication: it takes a lot of RAM just to run the filesystem if you turn on that feature. (So I haven’t tried yet, because I read that.) And it works at a block level, where a block may be 4K or more. I think it’s not very likely when you statically link two different programs with the same static library, that code blocks within the static library will just happen to be aligned to the block size on the disk, will it? There would have to be some effort to make that happen. Maybe a new kind of static linking which prioritizes alignment and grouping of “text” blocks into most-likely-reusable sections? Only if something like that were done, would static binaries make sense to be used universally, IMO. For now they only make sense as a workaround for DLL hell on Windows (because most software there is proprietary anyway, and the package management is so primitive that you can’t just ask the system to upgrade all your software, including Qt, and rely on binary compatibility to keep it all working), or in cases when you know you only need to run one Qt program on the system, or when the system doesn’t support dynamic libs very well (the mobile platforms for example - and it’s their loss that they made it like that, as well as a big pain for us.) They save the developer some trouble, but at such an expense for the user. From jhihn at gmx.com Mon Apr 17 03:25:49 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 17 Apr 2017 03:25:49 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F Message-ID: I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, etc]) don't use an interface? I recently moved some code from ints to floats, and I had to change far more code than I should have had to. My proposal is to change QRect to QRectI, and make QRect an interface. In the past, I think I remember some pain points between QList and QVector, (or was it QMap, QHash?) which should be QIterable (QIndexable)? Similarly all the string types. I'm not fan of MS's Ieverything, but I think base classes/interfaces are under used in Qt. Why aren't there more of them? From jhihn at gmx.com Mon Apr 17 04:02:30 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 17 Apr 2017 04:02:30 +0200 Subject: [Development] As Qt contemplates its future.. In-Reply-To: References: <2257337.m0j1eRqRdy@localhost.localdomain> <209381492079086@web53g.yandex.ru> <214901492079139@web53g.yandex.ru>, Message-ID: You're going a lot a mental masturbation there. While it's a lot of fun, it would be a tremendous effort to make . those sweeping changes. I would focus on how to to get there iteratively. A few other comments: - C++ works the same way everywhere. It's on more platforms than Java and .NET. - The C++ is at a lower level than Java or .NET, so dependencies are less impacted by your runtime and garbage collection is consistent. - C++'s proposed #import directive will help compile times (is this your 'bloat'?) Things I'd like: - I'd like to see Qt target web like Wt does (Witty) or QMLWeb - I think C++ is falling out of favor with a lot of new developers. Qt should be more JavasScripty, but like how QML does this, I think that should sit above C++. - The idea of transpiling is really taking off. Multiple "languages" transpile to JS, for execution in a browser. I don't know much about creating a compiler, but something like a Python with an even more simple syntax, though I'm sure people would suggest Go, Rust, JS, or whatever. Writing in that 'proto' language (but not ugly like assembly) would compiler to a proper language. It's be like Qt in a way, like .NET without needing a CLR. What this has to do with Qt-actual, I'm not sure. Maybe write once, compile to any language, then compile anywhere? Imagine Qt `in` .NET or Java. I really hate that we keep dividing the efforts of developers and soloing them in platforms. If I write code, it should be usable by anyone on any platform, Oracle, Microsoft be damned. As for "cruft" I think they are just specializations, which provide significant value to those who need them. > Sent: Thursday, April 13, 2017 at 8:02 AM > From: "Randall O'Reilly" > To: "Konstantin Tokarev" > Cc: "development at qt-project.org" > Subject: Re: [Development] As Qt contemplates its future.. > > With the recent language explosion, there are now languages to fit everyone’s biases and aesthetics. This also means that there is an endless potential for language wars, which I’m sure nobody wants to rehash on this list. My point is just that Go represents a particular set of choices that I think is very compatible with a certain (possibly large) segment of the Qt user-base — those who favor clarity, simplicity, readability, over e.g., extreme performance optimization or having every different kind of possible language feature at one’s disposal (aka “language bloat”). As C++ is seemingly in a constant state of reinvention lately, and is now massively bloated and unwieldy in some people’s estimation, it might be an opportune moment to consider a “reboot” — a fresh new framework unburdened by all that cruft. My sense is that Go has made some really excellent (and hard) choices that benefit from all the different language experiments and experience (and especially the limitations of C++), and that one major thing holding it back is lack of a decent GUI framework, so that Qt could really make a big difference there. Furthermore, Qt itself has a kind of bloat problem of its own, having evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now 3D), so it could possibly benefit from a fresh start / reboot as well. > > Perhaps building from the ground-up on a core scenegraph framework that can support 2D *and* 3D, with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax to do the widget etc painting in a resolution-independent, style-based manner (no more high-dpi hassles — future proof resolution independence).. I’m sure everyone could come up with a good wish list based on all the experience with Qt so far :) > > - Randy > > > On Apr 13, 2017, at 7:25 PM, Konstantin Tokarev wrote: > > > > > > > > 13.04.2017, 13:25, "Konstantin Tokarev" : > >> 13.04.2017, 12:32, "Nikita Krupenko" : > >>> On четверг, 13 апреля 2017 г. 08:24:39 EEST Randall O'Reilly wrote: > >>>> In the context of all this recent discussion about modernizing Qt to > >>>> accommodate updates to C++, has anyone given any thought to the radical > >>>> idea of creating a brand new product using Go? Go (golang) is rapidly > >>>> gaining in popularity, and seems to embody everything that is great about > >>>> Qt (simplicity, elegance, strong concern for readability, etc), and it has > >>>> many features of Qt built directly into the language (reflection, i.e., > >>>> moc, goroutines and channels for signal / slot functionality). One of its > >>>> main limitations is lack of a dominant, fully-featured GUI toolkit. There > >>>> are existing bindings to Qt and QML, but it seems like creating a brand new > >>>> native GUI framework in the Qt mold could be a great opportunity to make a > >>>> huge impact on a language that has a bright future. All the lessons > >>>> learned as Qt has evolved over the years could be consolidated into a fresh > >>>> new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / > >>>> Vulkan, etc) as the underlying renderer, or something like that… Obviously > >>>> a huge undertaking, but something that could produce transformative effects > >>>> for future programmers (whereas it seems that continued improvements to the > >>>> C++ product are likely to be much more incremental). Maybe some funding > >>>> from Google could be obtained to support such an endeavor? > >>>> > >>>> - Randy > >>> > >>> Why Go? Isn't Rust more close to the C++ niche? > >> > >> Rust does not have even GCC frontend, so is even less portable than C++ > > > > Ooops, I meant "than Go" > > > >> > >>> _______________________________________________ > >>> Development mailing list > >>> Development at qt-project.org > >>> http://lists.qt-project.org/mailman/listinfo/development > >> > >> -- > >> Regards, > >> Konstantin > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > -- > > Regards, > > Konstantin > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From chgans at gna.org Mon Apr 17 04:47:08 2017 From: chgans at gna.org (Ch'Gans) Date: Mon, 17 Apr 2017 14:47:08 +1200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: Message-ID: On 17 April 2017 at 13:25, Jason H wrote: > I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, etc]) don't use an interface? > I recently moved some code from ints to floats, and I had to change far more code than I should have > had to. > > My proposal is to change QRect to QRectI, and make QRect an interface. This is only the tip of the iceberg, there's the storage type and then the dimension, Qt has specialised class for int and double in 2 and/or 3 dimensions, and then there's the family of 2+ dimensions with float (QVector2/3/4D, QMatrixNxM, QQuaternion, ...). I saw a patch not so long ago about bringing in qfloat16, ... And I won't mention coordinate systems, ... Coming with a set of interfaces that plays well together is not an easy task and things get complicated very quickly. Have a quick read at boost.geometry "design rational"[1], it looks very sexy at first, but once you start using it, you realised how cumbersome it can get. IMHO, there are different use-cases, just to list a few of them: - 1. GUI/painting tasks (int in 2D 'top-left' CS) - 2. 3D rendering tasks (float in 2 or 3D) - 3. Quick and inexact geometry (double in 2 or 3D) - 4. Exact and robust geometry (other in nD) - 5. [insert your own here] I don't believe that you can cover them them all with just one set of interfaces, different needs require different solutions. I guess there is lot of history behind Qt current API, it all started with managing pixels on a screen, didn't it? I personally would love to see a non-gui module that sits b/w 4 and 5 with "native" support for non-linear curves in 2/3D space... Chris [1] http://www.boost.org/doc/libs/1_61_0/libs/geometry/doc/html/geometry/design.html > > In the past, I think I remember some pain points between QList and QVector, (or was it QMap, QHash?) which should be QIterable (QIndexable)? Similarly all the string types. > > I'm not fan of MS's Ieverything, but I think base classes/interfaces are under used in Qt. Why aren't there more of them? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon Apr 17 05:44:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Apr 2017 20:44:17 -0700 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: Message-ID: <2514833.dyiYTnD4Et@tjmaciei-mobl1> Em domingo, 16 de abril de 2017, às 18:25:49 PDT, Jason H escreveu: > I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, > etc]) don't use an interface? I recently moved some code from ints to > floats, and I had to change far more code than I should have had to. If you're thinking of a template class and make each of those just an instantiation of the template, it could be done, and yet wouldn't help you a lot. Each instantiation is a distinct type. Your code would need to be adapted. It wouldn't be easy for us either, as the algorithms are subtly different. The rectangle and size, for example, store the inclusive bottom-right coordinate, whereas the floating point ones store them exclusive. If you're thinking of base class with inheritance and virtuals, then you have to learn a lot about C++ efficiency. Those classes are too small for virtuals. It would be bad API design and an incredible overhead for little gain. As I mentioned, the classes have actually little in common between one another. > My proposal is to change QRect to QRectI, and make QRect an interface. That's a vague suggestion. Make a concrete proposal, please. Without virtuals, of course. > I'm not fan of MS's Ieverything, but I think base classes/interfaces are > under used in Qt. Why aren't there more of them? You are thinking of classes with virtuals. QRect has no virtuals and shall never have them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Mon Apr 17 08:02:15 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 17 Apr 2017 08:02:15 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: <2514833.dyiYTnD4Et@tjmaciei-mobl1> References: , <2514833.dyiYTnD4Et@tjmaciei-mobl1> Message-ID: Maybe templates are the way to go. But I just had to change some lines because I was using vectors and Qt was using QList. I'd like to eliminate the need/cost for QList::toVector() and QVector::toList(). If there was a base that provided the basics so that I don't have to worry about it's representation in my code, I want the developer (usually me, but anyone using my functions) to be the one that makes that decision. You're right I don't know how C++ handles virtuals, but should I care? This is OOP, I want to use OOP. You're telling me that because the language/compiler implements something poorly, that I can't use OOP? > Sent: Sunday, April 16, 2017 at 11:44 PM > From: "Thiago Macieira" > To: development at qt-project.org > Subject: Re: [Development] Lack of base classes/interfaces? Q*, Q*F > > Em domingo, 16 de abril de 2017, às 18:25:49 PDT, Jason H escreveu: > > I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, > > etc]) don't use an interface? I recently moved some code from ints to > > floats, and I had to change far more code than I should have had to. > > If you're thinking of a template class and make each of those just an > instantiation of the template, it could be done, and yet wouldn't help you a > lot. Each instantiation is a distinct type. Your code would need to be > adapted. > > It wouldn't be easy for us either, as the algorithms are subtly different. The > rectangle and size, for example, store the inclusive bottom-right coordinate, > whereas the floating point ones store them exclusive. > > If you're thinking of base class with inheritance and virtuals, then you have > to learn a lot about C++ efficiency. Those classes are too small for virtuals. > It would be bad API design and an incredible overhead for little gain. As I > mentioned, the classes have actually little in common between one another. > > > My proposal is to change QRect to QRectI, and make QRect an interface. > > That's a vague suggestion. Make a concrete proposal, please. Without virtuals, > of course. > > > I'm not fan of MS's Ieverything, but I think base classes/interfaces are > > under used in Qt. Why aren't there more of them? > > You are thinking of classes with virtuals. QRect has no virtuals and shall > never have them. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From andre at familiesomers.nl Mon Apr 17 08:10:28 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 17 Apr 2017 08:10:28 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: <2514833.dyiYTnD4Et@tjmaciei-mobl1> Message-ID: <2107663d-7898-dab1-8ab8-d913ee19ac70@familiesomers.nl> Op 17/04/2017 om 08:02 schreef Jason H: > Maybe templates are the way to go. But I just had to change some lines because I was using vectors and Qt was using QList. I'd like to eliminate the need/cost for QList::toVector() and QVector::toList(). If there was a base that provided the basics so that I don't have to worry about it's representation in my code, I want the developer (usually me, but anyone using my functions) to be the one that makes that decision. Well, I think most people here would agree QList was not the best choice in retrospect. > > You're right I don't know how C++ handles virtuals, but should I care? This is OOP, I want to use OOP. You're telling me that because the language/compiler implements something poorly, that I can't use OOP? There are many people for who real-world performance means a lot more that your wish to use "OOP" - for whatever understanding you have of that concept. Still, I'd like to see your proposal to to consolidate QRect and QRectF into one hierarchy using that. I don't see that working out, but perhaps I am missing something. What would the width() method return, for instance? André > > >> Sent: Sunday, April 16, 2017 at 11:44 PM >> From: "Thiago Macieira" >> To: development at qt-project.org >> Subject: Re: [Development] Lack of base classes/interfaces? Q*, Q*F >> >> Em domingo, 16 de abril de 2017, às 18:25:49 PDT, Jason H escreveu: >>> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, >>> etc]) don't use an interface? I recently moved some code from ints to >>> floats, and I had to change far more code than I should have had to. >> If you're thinking of a template class and make each of those just an >> instantiation of the template, it could be done, and yet wouldn't help you a >> lot. Each instantiation is a distinct type. Your code would need to be >> adapted. >> >> It wouldn't be easy for us either, as the algorithms are subtly different. The >> rectangle and size, for example, store the inclusive bottom-right coordinate, >> whereas the floating point ones store them exclusive. >> >> If you're thinking of base class with inheritance and virtuals, then you have >> to learn a lot about C++ efficiency. Those classes are too small for virtuals. >> It would be bad API design and an incredible overhead for little gain. As I >> mentioned, the classes have actually little in common between one another. >> >>> My proposal is to change QRect to QRectI, and make QRect an interface. >> That's a vague suggestion. Make a concrete proposal, please. Without virtuals, >> of course. >> >>> I'm not fan of MS's Ieverything, but I think base classes/interfaces are >>> under used in Qt. Why aren't there more of them? >> You are thinking of classes with virtuals. QRect has no virtuals and shall >> never have them. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon Apr 17 08:13:35 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Apr 2017 23:13:35 -0700 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: <2514833.dyiYTnD4Et@tjmaciei-mobl1> Message-ID: <16402479.qURIOpDy0R@tjmaciei-mobl1> Em domingo, 16 de abril de 2017, às 23:02:15 PDT, Jason H escreveu: > You're right I don't know how C++ handles virtuals, but should I care? This > is OOP, I want to use OOP. You're telling me that because the > language/compiler implements something poorly, that I can't use OOP? To make a long story short: yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alex at vikingsoft.eu Mon Apr 17 09:30:35 2017 From: alex at vikingsoft.eu (Alejandro Exojo) Date: Mon, 17 Apr 2017 09:30:35 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: Message-ID: <2244647.iss7YtiiGb@walt> On Monday 17 April 2017 03:25:49 Jason H wrote: > I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, > etc]) don't use an interface? I recently moved some code from ints to > floats, and I had to change far more code than I should have had to. > > My proposal is to change QRect to QRectI, and make QRect an interface. Have you thought this through? What would that interface or base class return for x()/y()/width(), etc? Classes like this are normally named "value classes" because you should consider them like like regular values that the language provides. That is, like int or float, for example, which is very appropriate for the case that you bring. Do you really think that there should be a base class for int and float? Some languages have that, but follow very different design principles. You should really explain which kind of code did you change, because just recently I adjusted code from using a key press event to a touch event, and the point had to change from QPoint to QPointF, and the changes were minimal. This wasn't explained to me, but I just found it natural. Also: https://wiki.qt.io/API_Design_Principles#Static_Polymorphism > In the past, I think I remember some pain points between QList and QVector, > (or was it QMap, QHash?) which should be QIterable (QIndexable)? Similarly > all the string types. Again I don't see which your problem was. All the containers have a very similar API, and the string types too. The algorithms in the standard library go to the extent that work with any container (including Qt containers) that provides some features and don't need a base class. And you don't need to be a low-level C++ developer that crafts algorithms and writes containers to end up writing code like this, or to see it valuable. Some time ago I did a simple proof of concept that used the same code to draw with QPainter on a QWidget, QQuickPaintedItem and QRasterWindow. I did it when I found the existence of QRasterWindow, saw the similarity of API, and though "this could be interesting". So sorry, you will have to explain more details of what your problem was, because it's not clear at all (at least to me) what is so problematic. You can use the same kind of container in a foreach or range for loop. You can use the same kind of iterator. QList has a lot of convenience API that QVector gained as well for easing the porting. So what's left? -- Viking Software, Qt and C++ developers for hire http://www.vikingsoft.eu From marc.mutz at kdab.com Mon Apr 17 09:30:23 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 17 Apr 2017 09:30:23 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <2606882.HqgOjlLZyd@tjmaciei-mobl1> References: <2606882.HqgOjlLZyd@tjmaciei-mobl1> Message-ID: <201704170930.23444.marc.mutz@kdab.com> On Monday 17 April 2017 00:59:55 Thiago Macieira wrote: > Em domingo, 16 de abril de 2017, às 15:16:54 PDT, Mark Gaiser escreveu: > > Ohh, that's great! > > > > > > > > One question. Would it be possible and sane to - by default - provide > > it as the patch implements it there, but with the addition of a define > > that can influence the behavior of the iterators? > > Most llikely no. Just look at the problem that QT_STRICT_ITERATORS causes. > We shouldn't make the same mistake again. The problem with QT_STRICT_ITERATORS is _not_ that they are changing begin() and end(), but that a) classes that shouldn't be (non-polymorphic ones), are exported, thus breaking patterns that are deeply ingrained in C++ developers (inline function no longer are inline, e.g.) and b) that classes that shouldn't be (non-polymorphic ones with public dtor), are inherited. _These_ are the things that need fixing, not QT_STRICT_ITERATORS, or a hypothetical QT_STL_COMPATIBLE_ITERSTORS, even though I consider the former, too, a kludge. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From annulen at yandex.ru Mon Apr 17 13:24:25 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 17 Apr 2017 14:24:25 +0300 Subject: [Development] State of LGPL exception after migration to LGPLv3 Message-ID: <9256451492428265@web20m.yandex.ru> Hello, There is LGPL_EXCEPTION.txt that says: ------------- As an additional permission to the GNU Lesser General Public License version 2.1, the object code form of a "work that uses the Library" may incorporate material from a header file that is part of the Library. You may distribute such object code under terms of your choice, provided that: (i) the header files of the Library have not been modified; and (ii) the incorporated material is limited to numerical parameters, data structure layouts, accessors, macros, inline functions and templates; and (iii) you comply with the terms of Section 6 of the GNU Lesser General Public License version 2.1. ------------- However, now Qt does not use LGPL 2.1. Therefore, following questions arise: 1. Is it still legal to incorporate "inline functions and templates" into code not covered by LGPLv3? In particular, I'm interested in qAsConst 2. Should LGPL_EXCEPTION.txt be updated? -- Regards, Konstantin From apoenitz at t-online.de Mon Apr 17 12:31:42 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 17 Apr 2017 12:31:42 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: <2107663d-7898-dab1-8ab8-d913ee19ac70@familiesomers.nl> References: <2514833.dyiYTnD4Et@tjmaciei-mobl1> <2107663d-7898-dab1-8ab8-d913ee19ac70@familiesomers.nl> Message-ID: <20170417103142.GB1835@klara.mpi.htwm.de> On Mon, Apr 17, 2017 at 08:10:28AM +0200, André Somers wrote: > Op 17/04/2017 om 08:02 schreef Jason H: > > Maybe templates are the way to go. But I just had to change some > > lines because I was using vectors and Qt was using QList. I'd like > > to eliminate the need/cost for QList::toVector() and > > QVector::toList(). If there was a base that provided the basics so > > that I don't have to worry about it's representation in my code, I > > want the developer (usually me, but anyone using my functions) to be > > the one that makes that decision. > Well, I think most people here would agree QList was not the best > choice in retrospect. > > > > You're right I don't know how C++ handles virtuals, but should I > > care? This is OOP, I want to use OOP. You're telling me that because > > the language/compiler implements something poorly, that I can't use > > OOP? > There are many people for who real-world performance means a lot more > that your wish to use "OOP" - for whatever understanding you have of > that concept. Still, I'd like to see your proposal to to consolidate > QRect and QRectF into one hierarchy using that. I don't really see this happen, either, but one thing that could be done is to make the implementations of QRect and QRectF more similar (and having the QRect version generate less code for typical operations) by shifting the values stored in the x2 and y2 members by one, i.e. start with - Q_DECL_CONSTEXPR QRect() Q_DECL_NOTHROW : x1(0), y1(0), x2(-1), y2(-1) {} + Q_DECL_CONSTEXPR QRect() Q_DECL_NOTHROW : x1(0), y1(0), x2(0), y2(0) {} and go from there. It's a bit less straightforward than it might appear as there are various related tests that practically test only the behaviour of (undefined, *cough*) signed integer overflow, but to me it looks like a harmless microoptimization in that area. > >> It wouldn't be easy for us either, as the algorithms are subtly > >> different. The rectangle and size, for example, store the inclusive > >> bottom-right coordinate, whereas the floating point ones store them > >> exclusive. ... fixing that. Andre' From andre at familiesomers.nl Mon Apr 17 15:17:55 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 17 Apr 2017 15:17:55 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: <20170417103142.GB1835@klara.mpi.htwm.de> References: <2514833.dyiYTnD4Et@tjmaciei-mobl1> <2107663d-7898-dab1-8ab8-d913ee19ac70@familiesomers.nl> <20170417103142.GB1835@klara.mpi.htwm.de> Message-ID: <4b0c9fd3-eed5-7a2e-ddc9-14131f1012f9@familiesomers.nl> Op 17/04/2017 om 12:31 schreef André Pönitz: > On Mon, Apr 17, 2017 at 08:10:28AM +0200, André Somers wrote: >> >>> You're right I don't know how C++ handles virtuals, but should I >>> care? This is OOP, I want to use OOP. You're telling me that because >>> the language/compiler implements something poorly, that I can't use >>> OOP? >> There are many people for who real-world performance means a lot more >> that your wish to use "OOP" - for whatever understanding you have of >> that concept. Still, I'd like to see your proposal to to consolidate >> QRect and QRectF into one hierarchy using that. > I don't really see this happen, either, but one thing that could be > done is to make the implementations of QRect and QRectF more similar > (and having the QRect version generate less code for typical operations) > by shifting the values stored in the x2 and y2 members by one, i.e. > start with > > - Q_DECL_CONSTEXPR QRect() Q_DECL_NOTHROW : x1(0), y1(0), x2(-1), y2(-1) {} > + Q_DECL_CONSTEXPR QRect() Q_DECL_NOTHROW : x1(0), y1(0), x2(0), y2(0) {} > > and go from there. > > It's a bit less straightforward than it might appear as there are > various related tests that practically test only the behaviour of > (undefined, *cough*) signed integer overflow, but to me it looks > like a harmless microoptimization in that area. Well, that's mostly just implementation details. What I am more curious for is how Jason proposes to hande the differences in return value types between QRect and QRectF's methods. After all, the former returns int for things like x, y, width and height, while the latter returns qreal... André From mardy at users.sourceforge.net Mon Apr 17 17:50:32 2017 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 17 Apr 2017 18:50:32 +0300 Subject: [Development] Adding Q_GADGET here and there In-Reply-To: <2898248.6xxIf1ZGPM@maurice> References: <53946074-d565-bf06-0e84-a75df5c57393@users.sourceforge.net> <2898248.6xxIf1ZGPM@maurice> Message-ID: <9f253bfb-876d-d718-59f7-08d28bd3f14c@users.sourceforge.net> On 16/04/2017 21:13, Olivier Goffart wrote: > > Q_GADGET's overhead is basically the cost of the QMetaObject. So it's there, > but it's quite small. > If there is an use for a class to be a Q_GADGET, I think it should be added. For the record: https://codereview.qt-project.org/#/c/191777/ Ciao, Alberto From thiago.macieira at intel.com Mon Apr 17 18:07:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 09:07:11 -0700 Subject: [Development] State of LGPL exception after migration to LGPLv3 In-Reply-To: <9256451492428265@web20m.yandex.ru> References: <9256451492428265@web20m.yandex.ru> Message-ID: <3651384.33rW8ZPOfs@tjmaciei-mobl1> Em segunda-feira, 17 de abril de 2017, às 04:24:25 PDT, Konstantin Tokarev escreveu: > 1. Is it still legal to incorporate "inline functions and templates" into > code not covered by LGPLv3? In particular, I'm interested in qAsConst The LGPLv3 text contains the equivalent exception. See LICENSE.LGPLv3 section 3 "Object Code Incorporating Material from Library Header Files." -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Apr 17 18:08:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 09:08:20 -0700 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <201704170930.23444.marc.mutz@kdab.com> References: <2606882.HqgOjlLZyd@tjmaciei-mobl1> <201704170930.23444.marc.mutz@kdab.com> Message-ID: <18894086.giWSYL5Ga8@tjmaciei-mobl1> Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz escreveu: > The problem with QT_STRICT_ITERATORS is _not_ that they are changing begin() > and end(), Actually, it was. You can't use QT_STRICT_ITERATORS in one TU and not in other, regardless of exporting or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Apr 17 18:48:26 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 17 Apr 2017 18:48:26 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <18894086.giWSYL5Ga8@tjmaciei-mobl1> References: <201704170930.23444.marc.mutz@kdab.com> <18894086.giWSYL5Ga8@tjmaciei-mobl1> Message-ID: <201704171848.26105.marc.mutz@kdab.com> On Monday 17 April 2017 18:08:20 Thiago Macieira wrote: > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz escreveu: > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing > > begin() and end(), > > Actually, it was. You can't use QT_STRICT_ITERATORS in one TU and not in > other, regardless of exporting or not. Why? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From jhihn at gmx.com Mon Apr 17 19:33:06 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 17 Apr 2017 19:33:06 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: <2244647.iss7YtiiGb@walt> References: , <2244647.iss7YtiiGb@walt> Message-ID: > Sent: Monday, April 17, 2017 at 3:30 AM > From: "Alejandro Exojo" > To: development at qt-project.org > Subject: Re: [Development] Lack of base classes/interfaces? Q*, Q*F > > On Monday 17 April 2017 03:25:49 Jason H wrote: > > I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, > > etc]) don't use an interface? I recently moved some code from ints to > > floats, and I had to change far more code than I should have had to. > > > > My proposal is to change QRect to QRectI, and make QRect an interface. > > Have you thought this through? What would that interface or base class return > for x()/y()/width(), etc? Not really. I've been spending a lot of time in Python and I think that has twisted by brain around a bit. So that is my mistake. on any given day I'm using 3 languages from a set of 4 - C++, Java, Python, JS so I do get some mechanics confused, as well as not remembering the finer details of the particular language of the hour. After some more thought, I think what I need are C++ templates. So let me rephrase: Why not QRect and QRect? Also I'm still not sure though why there isn't an interface for QVector/QList? The main things are operator [], at(), size(), etc. From thiago.macieira at intel.com Mon Apr 17 19:38:36 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 10:38:36 -0700 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <201704171848.26105.marc.mutz@kdab.com> References: <18894086.giWSYL5Ga8@tjmaciei-mobl1> <201704171848.26105.marc.mutz@kdab.com> Message-ID: <1558884.4OvWjjB7LO@tjmaciei-mobl1> Em segunda-feira, 17 de abril de 2017, às 09:48:26 PDT, Marc Mutz escreveu: > On Monday 17 April 2017 18:08:20 Thiago Macieira wrote: > > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz escreveu: > > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing > > > begin() and end(), > > > > Actually, it was. You can't use QT_STRICT_ITERATORS in one TU and not in > > other, regardless of exporting or not. > > Why? Well, now it can, because of this: iterator begin(iterator = iterator()) Q_DECL_NOTHROW { return data(); } iterator end(iterator = iterator()) Q_DECL_NOTHROW { return data() + size; } Because of the parameter, the non-strict version calls begin(T*), whereas the strict one calls begin(QTypedArrayData::iterator). Those are two different functions, with different name manglings. When they are emitted out-of-line and merged at link time, you'll have two copies, not one. The difference is how the ABI returns the return value: a QTypedArrayData::iterator is returned by implicit reference, whereas a pointer is returned by value. In the former case, the caller passes an implicit parameter to the storage area for the called function. In the latter, there is no parameter. So if the two functions had the same parameters (and thus the same mangling), the caller of the non-strict would not pass anything for the first parameter, causing the called strict begin() function to dereference an uninitialised pointer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Apr 17 19:40:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 10:40:37 -0700 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: <2244647.iss7YtiiGb@walt> Message-ID: <9102936.AmtUYCGMmg@tjmaciei-mobl1> Em segunda-feira, 17 de abril de 2017, às 10:33:06 PDT, Jason H escreveu: > After some more thought, I think what I need are C++ templates. So let me > rephrase: Why not QRect and QRect? We should do that. See André P's email. > Also I'm still not sure though why there isn't an interface for > QVector/QList? The main things are operator [], at(), size(), etc. If by "interface" you mean a base class without virtuals, see https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/tools/ qgenericarray.h That's what this class was supposed to be. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Apr 17 19:50:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 10:50:34 -0700 Subject: [Development] Make qtstyleplugins an official module and release it Message-ID: <2165600.uyOFt0l2NH@tjmaciei-mobl1> Looks like we moved important functionality from qtbase to qtstyleplugins. Why wasn't it added to .gitmodules and included in the 5.7.0 and 5.8.0 releases? Can we fix it for 5.9.0? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From iamsergio at gmail.com Mon Apr 17 20:19:42 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 17 Apr 2017 19:19:42 +0100 Subject: [Development] Make qtstyleplugins an official module and release it In-Reply-To: <2165600.uyOFt0l2NH@tjmaciei-mobl1> References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> Message-ID: On Mon, Apr 17, 2017 at 6:50 PM, Thiago Macieira wrote: > Looks like we moved important functionality from qtbase to qtstyleplugins. Why > wasn't it added to .gitmodules and included in the 5.7.0 and 5.8.0 releases? IIRC, the gtk2 stuff was considered non-important (there's was a thread about this). But after reading today's qt-interest I think you're referring to the gtk3 style. That style simply doesn't exist, not even in qtstyleplugins. If we were to implement it it would probably go to qtbase. Regards, Sérgio Martins From annulen at yandex.ru Mon Apr 17 20:44:46 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 17 Apr 2017 21:44:46 +0300 Subject: [Development] Make qtstyleplugins an official module and release it In-Reply-To: References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> Message-ID: <2091411492454686@web39j.yandex.ru> 17.04.2017, 21:20, "Sérgio Martins" : > On Mon, Apr 17, 2017 at 6:50 PM, Thiago Macieira > wrote: >>  Looks like we moved important functionality from qtbase to qtstyleplugins. Why >>  wasn't it added to .gitmodules and included in the 5.7.0 and 5.8.0 releases? > > IIRC, the gtk2 stuff was considered non-important (there's was a > thread about this). > > But after reading today's qt-interest I think you're referring to the > gtk3 style. That style simply doesn't exist, not even in > qtstyleplugins. If we were to implement it it would probably go to > qtbase. FWIW, author of QtCurve gave up on GTK3 support, because things break with every new version. > > Regards, > Sérgio Martins > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Mon Apr 17 21:23:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 12:23:08 -0700 Subject: [Development] Make qtstyleplugins an official module and release it In-Reply-To: References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> Message-ID: <24078294.EJgQmvgWSo@tjmaciei-mobl1> On segunda-feira, 17 de abril de 2017 11:19:42 PDT Sérgio Martins wrote: > On Mon, Apr 17, 2017 at 6:50 PM, Thiago Macieira > > wrote: > > Looks like we moved important functionality from qtbase to qtstyleplugins. > > Why wasn't it added to .gitmodules and included in the 5.7.0 and 5.8.0 > > releases? > IIRC, the gtk2 stuff was considered non-important (there's was a > thread about this). > > But after reading today's qt-interest I think you're referring to the > gtk3 style. That style simply doesn't exist, not even in > qtstyleplugins. If we were to implement it it would probably go to > qtbase. So src/widgets/styles/qgtkstyle.cpp did not compile with Gtk3? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Tue Apr 18 00:01:10 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 18 Apr 2017 00:01:10 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F References: <2244647.iss7YtiiGb@walt> Message-ID: Alejandro Exojo wrote: > You should really explain which kind of code did you change, because just > recently I adjusted code from using a key press event to a touch event, > and the point had to change from QPoint to QPointF, and the changes were > minimal. This wasn't explained to me, but I just found it natural. Also: > > https://wiki.qt.io/API_Design_Principles#Static_Polymorphism And for the OP who is coming from Python: C++ templates can actually be used to duck-type things *at compile time*, and thus get some compile-time polymorphism without an inheritance relationship. So if foo is a template , then calling at(i) on an object of type T will call QVector::at(int) in foo and QList::at(int) in foo, simply because of the name. (Trying to instantiate the template with a class that does not have an at(int) method will of course fail to compile.) What will of course *NOT* work in C++ is to duck-type things *at runtime*. You cannot pass a QList to foo. Runtime polymorphism is (in general) only possible through virtual methods and inheritance. (And yes, I know about the possibilities to (ab)use QMetaObject for Q_OBJECTs or Q_GADGETs to get there. That is out of scope here.) Kevin Kofler From kevin.kofler at chello.at Tue Apr 18 00:05:30 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 18 Apr 2017 00:05:30 +0200 Subject: [Development] Make qtstyleplugins an official module and release it References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> <24078294.EJgQmvgWSo@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > So src/widgets/styles/qgtkstyle.cpp did not compile with Gtk3? No, it doesn't. The GTK+ 3 theming API is very different. Some Red Hat / Fedora developers have ported the Adwaita style (the default GNOME 3 style) to Qt natively, and that is chosen by default on GNOME 3 in Fedora (through a platform plugin also implemented by them: QGnomePlatform). I do not know of any Qt style able to draw an arbitrary GTK+ 3 style, it's only either the old GTK+ 2 QGtkStyle or the Adwaita port. Kevin Kofler From thiago.macieira at intel.com Tue Apr 18 00:39:36 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 15:39:36 -0700 Subject: [Development] Make qtstyleplugins an official module and release it In-Reply-To: References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> <24078294.EJgQmvgWSo@tjmaciei-mobl1> Message-ID: <3938983.fdtVyZZlVT@tjmaciei-mobl1> On segunda-feira, 17 de abril de 2017 15:05:30 PDT Kevin Kofler wrote: > Thiago Macieira wrote: > > So src/widgets/styles/qgtkstyle.cpp did not compile with Gtk3? > > No, it doesn't. The GTK+ 3 theming API is very different. > > Some Red Hat / Fedora developers have ported the Adwaita style (the default > GNOME 3 style) to Qt natively, and that is chosen by default on GNOME 3 in > Fedora (through a platform plugin also implemented by them: QGnomePlatform). Which is not part of Qt? Because I can't find QGnomePlatform. QGnomeTheme::themeHint has this: case QPlatformTheme::StyleNames: { QStringList styleNames; styleNames << QStringLiteral("fusion") << QStringLiteral("windows"); return QVariant(styleNames); } -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kuba at mareimbrium.org Tue Apr 18 03:46:02 2017 From: kuba at mareimbrium.org (Kuba Ober) Date: Mon, 17 Apr 2017 21:46:02 -0400 Subject: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017 Message-ID: Are -static -ltcg -debug-and-release x86 builds tested and supported? It seems that they are broken on at least MSVC 2015 and 2017, in both 5.7 and 5.8. That's using most recent production releases of either version of MSVC (no prereleases etc), and I build using most recent jom. For me; 5.8 in a debug build corrupts the heap early during static initialization and doesn't even get to main's body. A release build is will generally crash somewhere but due to lack of heap diagnostics it will get to run first, on a partially corrupted heap. 5.7 crashes in the release if you as much as use add a shortcut to a dummy widget and then return from main. Seems to be a different face of the same problem, although the debug version didn't crash. IIRC 5.6 was also crashing for me. Since this is reproducible on 2 different machines, and seems to point to a persistent problem - did anyone else run into it? I will file bug reports but would want to know first whether it's anything known. To be completely frank, I couldn't get any Qt version between 5.6 and 5.8, inclusive, to work under either MSVC 2015 or 2017 with -static -ltcg so it seems like an untested configuration that's exposing undefined behavior somewhere as the whole thing is globally optimized. I kinda need this to work. Unless I hear better ideas, I plan on stripping away code to see what it takes to make it not crash. With 5.8 it crashes even with no plugins linked in, the heap corruption is detected in a heap free from one of the Q_GLOBAL_STATICs in somewhere in Qt. Cheers, Kuba Ober From thiago.macieira at intel.com Tue Apr 18 04:26:02 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 19:26:02 -0700 Subject: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017 In-Reply-To: References: Message-ID: <20447299.kzHRIoPUIW@tjmaciei-mobl1> Em segunda-feira, 17 de abril de 2017, às 18:46:02 PDT, Kuba Ober escreveu: > Are -static -ltcg -debug-and-release x86 builds tested and supported? No and we will not test it. That will create a .lib file with no code. Only during the linking of your application will ALL the code be generated. I don't think we test -static either. > For me; 5.8 in a debug build corrupts the heap early during static > initialization and doesn't even get to main's body. A release build is will > generally crash somewhere but due to lack of heap diagnostics it will get > to run first, on a partially corrupted heap. Does the same problem happen with -static and without -ltcg? If it doesn't happen, then it's either a compiler bug or something completely unsupported. You'll have to debug yourself, sorry. > I will file bug reports but would want to know first whether it's anything > known. To be completely frank, I couldn't get any Qt version between 5.6 > and 5.8, inclusive, to work under either MSVC 2015 or 2017 with -static > -ltcg so it seems like an untested configuration that's exposing undefined > behavior somewhere as the whole thing is globally optimized. Don't file. We'll just close the bug as unsupported. File only if the problem persists when you use only one of -ltcg or -static. Not both. Or I can assign it back to you, if you're willing to work on identifying the problem. > I kinda need this to work. Unless I hear better ideas, I plan on stripping > away code to see what it takes to make it not crash. With 5.8 it crashes > even with no plugins linked in, the heap corruption is detected in a heap > free from one of the Q_GLOBAL_STATICs in somewhere in Qt. That would be welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Tue Apr 18 06:58:51 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 18 Apr 2017 04:58:51 +0000 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: <3355729.XLYieY6BcX@tjmaciei-mobl1> References: <1643490.9zMfjAF2Up@tjmaciei-mobl1> <3355729.XLYieY6BcX@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Thiago Macieira > Sent: torstaina 13. huhtikuuta 2017 22.48 > To: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Qt 5.10 schedule proposal > > Interleaving your two emails: > > > - Branch '5.6.3' from '5.6' at the end of May/beginning of June, > > 5.6.3 release target August 2017 > > - Qt 5.10 Feature Freeze: 8.8.2017 > > - Qt 5.10 Alpha Release: 31.8.2017 > > - Branch '5.9.1' from '5.9' at the end of July/beginning of August, > > 5.9.1 release target September 2017 > > - First Qt 5.10 Beta Release 5.10.2017 > > - Qt 5.10 RC 16.11.2017 > > - Branch '5.9.2' from '5.9' Nov 2017 > > - Qt 5.10 final release 30.11.2017 > > - Branch '5.6.4' from '5.6' Jan 2018 > > Any chance to pull in 5.6.3 release to the first half of the year? We've already > got the first 5.9 beta out, so the release should happen hopefully by the end > of May. We should be able to branch 5.6.3 and release sooner than August. > That would also help alleviate the work of both a 5.6.3 and 5.10 alpha close > together. Unfortunately there isn't. We need to get Qt5.9 out first & then start doing 5.6.3 and 5.10 and so on there isn't enough time to get 5.6.3 out before summer holidays. But we should be able to get one or two 5.6.3 snapshots (or release candidates) out before summer holidays. That way we should be quite close to 5.6.3 when coming back... > > At this time, 5.6.3 has 405 patches in qtbase, versus 530 that went there for > 5.6.2. I'd rather release with fewer than more, as it decreases the chance of > being difficult to achieve a release. And the more we wait, the more there > will be of them. And it would place 5.6.3 more or less half-way between 5.6.2 > (Nov > 2016) and 5.6.4 (Feb 2018). I agree. But on the other hand there is that many changes already in and quite long time since we tested this release and that's why we surely need time to test & fix the remaining things before we are ready for the release. - Jani From thiago.macieira at intel.com Tue Apr 18 08:25:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Apr 2017 23:25:08 -0700 Subject: [Development] Qt 5.10 schedule proposal In-Reply-To: References: <3355729.XLYieY6BcX@tjmaciei-mobl1> Message-ID: <2203658.yVRF0mNyBD@tjmaciei-mobl1> Em segunda-feira, 17 de abril de 2017, às 21:58:51 PDT, Jani Heikkinen escreveu: > I agree. But on the other hand there is that many changes already in and > quite long time since we tested this release and that's why we surely need > time to test & fix the remaining things before we are ready for the > release. That's another reason to do it sooner, not later... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mikkel at krautz.dk Tue Apr 18 10:37:51 2017 From: mikkel at krautz.dk (Mikkel Krautz) Date: Tue, 18 Apr 2017 10:37:51 +0200 Subject: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017 In-Reply-To: References: Message-ID: MSVC 2015 has buggy magic statics, see https://bugreports.qt.io/browse/QTBUG-58318 and https://connect.microsoft.com/VisualStudio/feedback/details/3121209 I worked around the issue by disabling them with -Zc:threadSafeInit-. On Tue, Apr 18, 2017 at 3:46 AM, Kuba Ober wrote: > Are -static -ltcg -debug-and-release x86 builds tested and supported? It seems that they are broken on at least MSVC 2015 and 2017, in both 5.7 and 5.8. That's using most recent production releases of either version of MSVC (no prereleases etc), and I build using most recent jom. > > For me; 5.8 in a debug build corrupts the heap early during static initialization and doesn't even get to main's body. A release build is will generally crash somewhere but due to lack of heap diagnostics it will get to run first, on a partially corrupted heap. > > 5.7 crashes in the release if you as much as use add a shortcut to a dummy widget and then return from main. Seems to be a different face of the same problem, although the debug version didn't crash. > > IIRC 5.6 was also crashing for me. > > Since this is reproducible on 2 different machines, and seems to point to a persistent problem - did anyone else run into it? > > I will file bug reports but would want to know first whether it's anything known. To be completely frank, I couldn't get any Qt version between 5.6 and 5.8, inclusive, to work under either MSVC 2015 or 2017 with -static -ltcg so it seems like an untested configuration that's exposing undefined behavior somewhere as the whole thing is globally optimized. > > I kinda need this to work. Unless I hear better ideas, I plan on stripping away code to see what it takes to make it not crash. With 5.8 it crashes even with no plugins linked in, the heap corruption is detected in a heap free from one of the Q_GLOBAL_STATICs in somewhere in Qt. > > Cheers, Kuba Ober > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Tue Apr 18 10:38:34 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 18 Apr 2017 08:38:34 +0000 Subject: [Development] State of LGPL exception after migration to LGPLv3 In-Reply-To: <3651384.33rW8ZPOfs@tjmaciei-mobl1> References: <9256451492428265@web20m.yandex.ru> <3651384.33rW8ZPOfs@tjmaciei-mobl1> Message-ID: The LGPL_EXCEPTION.txt files should get removed from our sources. LGPLv3 covers this case directly. Cheers, Lars > On 17 Apr 2017, at 18:07, Thiago Macieira wrote: > > Em segunda-feira, 17 de abril de 2017, às 04:24:25 PDT, Konstantin Tokarev > escreveu: >> 1. Is it still legal to incorporate "inline functions and templates" into >> code not covered by LGPLv3? In particular, I'm interested in qAsConst > > The LGPLv3 text contains the equivalent exception. See LICENSE.LGPLv3 section > 3 "Object Code Incorporating Material from Library Header Files." > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Tue Apr 18 10:52:47 2017 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 18 Apr 2017 10:52:47 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <201704171848.26105.marc.mutz@kdab.com> References: <18894086.giWSYL5Ga8@tjmaciei-mobl1> <201704171848.26105.marc.mutz@kdab.com> Message-ID: <1668053.hI9bPxDsDk@maurice> On Montag, 17. April 2017 18:48:26 CEST Marc Mutz wrote: > On Monday 17 April 2017 18:08:20 Thiago Macieira wrote: > > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz escreveu: > > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing > > > begin() and end(), > > > > Actually, it was. You can't use QT_STRICT_ITERATORS in one TU and not in > > other, regardless of exporting or not. > > Why? ODR violation is an undefined behaviour. (Technically, this is also the case across library boundaries) From marc.mutz at kdab.com Tue Apr 18 11:25:44 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 18 Apr 2017 11:25:44 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <1668053.hI9bPxDsDk@maurice> References: <201704171848.26105.marc.mutz@kdab.com> <1668053.hI9bPxDsDk@maurice> Message-ID: <201704181125.44965.marc.mutz@kdab.com> On Tuesday 18 April 2017 10:52:47 Olivier Goffart wrote: > On Montag, 17. April 2017 18:48:26 CEST Marc Mutz wrote: > > On Monday 17 April 2017 18:08:20 Thiago Macieira wrote: > > > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz > > escreveu: > > > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing > > > > begin() and end(), > > > > > > Actually, it was. You can't use QT_STRICT_ITERATORS in one TU and not > > > in other, regardless of exporting or not. > > > > Why? > > ODR violation is an undefined behaviour. > (Technically, this is also the case across library boundaries) If QT_STRICT_ITERATORS (as-is) is an ODR violation, and technically, it is, then so is #ifdef Q_COMPILER_... over member functions, or QT_NO_CAST_FROM_ASCII. However, we'd be screwed if any compiler started to exploit that particular UB. So, there's nothing out of the ordinary with QT_STRICT_ITERATORS itself. Maybe there was in the past, but not in its current state. In its current state, the problems with QT_STRICT_ITERATORS are _solely_ the two I mentioned, and they affect all member-function-ifdef'ery, be it about iterators, conversions, or c++ features, in the same way. Just try to compile QtCore with QT_NO_CAST_FROM_ASCII and watch the carnage that surely ensues. We can turn a blind eye on the issue, but this wholesale exporting of non- polymophic classes will bite us over and over again, until the naysayers will have learned, too. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Tue Apr 18 12:19:43 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 18 Apr 2017 12:19:43 +0200 Subject: [Development] Make qtstyleplugins an official module and release it References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> <24078294.EJgQmvgWSo@tjmaciei-mobl1> <3938983.fdtVyZZlVT@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On segunda-feira, 17 de abril de 2017 15:05:30 PDT Kevin Kofler wrote: >> Thiago Macieira wrote: >> > So src/widgets/styles/qgtkstyle.cpp did not compile with Gtk3? >> >> No, it doesn't. The GTK+ 3 theming API is very different. >> >> Some Red Hat / Fedora developers have ported the Adwaita style (the >> default GNOME 3 style) to Qt natively, and that is chosen by default on >> GNOME 3 in Fedora (through a platform plugin also implemented by them: >> QGnomePlatform). > > Which is not part of Qt? Because I can't find QGnomePlatform. Indeed, all the work is (unfortunately) out of tree: https://github.com/MartinBriza/QGnomePlatform https://github.com/MartinBriza/adwaita-qt https://github.com/MartinBriza/highcontrast-qt Getting this upstreamed is going to be difficult because of the concerns Red Hat Legal has about the Qt CLA. Kevin Kofler From jhihn at gmx.com Tue Apr 18 15:35:02 2017 From: jhihn at gmx.com (Jason H) Date: Tue, 18 Apr 2017 15:35:02 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: <2244647.iss7YtiiGb@walt>, Message-ID: > Sent: Monday, April 17, 2017 at 6:01 PM > From: "Kevin Kofler" > To: development at qt-project.org > Subject: Re: [Development] Lack of base classes/interfaces? Q*, Q*F > > Alejandro Exojo wrote: > > You should really explain which kind of code did you change, because just > > recently I adjusted code from using a key press event to a touch event, > > and the point had to change from QPoint to QPointF, and the changes were > > minimal. This wasn't explained to me, but I just found it natural. Also: > > > > https://wiki.qt.io/API_Design_Principles#Static_Polymorphism > > And for the OP who is coming from Python: C++ templates can actually be used > to duck-type things *at compile time*, and thus get some compile-time > polymorphism without an inheritance relationship. So if foo is a template > , then calling at(i) on an object of type T will call > QVector::at(int) in foo and QList::at(int) in foo, simply > because of the name. (Trying to instantiate the template with a class that > does not have an at(int) method will of course fail to compile.) > > What will of course *NOT* work in C++ is to duck-type things *at runtime*. > You cannot pass a QList to foo. Runtime polymorphism is (in > general) only possible through virtual methods and inheritance. (And yes, I > know about the possibilities to (ab)use QMetaObject for Q_OBJECTs or > Q_GADGETs to get there. That is out of scope here.) Thank Kevin, yes compile-time is fine for my current engineering challenge. Even though I can in python, I tend to eschew runtime typing. I think the lack of compile-time type checks is a problem with building larger software systems (I have yet to see enterprise software written in JS (though TypeScript addresses this). My concern is mainly allowing the developer to chose the concrete implementation and having my code work with whatever implementation the developer has chosen (in the case of QVector vs QList of QRect vs QRectF). I think runtime type checks (isinstance() in python) are bad because it greatly increases the test cases. From jhihn at gmx.com Tue Apr 18 16:01:45 2017 From: jhihn at gmx.com (Jason H) Date: Tue, 18 Apr 2017 16:01:45 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: <9102936.AmtUYCGMmg@tjmaciei-mobl1> References: <2244647.iss7YtiiGb@walt> , <9102936.AmtUYCGMmg@tjmaciei-mobl1> Message-ID: This would be great. What happened to it? > Sent: Monday, April 17, 2017 at 1:40 PM > From: "Thiago Macieira" > To: development at qt-project.org > Subject: Re: [Development] Lack of base classes/interfaces? Q*, Q*F > > Em segunda-feira, 17 de abril de 2017, às 10:33:06 PDT, Jason H escreveu: > > After some more thought, I think what I need are C++ templates. So let me > > rephrase: Why not QRect and QRect? > > We should do that. See André P's email. > > > Also I'm still not sure though why there isn't an interface for > > QVector/QList? The main things are operator [], at(), size(), etc. > > If by "interface" you mean a base class without virtuals, see > > https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/tools/ > qgenericarray.h > > That's what this class was supposed to be. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From oswald.buddenhagen at qt.io Tue Apr 18 18:06:10 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 18 Apr 2017 18:06:10 +0200 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> References: <201703011338.47378.marc.mutz@kdab.com> <20170313113332.GP19298@troll08> <176CC20E-20EF-4315-87E8-FBF8CB292C3B@qt.io> Message-ID: <20170418160610.GA1708@ugly> On Tue, Apr 11, 2017 at 07:49:28AM +0200, Tuukka Turunen wrote: > Hi, > > With Qt 5.9 beta released last week, I think we should close 5.8 branch > now. > it's done. as usual, i'm expecting a flurry of retargeting requests (not on this list! gah). > Closing 5.8 will help getting Qt 5.9 out in time by pushing everything > directly into 5.9 branch. This is already the case for most items, but > some items are still pushed to 5.8 branch causing the need for continuous > merges and delaying getting those fixes to 5.9. Running the merges and > submodule updates also causes load to the CI, which is away from doing > more frequent runs on 5.9 and dev. > > There has been a lot of discussion about this in the mailing lists, I > think the two ones below sum it up quite well. > > Yours, > > Tuukka > > On 13/03/2017, 13.33, "Development on behalf of Oswald Buddenhagen" > oswald.buddenhagen at qt.io> wrote: > > On Wed, Mar 01, 2017 at 01:38:47PM +0100, Marc Mutz wrote: > > On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: > > > > Let's conclude this topic now by moving on towards 5.9 as Tuukka > > > > proposed. After some thinking I also agree that this is the best > > > > course of action from where we are right now. > > > > > > This also implies that bug fixes should now get pushed to the 5.9 > > > branch and we should close the 5.8 branch soon. > > > > I disagree. Even if you cannot produce releases from 5.8 anymore, > > that's our stable branch. > > > that may be the case, but doesn't necessarily mean that you need to > upstream your fixes there. closing it only affects other users of the > 5.8 tip who want your fixes. probably not that many. > > otoh, the branch being open costs CI cycles and causes some forward > merging effort, while benefitting a marginal number of people. > > another point is that most tqtc employees are actually following the > management order and are neglecting 5.8 (for two months now), which > means that it's by far not as stable as one would want it to be. > > so i guess it's time to give in and officially close the branch. > _______________________________________________ > Development mailing list > Development at qt-project.org > [1]http://lists.qt-project.org/mailman/listinfo/development > > > On 01/03/2017, 21.58, "Development on behalf of Thiago Macieira" > thiago.macieira at intel.com> wrote: > > Em quarta-feira, 1 de marc,o de 2017, `as 04:38:47 PST, Marc Mutz > escreveu: > > > This also implies that bug fixes should now get pushed to the 5.9 > branch > > > and we should close the 5.8 branch soon. > > > > I disagree. Even if you cannot produce releases from 5.8 anymore, > that's our > > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* > you can > > close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? > > We usually switch the default branch between the beta and the RC, so > the point > is moot. > > 5.9 will be considered stable in a couple of weeks, so 5.8 can be > closed. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > [2]http://lists.qt-project.org/mailman/listinfo/development > > Links: > 1. http://lists.qt-project.org/mailman/listinfo/development > 2. http://lists.qt-project.org/mailman/listinfo/development From kuba at mareimbrium.org Tue Apr 18 18:06:59 2017 From: kuba at mareimbrium.org (Kuba Ober) Date: Tue, 18 Apr 2017 12:06:59 -0400 Subject: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017 In-Reply-To: References: Message-ID: <850A7DF2-BA6B-4884-AE59-B3ADA11AD19D@mareimbrium.org> > 18 apr. 2017 kl. 04:37 skrev Mikkel Krautz : > > MSVC 2015 has buggy magic statics, see > https://bugreports.qt.io/browse/QTBUG-58318 and > https://connect.microsoft.com/VisualStudio/feedback/details/3121209 > > I worked around the issue by disabling them with -Zc:threadSafeInit-. Wow, thank you! I've definitely hit the snag related to the shortcuts. I'll see if this option fixes it and will report back ASAP. Cheers, Kuba (Why didn't I find the bug report I can't fathom - I did search for these keywords) From apoenitz at t-online.de Tue Apr 18 17:31:06 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 18 Apr 2017 17:31:06 +0200 Subject: [Development] Make qtstyleplugins an official module and release it In-Reply-To: References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> <24078294.EJgQmvgWSo@tjmaciei-mobl1> <3938983.fdtVyZZlVT@tjmaciei-mobl1> Message-ID: <20170418153106.GB2297@klara.mpi.htwm.de> On Tue, Apr 18, 2017 at 12:19:43PM +0200, Kevin Kofler wrote: > Thiago Macieira wrote: > > On segunda-feira, 17 de abril de 2017 15:05:30 PDT Kevin Kofler wrote: > >> Thiago Macieira wrote: > >> > So src/widgets/styles/qgtkstyle.cpp did not compile with Gtk3? > >> > >> No, it doesn't. The GTK+ 3 theming API is very different. > >> > >> Some Red Hat / Fedora developers have ported the Adwaita style (the > >> default GNOME 3 style) to Qt natively, and that is chosen by default on > >> GNOME 3 in Fedora (through a platform plugin also implemented by them: > >> QGnomePlatform). > > > > Which is not part of Qt? Because I can't find QGnomePlatform. > > Indeed, all the work is (unfortunately) out of tree: > https://github.com/MartinBriza/QGnomePlatform > https://github.com/MartinBriza/adwaita-qt > https://github.com/MartinBriza/highcontrast-qt > > Getting this upstreamed is going to be difficult because of the concerns Red > Hat Legal has about the Qt CLA. Interesting... real reasons, or company politics? Andre' From thiago.macieira at intel.com Tue Apr 18 18:47:48 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 18 Apr 2017 09:47:48 -0700 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: <9102936.AmtUYCGMmg@tjmaciei-mobl1> Message-ID: <1531571.7bdC9rxESy@tjmaciei-mobl1> Em terça-feira, 18 de abril de 2017, às 07:01:45 PDT, Jason H escreveu: > This would be great. What happened to it? I ran out of time developing it and the rest of QString, QByteArray, QVector, and QList for 5.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Apr 18 18:50:30 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 18 Apr 2017 09:50:30 -0700 Subject: [Development] Make qtstyleplugins an official module and release it In-Reply-To: <20170418153106.GB2297@klara.mpi.htwm.de> References: <2165600.uyOFt0l2NH@tjmaciei-mobl1> <20170418153106.GB2297@klara.mpi.htwm.de> Message-ID: <5509842.ZOqqk5iTnB@tjmaciei-mobl1> Em terça-feira, 18 de abril de 2017, às 08:31:06 PDT, André Pönitz escreveu: > > Getting this upstreamed is going to be difficult because of the concerns > > Red Hat Legal has about the Qt CLA. > > Interesting... real reasons, or company politics? [guessing] Real in the sense of "some people get more rights than others". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Tue Apr 18 20:45:53 2017 From: jhihn at gmx.com (Jason H) Date: Tue, 18 Apr 2017 20:45:53 +0200 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: <1531571.7bdC9rxESy@tjmaciei-mobl1> References: <9102936.AmtUYCGMmg@tjmaciei-mobl1> , <1531571.7bdC9rxESy@tjmaciei-mobl1> Message-ID: I'd love to see inclusion for 5.10+ or 6.0 :-) > Sent: Tuesday, April 18, 2017 at 12:47 PM > From: "Thiago Macieira" > To: development at qt-project.org > Subject: Re: [Development] Lack of base classes/interfaces? Q*, Q*F > > Em terça-feira, 18 de abril de 2017, às 07:01:45 PDT, Jason H escreveu: > > This would be great. What happened to it? > > I ran out of time developing it and the rest of QString, QByteArray, QVector, > and QList for 5.0. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From thiago.macieira at intel.com Tue Apr 18 23:25:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 18 Apr 2017 14:25:19 -0700 Subject: [Development] Lack of base classes/interfaces? Q*, Q*F In-Reply-To: References: <1531571.7bdC9rxESy@tjmaciei-mobl1> Message-ID: <31097430.sDn7De0UvV@tjmaciei-mobl1> Em terça-feira, 18 de abril de 2017, às 11:45:53 PDT, Jason H escreveu: > I'd love to see inclusion for 5.10+ or 6.0 :-) 6.0. It can't happen in 5.10 for the same reason it didn't happen in 5.1: it's a completely binary-incompatible change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kuba at mareimbrium.org Wed Apr 19 03:26:58 2017 From: kuba at mareimbrium.org (Kuba Ober) Date: Tue, 18 Apr 2017 21:26:58 -0400 Subject: [Development] openssl-linked include paths in Qt 5.8 Message-ID: When I build 5.8 configured with -static -openssl-linked -I c:\path\to\openssl\include -L c:\path...\lib etc., the OpenSSL configure test passes, but building the network code fails since the include path never makes it to the Makefile (for nmake). Adding QMAKE_INCDIR+=c:\path...\include doesn't help. Am I missing something, or is this a bug? OPENSSL_PATH also seems to be a no-op. Thanks, Kuba Ober From thiago.correa at gmail.com Wed Apr 19 05:03:18 2017 From: thiago.correa at gmail.com (=?UTF-8?Q?Thiago_A=2E_Corr=C3=AAa?=) Date: Wed, 19 Apr 2017 00:03:18 -0300 Subject: [Development] openssl-linked include paths in Qt 5.8 In-Reply-To: References: Message-ID: I have struggled with this in 5.5 and there was closed bug (no feedback) that dates back from 5.5 as well. From what I can tell nmake distclean misses something. I was able to work around this with both of these options: - Erase all source code and download/extract new fresh source tree - Edit .qmake.super and add: INCLUDEPATH += -I c:\path...\include and LIBS += -L c:\path...\lib I suppose after configure qmake -recursive could also work. Most of the time it looks like previously generated Makefiles get stale. Kind Regards, Thiago A. Correa On Tue, Apr 18, 2017 at 10:26 PM, Kuba Ober wrote: > When I build 5.8 configured with -static -openssl-linked -I c:\path\to\openssl\include -L c:\path...\lib etc., the OpenSSL configure test passes, but building the network code fails since the include path never makes it to the Makefile (for nmake). Adding QMAKE_INCDIR+=c:\path...\include doesn't help. Am I missing something, or is this a bug? OPENSSL_PATH also seems to be a no-op. > > Thanks, Kuba Ober > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Wed Apr 19 11:22:35 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 19 Apr 2017 11:22:35 +0200 Subject: [Development] openssl-linked include paths in Qt 5.8 In-Reply-To: References: Message-ID: <20170419092235.GC1708@ugly> On Tue, Apr 18, 2017 at 09:26:58PM -0400, Kuba Ober wrote: > When I build 5.8 configured with -static -openssl-linked -I c:\path\to\openssl\include -L c:\path...\lib etc., the OpenSSL configure test passes, but building the network code fails since the include path never makes it to the Makefile (for nmake). Adding QMAKE_INCDIR+=c:\path...\include doesn't help. Am I missing something, or is this a bug? OPENSSL_PATH also seems to be a no-op. > there is already a jira task that sounds quite similar. i didn't get around to investigate it yet. instructions for obtaining a possibly useful log: - let configure finish - inject -d into the qmake call at the bottom on the configure script - find the openssl entries in config.cache and delete them - run configure again, with all output redirected to a file without the cache trickery you'd get a ~45M file, so don't do that. From rafael.roquetto at kdab.com Wed Apr 19 15:05:18 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Wed, 19 Apr 2017 10:05:18 -0300 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell Message-ID: <20170419130517.GA6906@orion> Hello, I would like to announce that I am stepping down as the QNX maintainer. I would like to propose James McDonnell from QNX for the role. I believe he is the right person to carry on the maintenance of QNX on Qt, because: * he works for QNX, and therefore has a better contextual overview of what needs to be done and considered. * he has been comitting to Qt on QNX for quite a while, being even more active than myself. James is an approver and has been working on several fronts, including QtMultimedia, general bugfixing and brigging excellent QNX support into QtCreator. Long live Qt on QNX! Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From rjvbertin at gmail.com Wed Apr 19 15:29:28 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 19 Apr 2017 15:29:28 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac Message-ID: <2644995.t4MUDqga7l@bola> Hi, Can anyone comment on the feasibility of the following idea, please? OS X 10.7 introduced an optional separation in Mission Control between "spaces" (virtual desktops) and physical screens and coupled that with a fullscreen window inconsistency. By default each monitor has its own virtual desktop and in that case windows that go fullscreen do not affect the other displays (monitors). But when each virtual destop spans all connected screens (so that you can swap spaces on all screens with the keyboard shortcuts) putting a window in fullscreen has an annoying side-effect. The window content is still shown on only the monitor it occupied but the other monitors are all blacked out. Sadly this Mission Control option is not one that can be toggled easily; one has to log off and back in to see the effect. As a laptop user I usually use the laptop's own screen as a secondary monitor when I have my large-screen monitor connected, and thus find it more productive to have virtual desktops that span both screens. I'd love to see an option in Qt like the one provided by VLC, allowing fullscreen windows that leave the other monitor(s) untouched regardless of how Mission Control is configured w.r.t. Spaces. VLC is a good example where this is useful: it allows to watch fullscreen videos and keep an eye on apps running on the secondary screen, for instance to monitor incoming email. How feasible would it be (for a mere mortal like myself) to implement the old-style fullscreen behaviour? I guess that would have to be done in the Cocoa platform plugin? It's been a long time since I looked at how pre-10.7 applications achieved fullscreen mode but I recall it was rather complicated, involving managing different NSWindows for each NSView that could be shown in fullscreen mode. Thanks, René From annulen at yandex.ru Wed Apr 19 15:44:24 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 19 Apr 2017 16:44:24 +0300 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers Message-ID: <275231492609464@web20g.yandex.ru> Hello, I think it will be a good idea to provide implementation of functor calling deleteLater() instead of delete which can be used with std::unique_ptr, std::shared_ptr and other smart pointers with compatible interface. We already have QScopedPointerObjectDeleteLater, however it implements cleanup(T*) instead of operator()(T*). Any suggestions how to name this new class and where to place it? -- Regards, Konstantin From tuukka.turunen at qt.io Wed Apr 19 16:41:37 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 19 Apr 2017 14:41:37 +0000 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: <20170419130517.GA6906@orion> References: <20170419130517.GA6906@orion> Message-ID: <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> Thanks Rafael for your work on this. I see James very well fit for this role. Yours, Tuukka On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" wrote: Hello, I would like to announce that I am stepping down as the QNX maintainer. I would like to propose James McDonnell from QNX for the role. I believe he is the right person to carry on the maintenance of QNX on Qt, because: * he works for QNX, and therefore has a better contextual overview of what needs to be done and considered. * he has been comitting to Qt on QNX for quite a while, being even more active than myself. James is an approver and has been working on several fronts, including QtMultimedia, general bugfixing and brigging excellent QNX support into QtCreator. Long live Qt on QNX! Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts From giuseppe.dangelo at kdab.com Wed Apr 19 16:52:22 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 19 Apr 2017 16:52:22 +0200 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <275231492609464@web20g.yandex.ru> References: <275231492609464@web20g.yandex.ru> Message-ID: <4a0af278-68be-db87-b839-45f33fecaf40@kdab.com> Il 19/04/2017 15:44, Konstantin Tokarev ha scritto: > I think it will be a good idea to provide implementation of functor calling > deleteLater() instead of delete which can be used with std::unique_ptr, > std::shared_ptr and other smart pointers with compatible interface. > > We already have QScopedPointerObjectDeleteLater, however it implements > cleanup(T*) instead of operator()(T*). > > Any suggestions how to name this new class and where to place it? Where to place it: in qobject.h, unless we claim this is done for STL compatibility, and therefore it may need to go somewhere else depending on the resolution on the other thread. I don't think this stuff should be there purely for STL compatibility. In hindsight, the QScopedPointer deleters should have had more generic names than QScopedPointerFoo, as they should be usable in other scenarios too (QSharedPointer?). So, maybe, just add this as an inner class of QObject? QObject::DeleteLater(Functor) maybe? My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From annulen at yandex.ru Wed Apr 19 16:56:31 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 19 Apr 2017 17:56:31 +0300 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <4a0af278-68be-db87-b839-45f33fecaf40@kdab.com> References: <275231492609464@web20g.yandex.ru> <4a0af278-68be-db87-b839-45f33fecaf40@kdab.com> Message-ID: <145061492613791@web22j.yandex.ru> 19.04.2017, 17:52, "Giuseppe D'Angelo" : > Il 19/04/2017 15:44, Konstantin Tokarev ha scritto: >>  I think it will be a good idea to provide implementation of functor calling >>  deleteLater() instead of delete which can be used with std::unique_ptr, >>  std::shared_ptr and other smart pointers with compatible interface. >> >>  We already have QScopedPointerObjectDeleteLater, however it implements >>  cleanup(T*) instead of operator()(T*). >> >>  Any suggestions how to name this new class and where to place it? > > Where to place it: in qobject.h, unless we claim this is done for STL > compatibility, and therefore it may need to go somewhere else depending > on the resolution on the other thread. > > I don't think this stuff should be there purely for STL compatibility. > In hindsight, the QScopedPointer deleters should have had more generic > names than QScopedPointerFoo, as they should be usable in other > scenarios too (QSharedPointer?). > > So, maybe, just add this as an inner class of QObject? > QObject::DeleteLater(Functor) maybe? I thought about it, however I had a concern that QScopedPointerObjectDeleteLater is a template that in theory can call non-QObject deleteLater() method, while inner class of QObject is expected to work with QObject-derived classes only > > My 2 cents, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - Qt, C++ and OpenGL Experts > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From lars.knoll at qt.io Wed Apr 19 18:47:36 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 19 Apr 2017 16:47:36 +0000 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> Message-ID: <83596482-732D-4415-90C9-31F2254C11A2@qt.io> A big thanks from me as well for all you work on maintaining Qt on QNX. James would indeed be a great person to take over this role, but he hasn't said anything himself yet. James, are you willing to take over maintainership for the QNX port? Cheers, Lars > On 19 Apr 2017, at 16:41, Tuukka Turunen wrote: > > > Thanks Rafael for your work on this. I see James very well fit for this role. > > Yours, > > Tuukka > > On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" wrote: > > Hello, > > I would like to announce that I am stepping down as the QNX maintainer. I > would like to propose James McDonnell from QNX for the role. I believe he is > the right person to carry on the maintenance of QNX on Qt, because: > > * he works for QNX, and therefore has a better contextual overview of what > needs to be done and considered. > * he has been comitting to Qt on QNX for quite a while, being even more > active than myself. James is an approver and has been working on several > fronts, including QtMultimedia, general bugfixing and brigging excellent > QNX support into QtCreator. > > Long live Qt on QNX! > > Rafael > > -- > Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Apr 19 19:41:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 19 Apr 2017 10:41:26 -0700 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: <83596482-732D-4415-90C9-31F2254C11A2@qt.io> References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> <83596482-732D-4415-90C9-31F2254C11A2@qt.io> Message-ID: <2164513.9GDpTuh4vS@tjmaciei-mobl1> On quarta-feira, 19 de abril de 2017 09:47:36 PDT Lars Knoll wrote: > A big thanks from me as well for all you work on maintaining Qt on QNX. > > James would indeed be a great person to take over this role, but he hasn't > said anything himself yet. James, are you willing to take over > maintainership for the QNX port? Assuming James is willing to be the maintainer, he has my +1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Apr 19 19:43:22 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 19 Apr 2017 10:43:22 -0700 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <275231492609464@web20g.yandex.ru> References: <275231492609464@web20g.yandex.ru> Message-ID: <8468138.KnMxkeLjVU@tjmaciei-mobl1> On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote: > Hello, > > I think it will be a good idea to provide implementation of functor calling > deleteLater() instead of delete which can be used with std::unique_ptr, > std::shared_ptr and other smart pointers with compatible interface. > > We already have QScopedPointerObjectDeleteLater, however it implements > cleanup(T*) instead of operator()(T*). > > Any suggestions how to name this new class and where to place it? QSharedPointer already supports a PMF as a deleter. auto ptr = QSharedPointer(new QObject, &QObject::deleteLater); So I think this actually belongs in the std-proposals mailing list, not in Qt. Until C++20 gets it, you can use a lambda. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Apr 19 19:48:38 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 19 Apr 2017 20:48:38 +0300 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <8468138.KnMxkeLjVU@tjmaciei-mobl1> References: <275231492609464@web20g.yandex.ru> <8468138.KnMxkeLjVU@tjmaciei-mobl1> Message-ID: <252191492624118@web41j.yandex.ru> 19.04.2017, 20:43, "Thiago Macieira" : > On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote: >>  Hello, >> >>  I think it will be a good idea to provide implementation of functor calling >>  deleteLater() instead of delete which can be used with std::unique_ptr, >>  std::shared_ptr and other smart pointers with compatible interface. >> >>  We already have QScopedPointerObjectDeleteLater, however it implements >>  cleanup(T*) instead of operator()(T*). >> >>  Any suggestions how to name this new class and where to place it? > > QSharedPointer already supports a PMF as a deleter. > >         auto ptr = QSharedPointer(new QObject, &QObject::deleteLater); > > So I think this actually belongs in the std-proposals mailing list, not in Qt. > > Until C++20 gets it, you can use a lambda. It's not possible to have members with auto-deduced types in non-template class, so I actually cannot. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Apr 19 19:57:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 19 Apr 2017 10:57:40 -0700 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <252191492624118@web41j.yandex.ru> References: <275231492609464@web20g.yandex.ru> <8468138.KnMxkeLjVU@tjmaciei-mobl1> <252191492624118@web41j.yandex.ru> Message-ID: <1927028.ZMbEv4ageV@tjmaciei-mobl1> On quarta-feira, 19 de abril de 2017 10:48:38 PDT Konstantin Tokarev wrote: > > auto ptr = QSharedPointer(new QObject, > > &QObject::deleteLater); > > > > So I think this actually belongs in the std-proposals mailing list, not in > > Qt. > > > > Until C++20 gets it, you can use a lambda. > > It's not possible to have members with auto-deduced types in non-template > class, so I actually cannot. Then don't use auto-deduced types. auto ptr = std::shared_ptr(new QObject, [](QObject *o) { o->deleteLater(); }); -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Wed Apr 19 19:58:28 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 19 Apr 2017 20:58:28 +0300 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <252191492624118@web41j.yandex.ru> References: <275231492609464@web20g.yandex.ru> <8468138.KnMxkeLjVU@tjmaciei-mobl1> <252191492624118@web41j.yandex.ru> Message-ID: On 19 April 2017 at 20:48, Konstantin Tokarev wrote: > > > 19.04.2017, 20:43, "Thiago Macieira" : >> On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote: >>> Hello, >>> >>> I think it will be a good idea to provide implementation of functor calling >>> deleteLater() instead of delete which can be used with std::unique_ptr, >>> std::shared_ptr and other smart pointers with compatible interface. >>> >>> We already have QScopedPointerObjectDeleteLater, however it implements >>> cleanup(T*) instead of operator()(T*). >>> >>> Any suggestions how to name this new class and where to place it? >> >> QSharedPointer already supports a PMF as a deleter. >> >> auto ptr = QSharedPointer(new QObject, &QObject::deleteLater); >> >> So I think this actually belongs in the std-proposals mailing list, not in Qt. >> >> Until C++20 gets it, you can use a lambda. > > It's not possible to have members with auto-deduced types in non-template class, > so I actually cannot. I fail to see what auto-deduced members have to do with it: std::unique_ptr upqobj{nullptr, [](QObject* obj) { obj->deleteLater(); }}; From jmcdonnell at blackberry.com Wed Apr 19 20:05:21 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Wed, 19 Apr 2017 18:05:21 +0000 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: <83596482-732D-4415-90C9-31F2254C11A2@qt.io> References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> <83596482-732D-4415-90C9-31F2254C11A2@qt.io> Message-ID: I'd be happy to take responsibility for the QNX parts of Qt ;-). On 2017-04-19, 12:47 PM, "Development on behalf of Lars Knoll" wrote: >A big thanks from me as well for all you work on maintaining Qt on QNX. > >James would indeed be a great person to take over this role, but he >hasn't said anything himself yet. James, are you willing to take over >maintainership for the QNX port? > >Cheers, >Lars > >> On 19 Apr 2017, at 16:41, Tuukka Turunen wrote: >> >> >> Thanks Rafael for your work on this. I see James very well fit for this >>role. >> >> Yours, >> >> Tuukka >> >> On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" >>>rafael.roquetto at kdab.com> wrote: >> >> Hello, >> >> I would like to announce that I am stepping down as the QNX >>maintainer. I >> would like to propose James McDonnell from QNX for the role. I >>believe he is >> the right person to carry on the maintenance of QNX on Qt, because: >> >> * he works for QNX, and therefore has a better contextual >>overview of what >> needs to be done and considered. >> * he has been comitting to Qt on QNX for quite a while, being >>even more >> active than myself. James is an approver and has been working >>on several >> fronts, including QtMultimedia, general bugfixing and brigging >>excellent >> QNX support into QtCreator. >> >> Long live Qt on QNX! >> >> Rafael >> >> -- >> Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - Qt Experts >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From dbroady1 at yahoo.com Wed Apr 19 20:37:27 2017 From: dbroady1 at yahoo.com (Darin Broady) Date: Wed, 19 Apr 2017 18:37:27 +0000 (UTC) Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <275231492609464@web20g.yandex.ru> References: <275231492609464@web20g.yandex.ru> Message-ID: <396469456.3894671.1492627047485@mail.yahoo.com> Is there a reason a new member function for QScopedPointerObjectDeleteLater that conforms to the interface specified by std::default_delete would not work?    void QScopedPointerObjectDeleteLater::operator()(T *pointer) const { if (pointer) pointer->deleteLater(); }  Darin Broadydbroady1 at yahoo.com On Wednesday, April 19, 2017 9:44 AM, Konstantin Tokarev wrote: Hello, I think it will be a good idea to provide implementation of functor calling deleteLater() instead of delete which can be used with std::unique_ptr, std::shared_ptr and other smart pointers with compatible interface. We already have QScopedPointerObjectDeleteLater, however it implements cleanup(T*) instead of operator()(T*). Any suggestions how to name this new class and where to place it? -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Apr 19 20:44:44 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 19 Apr 2017 21:44:44 +0300 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: References: <275231492609464@web20g.yandex.ru> <8468138.KnMxkeLjVU@tjmaciei-mobl1> <252191492624118@web41j.yandex.ru> Message-ID: <5691492627484@web56g.yandex.ru> 19.04.2017, 20:58, "Ville Voutilainen" : > On 19 April 2017 at 20:48, Konstantin Tokarev wrote: >>  19.04.2017, 20:43, "Thiago Macieira" : >>>  On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote: >>>>   Hello, >>>> >>>>   I think it will be a good idea to provide implementation of functor calling >>>>   deleteLater() instead of delete which can be used with std::unique_ptr, >>>>   std::shared_ptr and other smart pointers with compatible interface. >>>> >>>>   We already have QScopedPointerObjectDeleteLater, however it implements >>>>   cleanup(T*) instead of operator()(T*). >>>> >>>>   Any suggestions how to name this new class and where to place it? >>> >>>  QSharedPointer already supports a PMF as a deleter. >>> >>>          auto ptr = QSharedPointer(new QObject, &QObject::deleteLater); >>> >>>  So I think this actually belongs in the std-proposals mailing list, not in Qt. >>> >>>  Until C++20 gets it, you can use a lambda. >> >>  It's not possible to have members with auto-deduced types in non-template class, >>  so I actually cannot. > > I fail to see what auto-deduced members have to do with it: > > std::unique_ptr upqobj{nullptr, > [](QObject* obj) { obj->deleteLater(); }}; Thanks, it works. Except it's totally unusable because of bolerplate spreading. Compare with std::unique_ptr that you can initialize without any boilerplate. Also, the second version does not increase size of unique_ptr with size of function pointer. -- Regards, Konstantin From annulen at yandex.ru Wed Apr 19 20:46:48 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 19 Apr 2017 21:46:48 +0300 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <396469456.3894671.1492627047485@mail.yahoo.com> References: <275231492609464@web20g.yandex.ru> <396469456.3894671.1492627047485@mail.yahoo.com> Message-ID: <10321492627608@web56g.yandex.ru> 19.04.2017, 21:37, "Darin Broady" : > Is there a reason a new member function for QScopedPointerObjectDeleteLater that conforms to the interface specified by std::default_delete would not work? > >    void QScopedPointerObjectDeleteLater::operator()(T *pointer) const { if (pointer) pointer->deleteLater(); } No strong reason, this was one of my thoughts too. One minor thing is that it won't have anything to do with QScopedPointer. > > Darin Broady > dbroady1 at yahoo.com > > On Wednesday, April 19, 2017 9:44 AM, Konstantin Tokarev wrote: > > Hello, > > I think it will be a good idea to provide implementation of functor calling > deleteLater() instead of delete which can be used with std::unique_ptr, > std::shared_ptr and other smart pointers with compatible interface. > > We already have QScopedPointerObjectDeleteLater, however it implements > cleanup(T*) instead of operator()(T*). > > Any suggestions how to name this new class and where to place it? > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From thiago.macieira at intel.com Wed Apr 19 21:10:46 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 19 Apr 2017 12:10:46 -0700 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <275231492609464@web20g.yandex.ru> References: <275231492609464@web20g.yandex.ru> Message-ID: <1593303.MpcJDozd8A@tjmaciei-mobl1> On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote: > We already have QScopedPointerObjectDeleteLater, however it implements > cleanup(T*) instead of operator()(T*). BTW, we should implement operator() in those deleters, calling the cleanup() static. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From krnekit at gmail.com Wed Apr 19 21:26:48 2017 From: krnekit at gmail.com (Nikita Krupenko) Date: Wed, 19 Apr 2017 22:26:48 +0300 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: References: <275231492609464@web20g.yandex.ru> <252191492624118@web41j.yandex.ru> Message-ID: <22308418.4lrhhFHD7X@localhost.localdomain> On среда, 19 апреля 2017 г. 20:58:28 EEST Ville Voutilainen wrote: > On 19 April 2017 at 20:48, Konstantin Tokarev wrote: > > 19.04.2017, 20:43, "Thiago Macieira" : > >> On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote: > >>> Hello, > >>> > >>> I think it will be a good idea to provide implementation of functor > >>> calling > >>> deleteLater() instead of delete which can be used with std::unique_ptr, > >>> std::shared_ptr and other smart pointers with compatible interface. > >>> > >>> We already have QScopedPointerObjectDeleteLater, however it implements > >>> cleanup(T*) instead of operator()(T*). > >>> > >>> Any suggestions how to name this new class and where to place it? > >> > >> QSharedPointer already supports a PMF as a deleter. > >> > >> auto ptr = QSharedPointer(new QObject, > >> &QObject::deleteLater); > >> > >> So I think this actually belongs in the std-proposals mailing list, not > >> in Qt. > >> > >> Until C++20 gets it, you can use a lambda. > > > > It's not possible to have members with auto-deduced types in non-template > > class, so I actually cannot. > > I fail to see what auto-deduced members have to do with it: > > std::unique_ptr upqobj{nullptr, > [](QObject* obj) { obj->deleteLater(); }}; BTW, is there any advantage of using lambda over the following construction? std::unique_ptr (ptr, std::mem_fn(&QObject::deleteLater)); From thiago.macieira at intel.com Wed Apr 19 21:31:55 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 19 Apr 2017 12:31:55 -0700 Subject: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers In-Reply-To: <22308418.4lrhhFHD7X@localhost.localdomain> References: <275231492609464@web20g.yandex.ru> <22308418.4lrhhFHD7X@localhost.localdomain> Message-ID: <6698764.djVR2cW1pd@tjmaciei-mobl1> On quarta-feira, 19 de abril de 2017 12:26:48 PDT Nikita Krupenko wrote: > BTW, is there any advantage of using lambda over the following construction? > > std::unique_ptr > (ptr, std::mem_fn(&QObject::deleteLater)); Yes. I can remember how to write lambdas, but not those functions from the Standard Library. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed Apr 19 21:48:06 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 19 Apr 2017 21:48:06 +0200 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> <83596482-732D-4415-90C9-31F2254C11A2@qt.io> Message-ID: On 2017-04-19 20:05, James McDonnell wrote: > I'd be happy to take responsibility for the QNX parts of Qt ;-). +1 from me, then. From rjvbertin at gmail.com Thu Apr 20 00:04:30 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 20 Apr 2017 00:04:30 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac References: <2644995.t4MUDqga7l@bola> Message-ID: <3576204.uBueZhTsT1@portia.local> Hi, I went ahead and tinkered with Qt4's code: https://github.com/RJVB/shortcut-test-qt5/blob/master/mainwindow.cpp#L302 QCocoaWindow inherits only QObject, not QWidget or QWindow, so implementing this logic in the Cocoa QPA was a bit more work but not impossible: https://cgit.kde.org/scratch/rjvbb/osx-integration.git/tree/src/qcocoa-qpa/qcocoawindow.mm?h=qt590#n1906 This PoC implementation applies the "legacy" (old-style) fullscreen mode to windows without the fullscreen titlebar button, and when QT_LEGACY_FULLSCREEN is set. In the latter case it appears to be a good idea to unset Qt::WindowFullscreenButtonHint because otherwise certain events restore the window frame (decoration). R From katja.marttila at qt.io Thu Apr 20 10:43:47 2017 From: katja.marttila at qt.io (Katja Marttila) Date: Thu, 20 Apr 2017 08:43:47 +0000 Subject: [Development] =?windows-1252?q?Please_update_your_Qt_Online_Insta?= =?windows-1252?q?ller=92s_Maintenance_Tool?= Message-ID: Hi, We are about to change the domain used in Qt Online Installations. If you are using an old version of Maintenance Tool, now is a good time to update it to version 2.0.5-2. So please run ‘Update components’ and your Qt installation will continue working without errors. The MaintenanceTool should be updated by May 5th 2017. After this you may encounter errors when using Maintenance Tool. --Katja Marttila -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Thu Apr 20 11:43:42 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 20 Apr 2017 09:43:42 +0000 Subject: [Development] Qt 5.9 Header diff (API review) Message-ID: Hi all, It is time to do official Header diff for Qt 5.9 APIs (compared to Qt 5.8.0) >From here you can find the diffs: https://codereview.qt-project.org/#/q/branch:5.9+topic:%22API+Review%22,n,z (thanks to Eddy!) Please do the review now if not done yet. We should get '+2' for each submodule as soon as possible, hoping already during next week but latest before Qt 5.9.0 RC br, Jani From lars.knoll at qt.io Thu Apr 20 12:19:14 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 20 Apr 2017 10:19:14 +0000 Subject: [Development] Qt 5.9 Header diff (API review) In-Reply-To: References: Message-ID: <7D3F9986-B00D-4115-98E0-2F756A9C556A@qt.io> Some of the diffs don’t look like they are 100% up to date. Eddy? Lars > On 20 Apr 2017, at 11:43, Jani Heikkinen wrote: > > Hi all, > > It is time to do official Header diff for Qt 5.9 APIs (compared to Qt 5.8.0) > > From here you can find the diffs: https://codereview.qt-project.org/#/q/branch:5.9+topic:%22API+Review%22,n,z (thanks to Eddy!) > > Please do the review now if not done yet. We should get '+2' for each submodule as soon as possible, hoping already during next week but latest before Qt 5.9.0 RC > > br, > Jani > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tor.arne.vestbo at qt.io Thu Apr 20 12:20:17 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 20 Apr 2017 12:20:17 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac In-Reply-To: <3576204.uBueZhTsT1@portia.local> References: <2644995.t4MUDqga7l@bola> <3576204.uBueZhTsT1@portia.local> Message-ID: <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> I see the problem you are trying to solve, but I don't think it's worth it to maintain a separate code path for this legacy mode that conflicts with the platform behavior. tor arne On 20/04/2017 00:04, René J. V. Bertin wrote: > Hi, > > I went ahead and tinkered with Qt4's code: > > https://github.com/RJVB/shortcut-test-qt5/blob/master/mainwindow.cpp#L302 > > QCocoaWindow inherits only QObject, not QWidget or QWindow, so implementing this > logic in the Cocoa QPA was a bit more work but not impossible: > > https://cgit.kde.org/scratch/rjvbb/osx-integration.git/tree/src/qcocoa-qpa/qcocoawindow.mm?h=qt590#n1906 > > This PoC implementation applies the "legacy" (old-style) fullscreen mode to > windows without the fullscreen titlebar button, and when QT_LEGACY_FULLSCREEN is > set. In the latter case it appears to be a good idea to unset > Qt::WindowFullscreenButtonHint because otherwise certain events restore the > window frame (decoration). > > R > From tor.arne.vestbo at qt.io Thu Apr 20 12:20:17 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 20 Apr 2017 12:20:17 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac In-Reply-To: <3576204.uBueZhTsT1@portia.local> References: <2644995.t4MUDqga7l@bola> <3576204.uBueZhTsT1@portia.local> Message-ID: <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> I see the problem you are trying to solve, but I don't think it's worth it to maintain a separate code path for this legacy mode that conflicts with the platform behavior. tor arne On 20/04/2017 00:04, René J. V. Bertin wrote: > Hi, > > I went ahead and tinkered with Qt4's code: > > https://github.com/RJVB/shortcut-test-qt5/blob/master/mainwindow.cpp#L302 > > QCocoaWindow inherits only QObject, not QWidget or QWindow, so implementing this > logic in the Cocoa QPA was a bit more work but not impossible: > > https://cgit.kde.org/scratch/rjvbb/osx-integration.git/tree/src/qcocoa-qpa/qcocoawindow.mm?h=qt590#n1906 > > This PoC implementation applies the "legacy" (old-style) fullscreen mode to > windows without the fullscreen titlebar button, and when QT_LEGACY_FULLSCREEN is > set. In the latter case it appears to be a good idea to unset > Qt::WindowFullscreenButtonHint because otherwise certain events restore the > window frame (decoration). > > R > From giuseppe.dangelo at kdab.com Thu Apr 20 13:32:35 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 20 Apr 2017 13:32:35 +0200 Subject: [Development] =?utf-8?q?Please_update_your_Qt_Online_Installer?= =?utf-8?q?=E2=80=99s_Maintenance_Tool?= In-Reply-To: References: Message-ID: Il 20/04/2017 10:43, Katja Marttila ha scritto: > Hi, > > We are about to change the domain used in Qt Online Installations. If > you are using an old version of Maintenance Tool, now is a good time to > update it to version 2.0.5-2. So please run ‘Update components’ and your > Qt installation will continue working without errors. The > MaintenanceTool should be updated by May 5th 2017. After this you may > encounter errors when using Maintenance Tool. Isn't this the wrong list for this message? It should've gone to announce@ and interest at . Second, I think that a 15 days window for updating is very, very wrong. You should allow at least 2 months. In corporate environments one is simply not allowed to run the Maintenance Tool at will; sysadmins must do it, and they must first do it in testing, triple check that nothing breaks, and then do it on the development / production machines. My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From rjvbertin at gmail.com Thu Apr 20 13:42:19 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 20 Apr 2017 13:42:19 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac In-Reply-To: <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> References: <2644995.t4MUDqga7l@bola> <3576204.uBueZhTsT1@portia.local> <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> Message-ID: <4852215.IIEFRhihgp@portia.local> On Thursday April 20 2017 12:20:17 Tor Arne Vestbø wrote: > I see the problem you are trying to solve, but I don't think it's worth > it to maintain a separate code path for this legacy mode that conflicts > with the platform behavior. That's the question, is this platform behaviour one should impose on the user, or is support for an alternative mode/behaviour an added value for certain users or uses? I know I'm not the only one who's annoyed by the loss of content on all my other screens when I put an app in fullscreen mode, and also that Apple are very unlikely to admit they're wrong in their approach with its inconsistent behaviour. If fullscreen mode is supposed to help you concentrate on a single task, why would it allow the use of other screens in one MissionControl configuration (say for related tasks requiring other apps or even other windows of the same app) and not in the other? This is not documented anywhere that I know of, so I think the blackening is more a side-effect of using a temporary Space to create fullscreen mode than a design principle that you're not allowed to work around. BTW, the same can be said for the screensHaveSeparateSpaces mode: why would it be impossible there to watch a fullscreen video without being bothered by light pollution from your other screens if that's what you want? In fact, I think they persist because we still have a choice: 1) use screensHaveSeparateSpaces (Joe User solution) 2) provide a "legacy" mode (a term I'm beginning to doubt, btw) in software where that's justified (e.g. when the user prefers it). If 1) were easier (immediate effect) we wouldn't need 2) but as long as that's not the case I'll defend 2) or resort to 3) avoid fullscreen mode and prefer applications that provide the kind of fullscreen mode I want. I hadn't noticed before I started tweaking the 5.9.0 Cocoa QPA, but the 5.8.0 Cocoa QPA has almost the same fallback-to-legacy fullscreen as I just implemented. (My implementation is a bit more feature-complete by now, IMHO :)) BTW, I noticed another reason why I prefer this kind of implementation: it's instantaneous and lacks the useless animation. R. > > tor arne > > On 20/04/2017 00:04, René J. V. Bertin wrote: > > Hi, > > > > I went ahead and tinkered with Qt4's code: > > > > https://github.com/RJVB/shortcut-test-qt5/blob/master/mainwindow.cpp#L302 > > > > QCocoaWindow inherits only QObject, not QWidget or QWindow, so implementing this > > logic in the Cocoa QPA was a bit more work but not impossible: > > > > https://cgit.kde.org/scratch/rjvbb/osx-integration.git/tree/src/qcocoa-qpa/qcocoawindow.mm?h=qt590#n1906 > > > > This PoC implementation applies the "legacy" (old-style) fullscreen mode to > > windows without the fullscreen titlebar button, and when QT_LEGACY_FULLSCREEN is > > set. In the latter case it appears to be a good idea to unset > > Qt::WindowFullscreenButtonHint because otherwise certain events restore the > > window frame (decoration). > > > > R > > From rjvbertin at gmail.com Thu Apr 20 14:14:39 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 20 Apr 2017 14:14:39 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac In-Reply-To: <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> References: <2644995.t4MUDqga7l@bola> <3576204.uBueZhTsT1@portia.local> <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> Message-ID: <16622540.rzPd6q0JT1@portia.local> Re: inconsistencies: I just checked video playback in Safari. HTML5 video uses the "native" fullscreen but Flash videos go fullscreen without affecting other screens. I've noticed the same in other browsers, but not in Google Chrome which uses "single-screen fullscreen" regardless the type of video being played. I think that's preferable... R. From tor.arne.vestbo at qt.io Thu Apr 20 14:56:04 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 20 Apr 2017 14:56:04 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac In-Reply-To: <4852215.IIEFRhihgp@portia.local> References: <2644995.t4MUDqga7l@bola> <3576204.uBueZhTsT1@portia.local> <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> <4852215.IIEFRhihgp@portia.local> Message-ID: <93997bb6-604d-649b-060d-c38ab044064d@qt.io> On 20/04/2017 13:42, René J.V. Bertin wrote: > On Thursday April 20 2017 12:20:17 Tor Arne Vestbø wrote: > >> I see the problem you are trying to solve, but I don't think it's >> worth it to maintain a separate code path for this legacy mode that >> conflicts with the platform behavior. > > That's the question, is this platform behaviour one should impose on > the user, Yes. If you want non-platform behavior because you disagree with the platform's choice, you are welcome to write one in user-code using frameless window set to QScreen::geometry() e.g. tor arne From tor.arne.vestbo at qt.io Thu Apr 20 14:56:04 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 20 Apr 2017 14:56:04 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac In-Reply-To: <4852215.IIEFRhihgp@portia.local> References: <2644995.t4MUDqga7l@bola> <3576204.uBueZhTsT1@portia.local> <6b35a4f4-007d-a5f0-a491-681f73055b94@qt.io> <4852215.IIEFRhihgp@portia.local> Message-ID: <93997bb6-604d-649b-060d-c38ab044064d@qt.io> On 20/04/2017 13:42, René J.V. Bertin wrote: > On Thursday April 20 2017 12:20:17 Tor Arne Vestbø wrote: > >> I see the problem you are trying to solve, but I don't think it's >> worth it to maintain a separate code path for this legacy mode that >> conflicts with the platform behavior. > > That's the question, is this platform behaviour one should impose on > the user, Yes. If you want non-platform behavior because you disagree with the platform's choice, you are welcome to write one in user-code using frameless window set to QScreen::geometry() e.g. tor arne From rjvbertin at gmail.com Thu Apr 20 15:43:22 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 20 Apr 2017 15:43:22 +0200 Subject: [Development] old-style, consistent fullscreen behaviour on Mac In-Reply-To: <93997bb6-604d-649b-060d-c38ab044064d@qt.io> References: <2644995.t4MUDqga7l@bola> <4852215.IIEFRhihgp@portia.local> <93997bb6-604d-649b-060d-c38ab044064d@qt.io> Message-ID: <10191484.KTIgvCviGC@portia.local> On Thursday April 20 2017 14:56:04 Tor Arne Vestbø wrote: > Yes. > > If you want non-platform behavior because you disagree with the > platform's choice, you are welcome to write one in user-code using > frameless window set to QScreen::geometry() e.g. That's a valid PoV for writing code using only native SDKs, but not one I think Qt can afford to apply too liberally. It exists in part because of the convenience it provides to design GUI applications Indeed, creating standard fullscreen behaviour is simple and can be done in "Qt userland" as well as with readily available and documented native SDK calls. Meaning it's extremely simple to add support for a basic fullscreen mode and to me that's an argument to keep it in the QPA as apparently it always was. Anything else is imposing unnecessary work on Qt users by requiring them to reinvent the wheel, make their code less maintainable through platform-conditional blocks etc. Ultimately this also is NOT non-platform behaviour. That would be the case if native fullscreen mode always blacked out all other screens and if none of Apple's own and/or officially condoned applications provided different types of fullscreen behaviour. A fullscreen window is nothing but a window occupying an entire screen and without decoration (frame) and the platform allows to turn any window into and back from such a configuration. Exactly the kind of platform behaviour emulation used elsewhere in Qt/Mac. End of discussion, IMHO. I guess we'll see how much outcry there is once 5.9.0 is released and starts being used and people thus start losing the trick to disable the fullscreen button and get normal, consistent fullscreen behaviour. Though I fear most of that outcry will be caught and addressed at levels where the powers that be don't bother listening... Since we're talking about fullscreen behaviour: ever tried putting a window from a multi-window application (say a Qt-based terminal emulator like Konsole) in native fullscreen mode and then open an additional window? If I understand the code correctly that window should get the NSWindowCollectionBehaviorFullScreenAuxiliary flag meaning it's apparently allowed to appear in fullscreen mode. What really happens is that it too is made fullscreen, and when one exits fullscreen mode the original window has disappeared (but not closed because the shell is still running). Apple's own Terminal.app does the same thing so it's probably a Cocoa bug, but one that isn't triggered when using a simple fullscreen mode. If that bug still exists in the latest Mac OS version that only gives an additional reason to provide a workaround - or is that "not done" either? R. PS: why does QApplication::setWindowIcon("foo.svgz") do anything on Mac? Isn't it decidedly non-platform behaviour to change a running application's app icon, with something un-Mac'ish as a compressed SVG image at that? :P From bernd.weimer at pelagicore.com Thu Apr 20 16:05:35 2017 From: bernd.weimer at pelagicore.com (Bernd Weimer) Date: Thu, 20 Apr 2017 16:05:35 +0200 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> <83596482-732D-4415-90C9-31F2254C11A2@qt.io> Message-ID: <096baaa2-b7c3-0b8d-9007-f721b401b815@pelagicore.com> Hi, I'd like to add that James will act as the sole maintainer for QNX. I am still listed as co-maintainer along with Rafael at least on paper. Though, I have been dragged away from QNX even more unfortunately, so there is no point in keeping this role. @James: make Qt on QNX great (again)! Bernd. On 04/19/2017 08:05 PM, James McDonnell wrote: > I'd be happy to take responsibility for the QNX parts of Qt ;-). > > On 2017-04-19, 12:47 PM, "Development on behalf of Lars Knoll" > lars.knoll at qt.io> wrote: > >> A big thanks from me as well for all you work on maintaining Qt on QNX. >> >> James would indeed be a great person to take over this role, but he >> hasn't said anything himself yet. James, are you willing to take over >> maintainership for the QNX port? >> >> Cheers, >> Lars >> >>> On 19 Apr 2017, at 16:41, Tuukka Turunen wrote: >>> >>> >>> Thanks Rafael for your work on this. I see James very well fit for this >>> role. >>> >>> Yours, >>> >>> Tuukka >>> >>> On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" >>> >> rafael.roquetto at kdab.com> wrote: >>> >>> Hello, >>> >>> I would like to announce that I am stepping down as the QNX >>> maintainer. I >>> would like to propose James McDonnell from QNX for the role. I >>> believe he is >>> the right person to carry on the maintenance of QNX on Qt, because: >>> >>> * he works for QNX, and therefore has a better contextual >>> overview of what >>> needs to be done and considered. >>> * he has been comitting to Qt on QNX for quite a while, being >>> even more >>> active than myself. James is an approver and has been working >>> on several >>> fronts, including QtMultimedia, general bugfixing and brigging >>> excellent >>> QNX support into QtCreator. >>> >>> Long live Qt on QNX! >>> >>> Rafael >>> >>> -- >>> Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer >>> Klarälvdalens Datakonsult AB, a KDAB Group company >>> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >>> KDAB - Qt Experts >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From jhihn at gmx.com Thu Apr 20 17:34:09 2017 From: jhihn at gmx.com (Jason H) Date: Thu, 20 Apr 2017 17:34:09 +0200 Subject: [Development] =?utf-8?q?Please_update_your_Qt_Online_Installer?= =?utf-8?q?=E2=80=99s_Maintenance_Tool?= In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Thu Apr 20 19:06:38 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 20 Apr 2017 13:06:38 -0400 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: Message-ID: <58F8EA9E.2070905@gmail.com> On 2017-04-16 10:44, Corentin wrote: > If you want the same behavior, you can create a proxy for your associative > container instance, with a custom iterator whose operator*() returns a std > pair ( or a QPair ) - quite a bit of boilterplate code. ...or use https://github.com/Kitware/qtextensions/blob/master/core/qtEnumerate.h. Rather than returning a pair (which may add overhead), it creates a proxy that just returns the iterator, so you can write: for (auto i : qtEnumerate(my_hash)) do_stuff(i.key(), i.value()); As a plus, `key()` and `value()` are much more readable than `first` and `second`. -- Matthew From mwoehlke.floss at gmail.com Thu Apr 20 19:06:38 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 20 Apr 2017 13:06:38 -0400 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: References: Message-ID: <58F8EA9E.2070905@gmail.com> On 2017-04-16 10:44, Corentin wrote: > If you want the same behavior, you can create a proxy for your associative > container instance, with a custom iterator whose operator*() returns a std > pair ( or a QPair ) - quite a bit of boilterplate code. ...or use https://github.com/Kitware/qtextensions/blob/master/core/qtEnumerate.h. Rather than returning a pair (which may add overhead), it creates a proxy that just returns the iterator, so you can write: for (auto i : qtEnumerate(my_hash)) do_stuff(i.key(), i.value()); As a plus, `key()` and `value()` are much more readable than `first` and `second`. -- Matthew From sergio.martins at kdab.com Thu Apr 20 19:18:37 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 20 Apr 2017 18:18:37 +0100 Subject: [Development] =?utf-8?q?QHash_iteration_vs_std=3A=3Aunordered=5F?= =?utf-8?q?map?= In-Reply-To: <58F8EA9E.2070905@gmail.com> References: <58F8EA9E.2070905@gmail.com> Message-ID: <955abca2f772fed053182c12661d93f8@kdab.com> On 2017-04-20 18:06, Matthew Woehlke wrote: > On 2017-04-16 10:44, Corentin wrote: >> If you want the same behavior, you can create a proxy for your >> associative >> container instance, with a custom iterator whose operator*() returns a >> std >> pair ( or a QPair ) - quite a bit of boilterplate code. > > ...or use > https://github.com/Kitware/qtextensions/blob/master/core/qtEnumerate.h. > Rather than returning a pair (which may add overhead), it creates a > proxy that just returns the iterator, so you can write: > > for (auto i : qtEnumerate(my_hash)) > do_stuff(i.key(), i.value()); That doesn't work with temporaries, does it ? Maybe something to fix in the C++ language, since the usual lifetime-extension tricks don't help in this case. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From mwoehlke.floss at gmail.com Thu Apr 20 19:28:27 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 20 Apr 2017 13:28:27 -0400 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <955abca2f772fed053182c12661d93f8@kdab.com> References: <58F8EA9E.2070905@gmail.com> <955abca2f772fed053182c12661d93f8@kdab.com> Message-ID: <58F8EFBB.9000902@gmail.com> On 2017-04-20 13:18, Sergio Martins wrote: > On 2017-04-20 18:06, Matthew Woehlke wrote: >> for (auto i : qtEnumerate(my_hash)) >> do_stuff(i.key(), i.value()); > > That doesn't work with temporaries, does it ? No. Neither does std::add_const / qAsConst. > Maybe something to fix in the C++ language, since the usual > lifetime-extension tricks don't help in this case. There has been talk, but TTBOMK no concrete proposals yet. (IIRC the `register` proposal was published but the author decided not to present it yet.) -- Matthew From corentin.jabot at gmail.com Fri Apr 21 01:57:41 2017 From: corentin.jabot at gmail.com (Corentin) Date: Fri, 21 Apr 2017 01:57:41 +0200 Subject: [Development] QHash iteration vs std::unordered_map In-Reply-To: <58F8EFBB.9000902@gmail.com> References: <58F8EA9E.2070905@gmail.com> <955abca2f772fed053182c12661d93f8@kdab.com> <58F8EFBB.9000902@gmail.com> Message-ID: Here is a solution using range-v3 https://github.com/cor3ntin/qt-iterate-over-associative-containers/blob/master/main.cpp - there is of course room for improvement :) 2017-04-20 19:28 GMT+02:00 Matthew Woehlke : > On 2017-04-20 13:18, Sergio Martins wrote: > > On 2017-04-20 18:06, Matthew Woehlke wrote: > >> for (auto i : qtEnumerate(my_hash)) > >> do_stuff(i.key(), i.value()); > > > > That doesn't work with temporaries, does it ? > > No. Neither does std::add_const / qAsConst. > > > Maybe something to fix in the C++ language, since the usual > > lifetime-extension tricks don't help in this case. > > There has been talk, but TTBOMK no concrete proposals yet. (IIRC the > `register` proposal was published but the author decided not to present > it yet.) > > -- > Matthew > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filippocucchetto at gmail.com Fri Apr 21 08:42:37 2017 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Fri, 21 Apr 2017 08:42:37 +0200 Subject: [Development] Adding std::weak_ptr to QModelIndex Message-ID: Is there any plan to enhance the QModelIndex interface by adding support to std::weak_ptr but being able to store a weak_ptr seems a little bit safer. -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Fri Apr 21 08:58:18 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 21 Apr 2017 06:58:18 +0000 Subject: [Development] [Announce] Qt 5.9 beta2 available Message-ID: Hi all, Qt 5.9 beta2 is now available. You can update it at the top of your Qt 5.9 beta online installation or do clean installation by using qt online installer. Detailed instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jani.heikkinen at qt.io Fri Apr 21 09:08:00 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 21 Apr 2017 07:08:00 +0000 Subject: [Development] Qt 5.9 beta2 available In-Reply-To: References: Message-ID: Hi all, Qt 5.9 beta2 is now available. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first beta can be found as an attachment. Please test the release and report your effort via https://wiki.qt.io/Qt59_release_testing. I hope we can get results for each platform in the table to get full coverage & good understanding where we are. br, Jani Heikkinen Release Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.9.0-beta1-delta-beta2-commits Type: application/octet-stream Size: 35455 bytes Desc: qt5.9.0-beta1-delta-beta2-commits URL: From marc.mutz at kdab.com Fri Apr 21 09:13:37 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 21 Apr 2017 09:13:37 +0200 Subject: [Development] Adding std::weak_ptr to QModelIndex In-Reply-To: References: Message-ID: <201704210913.37312.marc.mutz@kdab.com> On Friday 21 April 2017 08:42:37 Filippo Cucchetto wrote: > Is there any plan to enhance the QModelIndex interface by adding support to > std::weak_ptr I know that is not necessary since we can directly store T* from > shared_ptr but being able to store a weak_ptr seems a little bit safer. There is no such plan. QModelIndexes should not be stored anywhere, they are simply an interface type: as long as you're using ti correctly, you could not observe the weak_ptr being reset, anyway, and adding an expensive-to-copy type such as std::weak_ptr to an otherwise Trivial Class does not pull it's weight. If and when we change QModelIndex to become more convenient, but also more expensive to use, it should probably get a QVariant (or std::any), not any particular type. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From filippocucchetto at gmail.com Fri Apr 21 09:32:44 2017 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Fri, 21 Apr 2017 09:32:44 +0200 Subject: [Development] Adding std::weak_ptr to QModelIndex In-Reply-To: <201704210913.37312.marc.mutz@kdab.com> References: <201704210913.37312.marc.mutz@kdab.com> Message-ID: 2017-04-21 9:13 GMT+02:00 Marc Mutz : > On Friday 21 April 2017 08:42:37 Filippo Cucchetto wrote: > > Is there any plan to enhance the QModelIndex interface by adding support > to > > std::weak_ptr > I know that is not necessary since we can directly store T* from > > shared_ptr but being able to store a weak_ptr seems a little bit > safer. > > There is no such plan. QModelIndexes should not be stored anywhere, they > are > simply an interface type: as long as you're using ti correctly, you could > not > observe the weak_ptr being reset > > Yes and i agree, but there's a difference between a crash of an application and a warning. Futhermore since QModelIndexes have been somewhat interfaced with QML this bring a lot of indeterminism. > If and when we change QModelIndex to become more convenient, but also more > expensive to use, it should probably get a QVariant (or std::any), not any > particular type. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Apr 21 10:08:44 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 21 Apr 2017 08:08:44 +0000 Subject: [Development] Qt 5.9 Header diff (API review) In-Reply-To: <7D3F9986-B00D-4115-98E0-2F756A9C556A@qt.io> References: , <7D3F9986-B00D-4115-98E0-2F756A9C556A@qt.io> Message-ID: Lars Knoll (20 April 2017 12:19) > Some of the diffs don’t look like they are 100% up to date. Eddy? Indeed, I've just been updating them on request. I do plan on a bulk update today. Eddy. From lars.knoll at qt.io Fri Apr 21 10:10:11 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 21 Apr 2017 08:10:11 +0000 Subject: [Development] Qt 5.9 Header diff (API review) In-Reply-To: References: <7D3F9986-B00D-4115-98E0-2F756A9C556A@qt.io> Message-ID: <59325D6F-F259-47FD-9B43-01AF026C7D39@qt.io> > On 21 Apr 2017, at 10:08, Edward Welbourne wrote: > > Lars Knoll (20 April 2017 12:19) >> Some of the diffs don’t look like they are 100% up to date. Eddy? > > Indeed, I've just been updating them on request. > I do plan on a bulk update today. Thanks! Let us know once the updated diffs are available. No point doing the review on the old diffs. Cheers, Lars From edward.welbourne at qt.io Fri Apr 21 11:18:07 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 21 Apr 2017 09:18:07 +0000 Subject: [Development] Qt 5.9 Header diff (API review) In-Reply-To: <59325D6F-F259-47FD-9B43-01AF026C7D39@qt.io> References: <7D3F9986-B00D-4115-98E0-2F756A9C556A@qt.io> , <59325D6F-F259-47FD-9B43-01AF026C7D39@qt.io> Message-ID: Lars Knoll (21 April 2017 10:10) > Let us know once the updated diffs are available. No point doing the review on the old diffs. Done :-) Eddy. From jan.krause.no19 at gmail.com Fri Apr 21 11:21:55 2017 From: jan.krause.no19 at gmail.com (Jan Krause) Date: Fri, 21 Apr 2017 11:21:55 +0200 Subject: [Development] SignalTranisition: using of signal arguments within onTriggered handler? Message-ID: <6dc7fa6f-36e5-ff2f-d1cf-763e18973757@gmail.com> a transition of a state machine has normally the properties trigger/signal, guard, action... a SignalTransition (http://doc.qt.io/qt-5/qml-qtqml-statemachine-signaltransition.html) of the declarative state machine framework has signal + guard ... where is the action property? there is a triggered signal -> so one can use onTriggered; but how can I use the arguments of the trigger signal in the onTriggered handler? for example: signal triggerSignal(int myIntParam); SignalTransition { targetState: state_2 signal: triggerSignal guard: myIntParam < 10 onTriggered: console.log("myIntParam: "+myIntParam) } is this possible? or is there an other way to use signal arguments within onTriggered? thanks and cheers Jan From marc.mutz at kdab.com Fri Apr 21 12:01:27 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 21 Apr 2017 12:01:27 +0200 Subject: [Development] Adding std::weak_ptr to QModelIndex In-Reply-To: References: <201704210913.37312.marc.mutz@kdab.com> Message-ID: <201704211201.27898.marc.mutz@kdab.com> On Friday 21 April 2017 09:32:44 Filippo Cucchetto wrote: > 2017-04-21 9:13 GMT+02:00 Marc Mutz : > > On Friday 21 April 2017 08:42:37 Filippo Cucchetto wrote: > > > Is there any plan to enhance the QModelIndex interface by adding > > > support > > > > to > > > > > std::weak_ptr > > I know that is not necessary since we can directly store T* from > > > shared_ptr but being able to store a weak_ptr seems a little bit > > > > safer. > > > > There is no such plan. QModelIndexes should not be stored anywhere, they > > are > > simply an interface type: as long as you're using ti correctly, you could > > not > > observe the weak_ptr being reset > > > Yes and i agree, but there's a difference between a crash of an > application and a warning. Yes, the former is preferable :) Seriously, if you still release code that hasn't been though asan, valgrind, Purify or any other such tool, a weak_ptr will not help you, either. If you don't test, why do you expect your users to report some nondescript warning back to you? I'd say they're more likely to report a crash. > Futhermore since QModelIndexes have been somewhat interfaced with QML this > bring > a lot of indeterminism. > > > If and when we change QModelIndex to become more convenient, but also > > more expensive to use, it should probably get a QVariant (or std::any), > > not any particular type. > > > > Thanks, > > Marc > > > > -- > > Marc Mutz | Senior Software Engineer > > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > > Tel: +49-30-521325470 > > KDAB - The Qt, C++ and OpenGL Experts -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Fri Apr 21 12:10:07 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 21 Apr 2017 12:10:07 +0200 Subject: [Development] QCOMPARE & mixed types Message-ID: <201704211210.07277.marc.mutz@kdab.com> Hi, Jedrzej asked me to raise the issue here. Rationale for both allowing, as well as for why I think the rationale for the existing ban is wrong, is included in the commit message: https://codereview.qt-project.org/192269 Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From milian.wolff at kdab.com Fri Apr 21 12:45:08 2017 From: milian.wolff at kdab.com (Milian Wolff) Date: Fri, 21 Apr 2017 12:45:08 +0200 Subject: [Development] QCOMPARE & mixed types In-Reply-To: <201704211210.07277.marc.mutz@kdab.com> References: <201704211210.07277.marc.mutz@kdab.com> Message-ID: <3207015.vPmaluAiDY@agathebauer> On Freitag, 21. April 2017 12:10:07 CEST Marc Mutz wrote: > Hi, > > Jedrzej asked me to raise the issue here. > > Rationale for both allowing, as well as for why I think the rationale for > the existing ban is wrong, is included in the commit message: > > https://codereview.qt-project.org/192269 I for one welcome this change. I always cringed when I wrote code such as QCOMPARE(getSomeQUint64(), 0) and it would fail to compile, forcing me to write ugly code such as QCOMPARE(getSomeQUint64(), quint64(0)) I've also come across code that failed to compile some platforms, since it used something like 0l or 0ll which did not match whatever platform-specific type was used on the lhs... So, from my side a clear +1! -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From annulen at yandex.ru Fri Apr 21 12:53:03 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 21 Apr 2017 13:53:03 +0300 Subject: [Development] QCOMPARE & mixed types In-Reply-To: <3207015.vPmaluAiDY@agathebauer> References: <201704211210.07277.marc.mutz@kdab.com> <3207015.vPmaluAiDY@agathebauer> Message-ID: <2942641492771983@web47j.yandex.ru> 21.04.2017, 13:45, "Milian Wolff" : > On Freitag, 21. April 2017 12:10:07 CEST Marc Mutz wrote: >>  Hi, >> >>  Jedrzej asked me to raise the issue here. >> >>  Rationale for both allowing, as well as for why I think the rationale for >>  the existing ban is wrong, is included in the commit message: >> >>    https://codereview.qt-project.org/192269 > > I for one welcome this change. I always cringed when I wrote code such as > >     QCOMPARE(getSomeQUint64(), 0) > > and it would fail to compile, forcing me to write ugly code such as > >     QCOMPARE(getSomeQUint64(), quint64(0)) > > I've also come across code that failed to compile some platforms, since it > used something like 0l or 0ll which did not match whatever platform-specific > type was used on the lhs... > > So, from my side a clear +1! Another case: comparing QString or QByteArray on one side with const char* literal, or with expression which returns QStringBuilder > -- > Milian Wolff | milian.wolff at kdab.com | Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt Experts > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From announce at qt-project.org Fri Apr 21 12:58:50 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 21 Apr 2017 10:58:50 +0000 Subject: [Development] [Announce] Qt Creator 4.2.2 released Message-ID: We are happy to announce the release of Qt Creator 4.2.2. http://blog.qt.io/blog/2017/04/21/qt-creator-4-2-2-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at 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 _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jani.heikkinen at qt.io Fri Apr 21 13:28:29 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 21 Apr 2017 11:28:29 +0000 Subject: [Development] Heads up - 5.9 soft string freeze In-Reply-To: References: Message-ID: Hi all, Qt 5.9 beta is out & work towards final release continues. One step on the way is String Freeze which should happen really soon to be able to minimize time needed between beta and RC. So let's start keeping the translatable strings as it is & fix remaining important issues. And let's have the official String Freeze 28th April 2017. Br, Jani Heikkinen Release Manager From lars.knoll at qt.io Fri Apr 21 13:29:08 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 21 Apr 2017 11:29:08 +0000 Subject: [Development] QCOMPARE & mixed types In-Reply-To: <2942641492771983@web47j.yandex.ru> References: <201704211210.07277.marc.mutz@kdab.com> <3207015.vPmaluAiDY@agathebauer> <2942641492771983@web47j.yandex.ru> Message-ID: On 21 Apr 2017, at 12:53, Konstantin Tokarev > wrote: 21.04.2017, 13:45, "Milian Wolff" >: On Freitag, 21. April 2017 12:10:07 CEST Marc Mutz wrote: Hi, Jedrzej asked me to raise the issue here. Rationale for both allowing, as well as for why I think the rationale for the existing ban is wrong, is included in the commit message: https://codereview.qt-project.org/192269 I for one welcome this change. I always cringed when I wrote code such as QCOMPARE(getSomeQUint64(), 0) and it would fail to compile, forcing me to write ugly code such as QCOMPARE(getSomeQUint64(), quint64(0)) I've also come across code that failed to compile some platforms, since it used something like 0l or 0ll which did not match whatever platform-specific type was used on the lhs... So, from my side a clear +1! Another case: comparing QString or QByteArray on one side with const char* literal, or with expression which returns QStringBuilder Implicit conversions from QByteArray/const char * to QString was one of the reasons we didn't want this in the past (Qt 4), as those conversions were locale dependent. That is of course less of a problem since Qt 5.0. Cheers, Lars -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts , _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.krause.no19 at gmail.com Fri Apr 21 15:27:24 2017 From: jan.krause.no19 at gmail.com (Jan Krause) Date: Fri, 21 Apr 2017 15:27:24 +0200 Subject: [Development] SignalTranisition: using of signal arguments within onTriggered handler? In-Reply-To: <6dc7fa6f-36e5-ff2f-d1cf-763e18973757@gmail.com> References: <6dc7fa6f-36e5-ff2f-d1cf-763e18973757@gmail.com> Message-ID: sorry ... wrong list... :o Am 21.04.2017 um 11:21 schrieb Jan Krause: > a transition of a state machine has normally the properties > trigger/signal, guard, action... a SignalTransition > (http://doc.qt.io/qt-5/qml-qtqml-statemachine-signaltransition.html) > of the declarative state machine framework has signal + guard ... > > where is the action property? > there is a triggered signal -> so one can use onTriggered; but how can > I use the arguments of the trigger signal in the onTriggered handler? > > for example: > > signal triggerSignal(int myIntParam); > SignalTransition { > targetState: state_2 > signal: triggerSignal > guard: myIntParam < 10 > onTriggered: console.log("myIntParam: "+myIntParam) > } > > is this possible? or is there an other way to use signal arguments > within onTriggered? > > thanks and cheers > Jan From massimocallegari at yahoo.it Sun Apr 23 14:28:04 2017 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sun, 23 Apr 2017 12:28:04 +0000 (UTC) Subject: [Development] distclean question References: <1502412336.4059071.1492950484192.ref@mail.yahoo.com> Message-ID: <1502412336.4059071.1492950484192@mail.yahoo.com> Hi, on Linux it might happen that when configuring Qt to build on a new system, some development packages are missing. It appears that the 'make confclean' target is no longer there (Qt 5.9.0) so to clean up I tried make distclean. However, while qmake creates the proper build paths for options like -nomake examples and -nomake tests, the distclean target ignores them, taking an awful amount of time to execute. Is it possible for qmake to generate a distclean target that actually cleans only the parts that have been specified in configure ? Or is this a generic make-related thing ? Also, I'd like to ask, what does this mean ?"Prior to reconfiguration, make sure you remove any leftovers from the previous build." Where are these "leftovers" documented if I intend to reconfigure without distclean ? With distclean, .config.cache is not removed, so it took me a while to figure out what were the leftovers I was interested to remove. Maybe it's better to reintroduce the confclean target ? Thanks,Massimo -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Apr 23 15:34:53 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Apr 2017 10:34:53 -0300 Subject: [Development] distclean question In-Reply-To: <1502412336.4059071.1492950484192@mail.yahoo.com> References: <1502412336.4059071.1492950484192.ref@mail.yahoo.com> <1502412336.4059071.1492950484192@mail.yahoo.com> Message-ID: <2372102.41BOgH2Djh@tjmaciei-mobl1> Em domingo, 23 de abril de 2017, às 09:28:04 -03, Massimo Callegari via Development escreveu: > Also, I'd like to ask, what does this mean ?"Prior to reconfiguration, make > sure you remove any leftovers from the previous build." Where are these > "leftovers" documented if I intend to reconfigure without distclean ? Any leftovers are anything that was created by configure or make and wasn't there when you extracted. The only advice you're going to get here is to not use make clean, distclean or confclean. Just remove the build directory by way of rm -rf. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kollix at aon.at Mon Apr 24 13:45:32 2017 From: kollix at aon.at (Martin Koller) Date: Mon, 24 Apr 2017 13:45:32 +0200 Subject: [Development] Qt 5.9 beta2 available In-Reply-To: References: Message-ID: <3401310.tvSvmj8EF5@lapi.koller> On Freitag, 21. April 2017 09:08:00 CEST Jani Heikkinen wrote: > Hi all, > > Qt 5.9 beta2 is now available. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first beta can be found as an attachment. > > Please test the release and report your effort via https://wiki.qt.io/Qt59_release_testing. I hope we can get results for each platform in the table to get full coverage & good understanding where we are. It seems qttools/src/assistant is missing clucene in the packages. Is there a reason for it (intentional) or was that forgotten ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? There is no cloud, just other people’s computers. This mail was not scanned before sending. It was sent from a secure Linux desktop. From Eike.Ziller at qt.io Mon Apr 24 13:58:51 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 24 Apr 2017 11:58:51 +0000 Subject: [Development] Qt 5.9 beta2 available In-Reply-To: <3401310.tvSvmj8EF5@lapi.koller> References: <3401310.tvSvmj8EF5@lapi.koller> Message-ID: <8383ED51-250C-49AB-9B93-AA24E9E219A2@qt.io> > On Apr 24, 2017, at 13:45, Martin Koller wrote: > > On Freitag, 21. April 2017 09:08:00 CEST Jani Heikkinen wrote: >> Hi all, >> >> Qt 5.9 beta2 is now available. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first beta can be found as an attachment. >> >> Please test the release and report your effort via https://wiki.qt.io/Qt59_release_testing. I hope we can get results for each platform in the table to get full coverage & good understanding where we are. > > It seems qttools/src/assistant is missing clucene in the packages. > Is there a reason for it (intentional) or was that forgotten ? Assistant no longer uses clucene. e.g. https://codereview.qt-project.org/186659 Br, Eike > > -- > Best regards/Schöne Grüße > > Martin > > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > There is no cloud, just other people’s computers. > > This mail was not scanned before sending. > It was sent from a secure Linux desktop. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at 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 From mardy at users.sourceforge.net Mon Apr 24 14:25:12 2017 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 24 Apr 2017 15:25:12 +0300 Subject: [Development] Exposing QMimeDatabase to QML; QtQml.Utils? Message-ID: <88204554-5a09-f033-3ed2-b54162cf0cb1@users.sourceforge.net> Hi all, in addition to making QMimeType usable from QML [1], jpnurmi also suggested of exposing QMimeDatabase as a singleton. The open question is where this element should be added: I suggested QtQtml.Models, given that it's a database, but maybe creating a separate module QtQml.Utils might be a better idea? If so, do you have suggestions for other classes to be exposed by it? Ciao, Alberto [1]: https://codereview.qt-project.org/191777 From jpnurmi at qt.io Mon Apr 24 14:36:38 2017 From: jpnurmi at qt.io (J-P Nurmi) Date: Mon, 24 Apr 2017 14:36:38 +0200 Subject: [Development] Exposing QMimeDatabase to QML; QtQml.Utils? In-Reply-To: <88204554-5a09-f033-3ed2-b54162cf0cb1@users.sourceforge.net> References: <88204554-5a09-f033-3ed2-b54162cf0cb1@users.sourceforge.net> Message-ID: <1493037398.9943.1.camel@qt.io> On Mon, 2017-04-24 at 15:25 +0300, Alberto Mardegan wrote: > Hi all, >   in addition to making QMimeType usable from QML [1], jpnurmi also > suggested of exposing QMimeDatabase as a singleton. > > The open question is where this element should be added: I suggested > QtQtml.Models, given that it's a database, but maybe creating a > separate > module QtQml.Utils might be a better idea? > > If so, do you have suggestions for other classes to be exposed by it? > > Ciao, >   Alberto > > [1]: https://codereview.qt-project.org/191777 > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, QML Settings, being currently in the Qt.labs namespace, could graduate later there. And QStandardPaths could be a nice addition too. -- J-P Nurmi From sean.harmer at kdab.com Mon Apr 24 15:05:17 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 24 Apr 2017 14:05:17 +0100 Subject: [Development] qdoc for C++ and QML Message-ID: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> Hi, are there any plans to reduce/remove the redundancy when writing documentation for both C++ and QML? Seems a waste of time to have to copy/paste or update the docs twice for both languages when really the only things differing are the "Q" prefix on the class names in C++. On a related note, are there any plans to be able to run make docs/html_docs/qch_docs etc from within creator and have the issue reporter plugin parse the output? Being flooded with warnings about overwriting HTML files on the command line and tryign to spot genuine issues is not much fun. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From Martin.Smith at qt.io Mon Apr 24 15:23:31 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 24 Apr 2017 13:23:31 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> Message-ID: Regarding documenting both C++ and QML at the same time, I will be happy to implement it if we can get a good idea for how to do it. Regarding the creator issue, I don't understand the problem so I can't comment. martin ________________________________________ From: Development on behalf of Sean Harmer Sent: Monday, April 24, 2017 3:05:17 PM To: development at qt-project.org Subject: [Development] qdoc for C++ and QML Hi, are there any plans to reduce/remove the redundancy when writing documentation for both C++ and QML? Seems a waste of time to have to copy/paste or update the docs twice for both languages when really the only things differing are the "Q" prefix on the class names in C++. On a related note, are there any plans to be able to run make docs/html_docs/qch_docs etc from within creator and have the issue reporter plugin parse the output? Being flooded with warnings about overwriting HTML files on the command line and tryign to spot genuine issues is not much fun. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Friedemann.Kleint at qt.io Mon Apr 24 15:26:13 2017 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Mon, 24 Apr 2017 15:26:13 +0200 Subject: [Development] qdoc for C++ and QML In-Reply-To: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> Message-ID: <652a5991-0bd4-bdb4-fa0e-280ca1590f81@qt.io> Hi, For starters, take a look at the script: http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/scripts/qdoc2tasks.pl?h=4.3 You can pipe the error output of qdoc through it to convert it to a Qt Creator task file. Opening it in Qt Creator will show the issues as build issues (see http://doc.qt.io/qtcreator/creator-task-lists.html ) and you can then click through them. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From robin.burchell at crimson.no Mon Apr 24 16:01:12 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Mon, 24 Apr 2017 16:01:12 +0200 Subject: [Development] Exposing QMimeDatabase to QML; QtQml.Utils? In-Reply-To: <1493037398.9943.1.camel@qt.io> References: <88204554-5a09-f033-3ed2-b54162cf0cb1@users.sourceforge.net> <1493037398.9943.1.camel@qt.io> Message-ID: <1493042472.406945.954246352.2A3B41B6@webmail.messagingengine.com> On Mon, Apr 24, 2017, at 02:36 PM, J-P Nurmi wrote: > QML Settings, being currently in the Qt.labs namespace, could graduate > later there. And QStandardPaths could be a nice addition too. Since these are all QtCore types thus far, what about a QtCore import? The source tree would of course have to live in qtdeclarative, but that's not really much of a problem. That then gives us a good place to put additional types, too. I'd generally like to avoid a "Utils" import, since in my opinion they far too easily end up as a dumping ground (yes, yes, arguments about QtCore already sort of being one aside: at least then it's consistent). -- Robin Burchell robin at crimson.no From sean.harmer at kdab.com Mon Apr 24 16:09:09 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 24 Apr 2017 15:09:09 +0100 Subject: [Development] qdoc for C++ and QML In-Reply-To: <652a5991-0bd4-bdb4-fa0e-280ca1590f81@qt.io> References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <652a5991-0bd4-bdb4-fa0e-280ca1590f81@qt.io> Message-ID: <37fba350-5eb1-651b-9553-4308f6cd3ed6@kdab.com> On 24/04/2017 14:26, Friedemann Kleint wrote: > Hi, > > For starters, take a look at the script: > > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/scripts/qdoc2tasks.pl?h=4.3 > > > You can pipe the error output of qdoc through it to convert it to a Qt > Creator task file. Opening it in Qt Creator will show the issues as > build issues (see http://doc.qt.io/qtcreator/creator-task-lists.html ) > and you can then click through them. Thanks, will give it a try! Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From sh at theharmers.co.uk Mon Apr 24 16:17:58 2017 From: sh at theharmers.co.uk (Sean Harmer) Date: Mon, 24 Apr 2017 15:17:58 +0100 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> Message-ID: <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Hi, On 24/04/2017 14:23, Martin Smith wrote: > Regarding documenting both C++ and QML at the same time, I will be happy to implement it if we can get a good idea for how to do it. Well, take https://codereview.qt-project.org/#/c/192093/ as a case in point. The docs for the QML and C++ parts are 80% the same. The only difference really is the code samples. So perhaps one option would be to allow specifying code blocks and maybe other blocks as being specific to C++ or QML. The rest of the containing block could then be the same. Likewise for \property vs \qmlproperty sections. The only difference is a "Q". When writing the docs perhaps marking up a class name without the "Q" prefix could link to the class docs in C++ and the QML type in the QML docs. So instead of: "A QFoo can be used to do blah" in C++ vs "A Foo can be used to do blah" in QML, we could have something like: "A \type Foo can be used to do blah" then when generating the C++ docs it looks for the QFoo docs. > Regarding the creator issue, I don't understand the problem so I can't comment. Like when building a C++ project in creator and being told by the compiler there are warnings/errors, creator parses these into issues that are nicely displayed and when you click on them take you to the relevant section of the code. Cheers, Sean > > martin > ________________________________________ > From: Development on behalf of Sean Harmer > Sent: Monday, April 24, 2017 3:05:17 PM > To: development at qt-project.org > Subject: [Development] qdoc for C++ and QML > > Hi, > > are there any plans to reduce/remove the redundancy when writing > documentation for both C++ and QML? Seems a waste of time to have to > copy/paste or update the docs twice for both languages when really the > only things differing are the "Q" prefix on the class names in C++. > > On a related note, are there any plans to be able to run make > docs/html_docs/qch_docs etc from within creator and have the issue > reporter plugin parse the output? Being flooded with warnings about > overwriting HTML files on the command line and tryign to spot genuine > issues is not much fun. > > Cheers, > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > KDAB (UK) Ltd, a KDAB Group company > Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From edward.welbourne at qt.io Mon Apr 24 16:29:18 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 24 Apr 2017 14:29:18 +0000 Subject: [Development] Exposing QMimeDatabase to QML; QtQml.Utils? In-Reply-To: <1493042472.406945.954246352.2A3B41B6@webmail.messagingengine.com> References: <88204554-5a09-f033-3ed2-b54162cf0cb1@users.sourceforge.net> <1493037398.9943.1.camel@qt.io>, <1493042472.406945.954246352.2A3B41B6@webmail.messagingengine.com> Message-ID: Robin Burchell (24 April 2017 16:01) > I'd generally like to avoid a "Utils" import, since in my opinion they > far too easily end up as a dumping ground +1, also for anything with "misc" in its name. Such names are a red flag about bad modularisation, Eddy. From Martin.Smith at qt.io Mon Apr 24 16:38:31 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 24 Apr 2017 14:38:31 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> , <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: The problem when combining C++ and QML documentation is qdoc has no way of knowing whether a QML type exists for a C++ class or whether a C++ class exists for a QML type. Should we add a new command like \cpp-qml to indicate that both exist and are documented the same? And if a C++ class has a corresponding QML type, should every member function be included in the documentation for both? How will qdoc know that a member function only applies to the C++ class or only to the QML type? martin ________________________________________ From: Development on behalf of Sean Harmer Sent: Monday, April 24, 2017 4:17:58 PM To: development at qt-project.org Subject: Re: [Development] qdoc for C++ and QML Hi, On 24/04/2017 14:23, Martin Smith wrote: > Regarding documenting both C++ and QML at the same time, I will be happy to implement it if we can get a good idea for how to do it. Well, take https://codereview.qt-project.org/#/c/192093/ as a case in point. The docs for the QML and C++ parts are 80% the same. The only difference really is the code samples. So perhaps one option would be to allow specifying code blocks and maybe other blocks as being specific to C++ or QML. The rest of the containing block could then be the same. Likewise for \property vs \qmlproperty sections. The only difference is a "Q". When writing the docs perhaps marking up a class name without the "Q" prefix could link to the class docs in C++ and the QML type in the QML docs. So instead of: "A QFoo can be used to do blah" in C++ vs "A Foo can be used to do blah" in QML, we could have something like: "A \type Foo can be used to do blah" then when generating the C++ docs it looks for the QFoo docs. > Regarding the creator issue, I don't understand the problem so I can't comment. Like when building a C++ project in creator and being told by the compiler there are warnings/errors, creator parses these into issues that are nicely displayed and when you click on them take you to the relevant section of the code. Cheers, Sean > > martin > ________________________________________ > From: Development on behalf of Sean Harmer > Sent: Monday, April 24, 2017 3:05:17 PM > To: development at qt-project.org > Subject: [Development] qdoc for C++ and QML > > Hi, > > are there any plans to reduce/remove the redundancy when writing > documentation for both C++ and QML? Seems a waste of time to have to > copy/paste or update the docs twice for both languages when really the > only things differing are the "Q" prefix on the class names in C++. > > On a related note, are there any plans to be able to run make > docs/html_docs/qch_docs etc from within creator and have the issue > reporter plugin parse the output? Being flooded with warnings about > overwriting HTML files on the command line and tryign to spot genuine > issues is not much fun. > > Cheers, > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > KDAB (UK) Ltd, a KDAB Group company > Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Mon Apr 24 17:08:25 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 24 Apr 2017 15:08:25 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: > On 24 Apr 2017, at 16:38, Martin Smith wrote: > > The problem when combining C++ and QML documentation is qdoc has no way of knowing whether a QML type exists for a C++ class or whether a C++ class exists for a QML type. > > Should we add a new command like \cpp-qml to indicate that both exist and are documented the same? Maybe qdoc could look for qmlRegisterType etc. in the cpp files and discover those relationships without writing anything else? It has a better parser these days, right? Otherwise if you really need a separate qdoc comment, maybe make it look kindof like the QML registration. \qmltype QQuickMyClass MyClass 1.0 or just \qmltype MyClass because qdoc already knows which C++ class the comment goes with, and hopefully can get the version from other comments too. But it amounts to repeating oneself in the code, which is always annoying. > And if a C++ class has a corresponding QML type, should every member function be included in the documentation for both? How will qdoc know that a member function only applies to the C++ class or only to the QML type? Q_INVOKABLE for methods should cover it, I think, if qdoc already knows that the class is exposed to QML. Plus properties, of course. Usually a property setter is not invokable, but there can be exceptions. I guess we haven’t run into this very frequently yet because so few classes have both a C++ and a QML API within the same class. Many QtQuick classes have no public C++ API (so we only document the QML API), and some are wrappers around legacy classes that have different C++ API, or classes for which we know the C++ is too complex or inappropriate to expose directly to QML. Some people even seem to think that as a rule of thumb, C++ and QML APIs should be in separate classes (in other words always write a wrapper for QML), just in case we later need the two APIs to diverge… but I’m not a fan of boilerplate wrapper code and needless indirection. Especially when it can’t be compiled out of existence, and thus bloats the memory footprint and slows down execution. Especially if both the real object and its wrapper are QObjects. But if you put both in the same class, you always have to be careful, keep in mind that adding C++ API might add QML API too, if it’s either invokable or a property. (We got in trouble with Window, but that has a worse problem: inheriting from the wrong class in the first place.) And we do try to keep QML APIs as slim and harmless as possible (in case a graphical design person ends up using them). At least QQuickItem rightly has both public C++ and QML API in the same class, and I don’t suppose anybody thinks we should have avoided it in that case? If qdoc auto-discovers the QML API that goes along with the C++ API, not only will we ensure that it’s all documented, but it may help anyone who is changing the C++ API to verify that the QML API changes which come along with that are really intended, and suitable for QML API. From Uwe.Rathmann at tigertal.de Mon Apr 24 17:37:39 2017 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Mon, 24 Apr 2017 15:37:39 +0000 (UTC) Subject: [Development] qdoc for C++ and QML References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: On Mon, 24 Apr 2017 15:08:25 +0000, Shawn Rutledge wrote: > I guess we haven’t run into this very frequently yet because so few > classes have both a C++ and a QML API within the same class. Well, this is exactly my use case. All my controls are 100% implemented in C++ offering a full featured C++ API. Having a usable QML API is a side effect you almost can't avoid, when doing it this way. I started to get the job done with doxygen and a homebrew filter, that preprocesses my docs by seperating the QML and C++ paths. But having something usable from Qt would be highly appreciated. Not sure if qdoc is intended to be useful for 3rd party libraries as well, but at least for my use case it would save me a lot of work. ciao, Uwe From Martin.Smith at qt.io Mon Apr 24 19:09:43 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 24 Apr 2017 17:09:43 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> , Message-ID: >Maybe qdoc could look for qmlRegisterType etc. in the cpp files and discover >those relationships without writing anything else? It has a better parser these >days, right? It certainly does have a better parser, but for speed, we tell it not to parse the code blocks. Only declarations and signatures. >Otherwise if you really need a separate qdoc comment, maybe make it look >kindof like the QML registration. It doesn't need a separate comment, just something in the one common comment that indicates the class is both C++ and QML. ________________________________________ From: Shawn Rutledge Sent: Monday, April 24, 2017 5:08:25 PM To: Martin Smith Cc: development at qt-project.org Subject: Re: [Development] qdoc for C++ and QML > On 24 Apr 2017, at 16:38, Martin Smith wrote: > > The problem when combining C++ and QML documentation is qdoc has no way of knowing whether a QML type exists for a C++ class or whether a C++ class exists for a QML type. > > Should we add a new command like \cpp-qml to indicate that both exist and are documented the same? Maybe qdoc could look for qmlRegisterType etc. in the cpp files and discover those relationships without writing anything else? It has a better parser these days, right? Otherwise if you really need a separate qdoc comment, maybe make it look kindof like the QML registration. \qmltype QQuickMyClass MyClass 1.0 or just \qmltype MyClass because qdoc already knows which C++ class the comment goes with, and hopefully can get the version from other comments too. But it amounts to repeating oneself in the code, which is always annoying. > And if a C++ class has a corresponding QML type, should every member function be included in the documentation for both? How will qdoc know that a member function only applies to the C++ class or only to the QML type? Q_INVOKABLE for methods should cover it, I think, if qdoc already knows that the class is exposed to QML. Plus properties, of course. Usually a property setter is not invokable, but there can be exceptions. I guess we haven’t run into this very frequently yet because so few classes have both a C++ and a QML API within the same class. Many QtQuick classes have no public C++ API (so we only document the QML API), and some are wrappers around legacy classes that have different C++ API, or classes for which we know the C++ is too complex or inappropriate to expose directly to QML. Some people even seem to think that as a rule of thumb, C++ and QML APIs should be in separate classes (in other words always write a wrapper for QML), just in case we later need the two APIs to diverge… but I’m not a fan of boilerplate wrapper code and needless indirection. Especially when it can’t be compiled out of existence, and thus bloats the memory footprint and slows down execution. Especially if both the real object and its wrapper are QObjects. But if you put both in the same class, you always have to be careful, keep in mind that adding C++ API might add QML API too, if it’s either invokable or a property. (We got in trouble with Window, but that has a worse problem: inheriting from the wrong class in the first place.) And we do try to keep QML APIs as slim and harmless as possible (in case a graphical design person ends up using them). At least QQuickItem rightly has both public C++ and QML API in the same class, and I don’t suppose anybody thinks we should have avoided it in that case? If qdoc auto-discovers the QML API that goes along with the C++ API, not only will we ensure that it’s all documented, but it may help anyone who is changing the C++ API to verify that the QML API changes which come along with that are really intended, and suitable for QML API. From Martin.Smith at qt.io Mon Apr 24 19:11:58 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 24 Apr 2017 17:11:58 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> , Message-ID: >Not sure if qdoc is intended to be useful for 3rd party libraries as >well, but at least for my use case it would save me a lot of work. It is meant to be useful for 3rd party libraries, so we just need to agree on the right way to do this. ________________________________________ From: Development on behalf of Uwe Rathmann Sent: Monday, April 24, 2017 5:37:39 PM To: development at qt-project.org Subject: Re: [Development] qdoc for C++ and QML On Mon, 24 Apr 2017 15:08:25 +0000, Shawn Rutledge wrote: > I guess we haven’t run into this very frequently yet because so few > classes have both a C++ and a QML API within the same class. Well, this is exactly my use case. All my controls are 100% implemented in C++ offering a full featured C++ API. Having a usable QML API is a side effect you almost can't avoid, when doing it this way. I started to get the job done with doxygen and a homebrew filter, that preprocesses my docs by seperating the QML and C++ paths. But having something usable from Qt would be highly appreciated. Not sure if qdoc is intended to be useful for 3rd party libraries as well, but at least for my use case it would save me a lot of work. ciao, Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Mon Apr 24 20:15:37 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 24 Apr 2017 20:15:37 +0200 Subject: [Development] QList In-Reply-To: References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> Message-ID: <8026fe3feca7368912585db567df290a@kdab.com> On 2017-04-06 09:20, Ville Voutilainen wrote: [...] > Okay, I will do it. :) [...] Interested to see the result, as I'm considering abandoning the QArrayList changes. Thanks, Marc From ville.voutilainen at gmail.com Mon Apr 24 20:19:18 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 24 Apr 2017 21:19:18 +0300 Subject: [Development] QList In-Reply-To: <8026fe3feca7368912585db567df290a@kdab.com> References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> <8026fe3feca7368912585db567df290a@kdab.com> Message-ID: On 24 April 2017 at 21:15, Marc Mutz wrote: > On 2017-04-06 09:20, Ville Voutilainen wrote: > [...] >> >> Okay, I will do it. :) > > [...] > > Interested to see the result, as I'm considering abandoning the QArrayList > changes. I'll try to get it done before the end of the week. As far as the final approach goes, that's a different matter that we need to discuss once the analysis write-up is done. What is wrong with QArrayList? From marc.mutz at kdab.com Mon Apr 24 20:39:53 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 24 Apr 2017 20:39:53 +0200 Subject: [Development] QList In-Reply-To: References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> <8026fe3feca7368912585db567df290a@kdab.com> Message-ID: On 2017-04-24 20:19, Ville Voutilainen wrote: [...] > What is wrong with QArrayList? Nothing, IMO, in the version proposed by me: https://codereview.qt-project.org/188938 But since there's been no +2 forthcoming on above change, and I will have no part in the massive code duplication that the alternative, making it a class before Qt 6, would entail, I'm considering closing the CR. And Thanks, Marc From andre at familiesomers.nl Tue Apr 25 06:45:04 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Tue, 25 Apr 2017 06:45:04 +0200 Subject: [Development] QList In-Reply-To: References: <20170405155140.GB26547@troll08> <60CE4C65-9EE4-42F3-B4B6-487A929E84ED@qt.io> <8026fe3feca7368912585db567df290a@kdab.com> Message-ID: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> Op 24/04/2017 om 20:39 schreef Marc Mutz: > On 2017-04-24 20:19, Ville Voutilainen wrote: > [...] >> What is wrong with QArrayList? > > Nothing, IMO, in the version proposed by me: > https://codereview.qt-project.org/188938 > > But since there's been no +2 forthcoming on above change, and I will > have no part in the massive code duplication that the alternative, > making it a class before Qt 6, would entail, I'm considering closing > the CR. Would it not be reasonable to wait until the discussion is finalized? Not that I'm a reviewer or an approver, but I would not give a +2 on any change that basically fixes a direction if the discussion on that has not yet been concluded. André From Uwe.Rathmann at tigertal.de Tue Apr 25 06:57:18 2017 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 25 Apr 2017 04:57:18 +0000 (UTC) Subject: [Development] qdoc for C++ and QML References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: On Mon, 24 Apr 2017 17:09:43 +0000, Martin Smith wrote: > It doesn't need a separate comment, just something in the one common > comment that indicates the class is both C++ and QML. Most of the decisions about what parts of the APIs have to go to the QML docs can indeed be made without any additional tags, but IMO there is still a need for being able to explicitly qualify certain parts as QML or C++ only. F.e I have a couple of C++ methods, that serve no other purpose than to make another C++ API accessible from QML. And the other way round I don't want to see the API, that is made for the C++ use case being visible in the QML docs - even if technically being invokable. Uwe From Martin.Smith at qt.io Tue Apr 25 08:05:38 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Tue, 25 Apr 2017 06:05:38 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> , Message-ID: >F.e I have a couple of C++ methods, that serve no other purpose than to >make another C++ API accessible from QML. And the other way round I don't >want to see the API, that is made for the C++ use case being visible in >the QML docs - even if technically being invokable. Use \internal in their qdoc comments to tell qdoc not to include them. ________________________________________ From: Development on behalf of Uwe Rathmann Sent: Tuesday, April 25, 2017 6:57:18 AM To: development at qt-project.org Subject: Re: [Development] qdoc for C++ and QML On Mon, 24 Apr 2017 17:09:43 +0000, Martin Smith wrote: > It doesn't need a separate comment, just something in the one common > comment that indicates the class is both C++ and QML. Most of the decisions about what parts of the APIs have to go to the QML docs can indeed be made without any additional tags, but IMO there is still a need for being able to explicitly qualify certain parts as QML or C++ only. F.e I have a couple of C++ methods, that serve no other purpose than to make another C++ API accessible from QML. And the other way round I don't want to see the API, that is made for the C++ use case being visible in the QML docs - even if technically being invokable. Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Uwe.Rathmann at tigertal.de Tue Apr 25 08:12:44 2017 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 25 Apr 2017 06:12:44 +0000 (UTC) Subject: [Development] qdoc for C++ and QML References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: On Tue, 25 Apr 2017 06:05:38 +0000, Martin Smith wrote: > Use \internal in their qdoc comments to tell qdoc not to include them. What would be incorrect as those APIs are only internal for C++, but public for QML or v.v. And sometimes you have "see also" references inside of docs for a method that is for both languages, but the reference is linking to QML or C++ only methods. Uwe From Shawn.Rutledge at qt.io Tue Apr 25 08:16:27 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 25 Apr 2017 06:16:27 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: <5A68CBF2-2D7A-4A5D-88DB-8C2F8C181B57@qt.io> > On 24 Apr 2017, at 16:17, Sean Harmer wrote: > > Hi, > > On 24/04/2017 14:23, Martin Smith wrote: >> Regarding documenting both C++ and QML at the same time, I will be happy to implement it if we can get a good idea for how to do it. > > Well, take https://codereview.qt-project.org/#/c/192093/ as a case in point. The docs for the QML and C++ parts are 80% the same. The only difference really is the code samples. So perhaps one option would be to allow specifying code blocks and maybe other blocks as being specific to C++ or QML. The rest of the containing block could then be the same. > > Likewise for \property vs \qmlproperty sections. The only difference is a "Q". > > When writing the docs perhaps marking up a class name without the "Q" prefix could link to the class docs in C++ and the QML type in the QML docs. So instead of: > > "A QFoo can be used to do blah" in C++ vs > "A Foo can be used to do blah" in QML, we could have something like: > > "A \type Foo can be used to do blah" then when generating the C++ docs it looks for the QFoo docs. This we haven’t addressed yet, right? Sounds like we need conditionals in doc comments: if building the QML doc, do this, if C++ do that. The code samples could be put into snippets though, to keep those comment blocks from getting unwieldy. From marc.mutz at kdab.com Tue Apr 25 08:14:54 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 25 Apr 2017 08:14:54 +0200 Subject: [Development] QList In-Reply-To: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> References: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> Message-ID: <201704250814.54738.marc.mutz@kdab.com> On Tuesday 25 April 2017 06:45:04 André Somers wrote: > Op 24/04/2017 om 20:39 schreef Marc Mutz: > > On 2017-04-24 20:19, Ville Voutilainen wrote: > > [...] > > > >> What is wrong with QArrayList? > > > > Nothing, IMO, in the version proposed by me: > > https://codereview.qt-project.org/188938 > > > > But since there's been no +2 forthcoming on above change, and I will > > have no part in the massive code duplication that the alternative, > > making it a class before Qt 6, would entail, I'm considering closing > > the CR. > > Would it not be reasonable to wait until the discussion is finalized? > Not that I'm a reviewer or an approver, but I would not give a +2 on any > change that basically fixes a direction if the discussion on that has > not yet been concluded. I believe this is exactly what I'm doing here with this request. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Martin.Smith at qt.io Tue Apr 25 08:29:27 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Tue, 25 Apr 2017 06:29:27 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> , Message-ID: >What would be incorrect as those APIs are only internal for C++, but >public for QML or v.v. Then we need \cpponly and \qmlonly, or something like that. ________________________________________ From: Development on behalf of Uwe Rathmann Sent: Tuesday, April 25, 2017 8:12:44 AM To: development at qt-project.org Subject: Re: [Development] qdoc for C++ and QML On Tue, 25 Apr 2017 06:05:38 +0000, Martin Smith wrote: > Use \internal in their qdoc comments to tell qdoc not to include them. What would be incorrect as those APIs are only internal for C++, but public for QML or v.v. And sometimes you have "see also" references inside of docs for a method that is for both languages, but the reference is linking to QML or C++ only methods. Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Friedemann.Kleint at qt.io Tue Apr 25 08:30:28 2017 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Tue, 25 Apr 2017 08:30:28 +0200 Subject: [Development] qdoc for C++ and QML In-Reply-To: <37fba350-5eb1-651b-9553-4308f6cd3ed6@kdab.com> References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <652a5991-0bd4-bdb4-fa0e-280ca1590f81@qt.io> <37fba350-5eb1-651b-9553-4308f6cd3ed6@kdab.com> Message-ID: <76bc6310-3422-2068-41e1-43d4959de126@qt.io> Hi, btw, we are facing a similar problem when generating the documentation for the PySide2 project (Python bindings for Qt). The code snippets are different; most of the text is similar. So, the issue could be generalized for any language bindings of Qt. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From edward.welbourne at qt.io Tue Apr 25 10:09:50 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 25 Apr 2017 08:09:50 +0000 Subject: [Development] Introductions? In-Reply-To: References: Message-ID: Steve Schilz asked me (24 April 2017 19:10) a pertinent question (heavily edited): > I’m not really sure what/where your role is… and I’m curious. > Perhaps an introduction on the mailing list (say, from Lars Knoll?) > for people further out in the Qt orbit is in order, or perhaps I > missed it? which prompts me to a suggestion, as much the same is relevant for any approver or maintainer: perhaps we should tweak our process for introducing candidates for those stations within the community; ask that each introduce self in the course of it - possibly *after* we've made our decision, so we won't be prejudiced by their weird hobbies. ISTR Lars, when proposing me, just linked to my review history in gerrit; that probably should suffice for the decision on whether to accept a candidate - but it might be worth, once the decision is made, as a matter of course, having the new approver or maintainer introduce self, or link to web pages that do so. That could be a short summary of career, hobbies and life, like I've been making software less bad for about three decades, starting in 1982, with several breaks. I've only had limited exposure to Qt prior to joining the Core and Network team at TQtC a year and a half ago; and I'm (not so) secretly a closet C programmer still learning new things in C++. I refactor algebra as a hobby and write about various topics on a web-site [0] that deserves more of my time than I've lately found the enthusiasm to spend on it. Or it could just be a link to a CV [1], if you have it on-line. [0] http://www.chaos.org.uk/~eddy/ [1] http://www.chaos.org.uk/~eddy/cv/ (a little out of date, I now notice) Doing this might leave more of us with a sense of who each other are, which seems like a natural thing in a community. What do folk think ? Eddy. From jedrzej.nowacki at qt.io Tue Apr 25 11:26:51 2017 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 25 Apr 2017 11:26:51 +0200 Subject: [Development] qdoc for C++ and QML In-Reply-To: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> Message-ID: <2380362.ynt3yfUC1c@42> On mandag 24. april 2017 14.05.17 CEST Sean Harmer wrote: > Hi, > > are there any plans to reduce/remove the redundancy when writing > documentation for both C++ and QML? Seems a waste of time to have to > copy/paste or update the docs twice for both languages when really the > only things differing are the "Q" prefix on the class names in C++. > (...) You can create shared blocks of docs in a separate qdocinc file and use them with " \include file.qdocinc" command. It is not perfect, as you would not see the full docs in the source code, but it generates the right thing. Cheers, Jędrek From jani.heikkinen at qt.io Tue Apr 25 11:39:48 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 25 Apr 2017 09:39:48 +0000 Subject: [Development] Testing help needed In-Reply-To: References: Message-ID: Hi all, There is now wiki page for reporting testing effort and results in https://wiki.qt.io/Qt59_release_testing . I also asked you all to take a tour for Qt 5.9 beta2 & report the effort via it. As you can see there isn't really any reports from community yet. It would be really beneficial for Qt to get packages tested early enough & find all release blockers well before official release. That would help us to keep the schedules and improve the release quality. So do you have some ideas how to get you all better involved to this? Is wiki page & table easy enough for this or should we use some other format? Getting you involved to this more will help us to do more patch level releases in the future as well (which has been the hot topic during this spring)... br, Jani From robin.burchell at crimson.no Tue Apr 25 11:46:58 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Tue, 25 Apr 2017 11:46:58 +0200 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: <1493113618.3902729.955369200.0847A95E@webmail.messagingengine.com> On Mon, Apr 24, 2017, at 05:08 PM, Shawn Rutledge wrote: > > And if a C++ class has a corresponding QML type, should every member function be included in the documentation for both? How will qdoc know that a member function only applies to the C++ class or only to the QML type? > > Q_INVOKABLE for methods should cover it, I think, if qdoc already knows > that the class is exposed to QML. Plus properties, of course. Usually a > property setter is not invokable, but there can be exceptions. This will involve some amount of work, though: for instance, qdoc would need to be taught what to do with QQmlListProperty ("list" in output, e.g. QQmlListProperty -> list). There's also registered types are not necessarily intended to be user-creatable, for instance, Item::layer, QQuickPen (Rectangle's border type) which need to be handled "specially" in documentation. And the good old subject of "variant" functions like Item::mapFromItem, which will need special casing... -- Robin Burchell robin at crimson.no From marc.mutz at kdab.com Tue Apr 25 12:59:03 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 25 Apr 2017 12:59:03 +0200 Subject: [Development] Use of std::function in Qt API In-Reply-To: <24435701.t0Ygg1vmXa@maurice> References: <24435701.t0Ygg1vmXa@maurice> Message-ID: <201704251259.04184.marc.mutz@kdab.com> On Tuesday 14 March 2017 11:32:39 Olivier Goffart wrote: > On Dienstag, 14. März 2017 10:33:44 CET Simon Hausmann wrote: > > Hi, > > > > > > I understand that there are limitations (to put it mildly) regarding the > > use of API from the C++ standard library in Qt API itself due to the > > inability to extend our binary compatibility promise. I'm curious though > > whether std::function falls under the same umbrella? > > Yes, it does: the binary representation (including size), or the mangling > is not guaranteed to be the same across stdlib implementations. > > > So here are the choice: > > 1- Re-implement QFunction, with similar semantic as std::function. > > 2- Lift the constraint that we can't use the stdlib in our ABI > > 3- Do nothing and keep using awkward interface when we need callback. > > > #3 is, as usual, the easier (status quo) and will probably happen. #1 is a > somewhat difficult task, but not that hard. We will just end up with a poor > copy of std::function. #2 was always dismissed in the past, but I think it > should be seriously considered. > > (The same applies to std::unique_ptr, too) There's also #4: type-erase the std component. Implemented in https://codereview.qt-project.org/192637 This commit, ladies and gentlemen, shows how we hurt ourselves for this policy of ours of keeping std types out of our ABI. And the issue in that commit is extremely subtle, too. This is how we'd solve the issue with std types allowed: https://codereview.qt-project.org/192656 What's holding us back? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From mardy at users.sourceforge.net Tue Apr 25 14:09:24 2017 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Tue, 25 Apr 2017 15:09:24 +0300 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: On 25/04/2017 09:29, Martin Smith wrote: >> What would be incorrect as those APIs are only internal for C++, but >> public for QML or v.v. > > Then we need \cpponly and \qmlonly, or something like that. This is calling for future headaches, when you start adding python or other languages. It's better to just support using \cpp, \qml, \python tags; and if no tags appear, then it's assumed that the documentation applies to all languages. Also \nocpp, \noqml and \nopython could be useful. Ciao, Alberto From thiago.macieira at intel.com Tue Apr 25 15:48:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Apr 2017 10:48:23 -0300 Subject: [Development] QList In-Reply-To: <201704250814.54738.marc.mutz@kdab.com> References: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> <201704250814.54738.marc.mutz@kdab.com> Message-ID: <31771025.Xza7NClrka@tjmaciei-mobl1> Em terça-feira, 25 de abril de 2017, às 03:14:54 -03, Marc Mutz escreveu: > On Tuesday 25 April 2017 06:45:04 André Somers wrote: > > Op 24/04/2017 om 20:39 schreef Marc Mutz: > > > On 2017-04-24 20:19, Ville Voutilainen wrote: > > > [...] > > > > > >> What is wrong with QArrayList? > > > > > > Nothing, IMO, in the version proposed by me: > > > https://codereview.qt-project.org/188938 > > > > > > But since there's been no +2 forthcoming on above change, and I will > > > have no part in the massive code duplication that the alternative, > > > making it a class before Qt 6, would entail, I'm considering closing > > > the CR. > > > > Would it not be reasonable to wait until the discussion is finalized? > > Not that I'm a reviewer or an approver, but I would not give a +2 on any > > change that basically fixes a direction if the discussion on that has > > not yet been concluded. > > I believe this is exactly what I'm doing here with this request. Basically the discussion is: what should happen to QArrayList or QArrayList? a) fail to compile b) become an array list c) become a vector I point out that (c) is what QList does, and we don't need the same behaviour as QList already has. Marc proposed (a), which is the simplest solution to the problem. I wanted (b), which would require duplication of code and Marc was unwilling to do that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Apr 25 15:51:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Apr 2017 10:51:54 -0300 Subject: [Development] Use of std::function in Qt API In-Reply-To: <201704251259.04184.marc.mutz@kdab.com> References: <24435701.t0Ygg1vmXa@maurice> <201704251259.04184.marc.mutz@kdab.com> Message-ID: <17164736.m9p1SAb0D9@tjmaciei-mobl1> Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu: > What's holding us back? At this point, inertia. I've already lifted my objection in the grounds that no one in the Linux sphere cares about compatibility between libstdc++ and libc++ without a "rebuild the world" step. Using the standard library requires a QUIP with the allowed classes and the allowed uses of those classes, as I'm sure we'll find incomplete or non- standard implementations of them in the many platforms and compilers we need to support. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Shawn.Rutledge at qt.io Tue Apr 25 15:57:24 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 25 Apr 2017 13:57:24 +0000 Subject: [Development] qdoc for C++ and QML In-Reply-To: References: <0e1234e7-6ad2-5f73-cf1c-4d2e108079cc@kdab.com> <8cadf5dd-0ceb-d160-0791-3381686482f4@theharmers.co.uk> Message-ID: > On 25 Apr 2017, at 14:09, Alberto Mardegan wrote: > > On 25/04/2017 09:29, Martin Smith wrote: >>> What would be incorrect as those APIs are only internal for C++, but >>> public for QML or v.v. >> >> Then we need \cpponly and \qmlonly, or something like that. > > This is calling for future headaches, when you start adding python or > other languages. > > It's better to just support using \cpp, \qml, \python tags; and if no > tags appear, then it's assumed that the documentation applies to all > languages. > Also \nocpp, \noqml and \nopython could be useful. Or something with a parameter like \lang(cpp) \lang(qml) etc. might be more extensible? (not sure of what sort of syntax like that you can support inside a backslash doc tag… should follow the convention if there is one) From lars.knoll at qt.io Tue Apr 25 16:30:05 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 25 Apr 2017 14:30:05 +0000 Subject: [Development] QList In-Reply-To: <31771025.Xza7NClrka@tjmaciei-mobl1> References: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> <201704250814.54738.marc.mutz@kdab.com> <31771025.Xza7NClrka@tjmaciei-mobl1> Message-ID: <73550F47-D21C-4172-84C1-9CEB113632F3@qt.io> On 25 Apr 2017, at 15:48, Thiago Macieira > wrote: Em terça-feira, 25 de abril de 2017, às 03:14:54 -03, Marc Mutz escreveu: On Tuesday 25 April 2017 06:45:04 André Somers wrote: Op 24/04/2017 om 20:39 schreef Marc Mutz: On 2017-04-24 20:19, Ville Voutilainen wrote: [...] What is wrong with QArrayList? Nothing, IMO, in the version proposed by me: https://codereview.qt-project.org/188938 But since there's been no +2 forthcoming on above change, and I will have no part in the massive code duplication that the alternative, making it a class before Qt 6, would entail, I'm considering closing the CR. Would it not be reasonable to wait until the discussion is finalized? Not that I'm a reviewer or an approver, but I would not give a +2 on any change that basically fixes a direction if the discussion on that has not yet been concluded. I believe this is exactly what I'm doing here with this request. Basically the discussion is: what should happen to QArrayList or QArrayList? a) fail to compile b) become an array list c) become a vector I point out that (c) is what QList does, and we don't need the same behaviour as QList already has. Marc proposed (a), which is the simplest solution to the problem. I wanted (b), which would require duplication of code and Marc was unwilling to do that. I’d be ok with (a), as long as we see it purely as a porting help for the few cases where users might need this. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Tue Apr 25 16:34:01 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 25 Apr 2017 14:34:01 +0000 Subject: [Development] Use of std::function in Qt API In-Reply-To: <17164736.m9p1SAb0D9@tjmaciei-mobl1> References: <24435701.t0Ygg1vmXa@maurice> <201704251259.04184.marc.mutz@kdab.com> <17164736.m9p1SAb0D9@tjmaciei-mobl1> Message-ID: > On 25 Apr 2017, at 15:51, Thiago Macieira wrote: > > Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu: >> What's holding us back? > > At this point, inertia. > > I've already lifted my objection in the grounds that no one in the Linux > sphere cares about compatibility between libstdc++ and libc++ without a > "rebuild the world" step. > > Using the standard library requires a QUIP with the allowed classes and the > allowed uses of those classes, as I'm sure we'll find incomplete or non- > standard implementations of them in the many platforms and compilers we need > to support. We concluded that we don’t want to be responsible for the stdlib breaking compatibility or compatibility between libstdc++ and libc++. So in that respect, we should be able to more freely to use more of the standard library, as long as the parts we’re using are supported on all our platforms. But I agree with Thiago, that we should have this written down in a QUIP, ideally with a list of the classes we consider ok to use in our APIs. Cheers, Lars From tuukka.turunen at qt.io Tue Apr 25 18:16:40 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 25 Apr 2017 16:16:40 +0000 Subject: [Development] Testing help needed In-Reply-To: References: , Message-ID: Hi, There were quite many people who expressed interest a few months ago to help in making the releases, so hopefully we get a lot of suggestions to better engage with the whole community for testing the releases. Quite many are testing new Qt versions with their applications and reporting issues via bugreports. This is really valuable and we hope that with the new process of multiple betas available via the online installer this testing becomes even easier. In addition we would like to have people to test new releases for wider functionality than just what their app needs. Optimally all, but that is of course not possible in practice. We have automatic testing in place with quite good coverage, but in order to catch all the needed issues manual testing is still beneficial. This is what Jani is asking volunteers to help with. The sooner we find issues to fix, the better. So time for testing is now. Yours, Tuukka ________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, April 25, 2017 11:39:48 AM To: development at qt-project.org; releasing at qt-project.org Cc: interest at qt-project.org Subject: [Development] Testing help needed Hi all, There is now wiki page for reporting testing effort and results in https://wiki.qt.io/Qt59_release_testing . I also asked you all to take a tour for Qt 5.9 beta2 & report the effort via it. As you can see there isn't really any reports from community yet. It would be really beneficial for Qt to get packages tested early enough & find all release blockers well before official release. That would help us to keep the schedules and improve the release quality. So do you have some ideas how to get you all better involved to this? Is wiki page & table easy enough for this or should we use some other format? Getting you involved to this more will help us to do more patch level releases in the future as well (which has been the hot topic during this spring)... br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.voutilainen at gmail.com Tue Apr 25 18:34:43 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 25 Apr 2017 19:34:43 +0300 Subject: [Development] Use of std::function in Qt API In-Reply-To: References: <24435701.t0Ygg1vmXa@maurice> <201704251259.04184.marc.mutz@kdab.com> <17164736.m9p1SAb0D9@tjmaciei-mobl1> Message-ID: On 25 April 2017 at 17:34, Lars Knoll wrote: > >> On 25 Apr 2017, at 15:51, Thiago Macieira wrote: >> >> Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu: >>> What's holding us back? >> >> At this point, inertia. >> >> I've already lifted my objection in the grounds that no one in the Linux >> sphere cares about compatibility between libstdc++ and libc++ without a >> "rebuild the world" step. >> >> Using the standard library requires a QUIP with the allowed classes and the >> allowed uses of those classes, as I'm sure we'll find incomplete or non- >> standard implementations of them in the many platforms and compilers we need >> to support. > > We concluded that we don’t want to be responsible for the stdlib breaking compatibility or compatibility between libstdc++ and libc++. So in that respect, we should be able to more freely to use more of the standard library, as long as the parts we’re using are supported on all our platforms. > > But I agree with Thiago, that we should have this written down in a QUIP, ideally with a list of the classes we consider ok to use in our APIs. Sounds like a good idea, because things like std::vector are becoming part of our API and ABI. :) https://codereview.qt-project.org/#/c/191873/ From marc.mutz at kdab.com Tue Apr 25 18:39:52 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 25 Apr 2017 18:39:52 +0200 Subject: [Development] Use of std::function in Qt API In-Reply-To: References: <24435701.t0Ygg1vmXa@maurice> <201704251259.04184.marc.mutz@kdab.com> <17164736.m9p1SAb0D9@tjmaciei-mobl1> Message-ID: <70d61ecb8d45a49e12e8f4999c281b0f@kdab.com> On 2017-04-25 16:34, Lars Knoll wrote: [...] > But I agree with Thiago, that we should have this written down in a > QUIP, ideally with a list of the classes we consider ok to use in our > APIs. [...] I'd make the QUIP define the updated BC guarantee. The list of std types available for use in Qt APIs should be in QtBase Git, though, to be versioned on a per-branch basis. From thiago.macieira at intel.com Tue Apr 25 19:41:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Apr 2017 14:41:19 -0300 Subject: [Development] Use of std::function in Qt API In-Reply-To: <70d61ecb8d45a49e12e8f4999c281b0f@kdab.com> References: <70d61ecb8d45a49e12e8f4999c281b0f@kdab.com> Message-ID: <1539354.QoJSJod02y@tjmaciei-mobl1> On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote: > On 2017-04-25 16:34, Lars Knoll wrote: > [...] > > > But I agree with Thiago, that we should have this written down in a > > QUIP, ideally with a list of the classes we consider ok to use in our > > APIs. > > [...] > > I'd make the QUIP define the updated BC guarantee. The list of std types > available for use in Qt APIs should be in QtBase Git, though, to be > versioned on a per-branch basis. Why does it need to be versioned on a per-branch basis? Because of when we deprecate older compilers, we can update the list? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Tue Apr 25 19:30:50 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 25 Apr 2017 19:30:50 +0200 Subject: [Development] Use of std::function in Qt API In-Reply-To: <1539354.QoJSJod02y@tjmaciei-mobl1> References: <70d61ecb8d45a49e12e8f4999c281b0f@kdab.com> <1539354.QoJSJod02y@tjmaciei-mobl1> Message-ID: <20170425173050.GA1654@klara.mpi.htwm.de> On Tue, Apr 25, 2017 at 02:41:19PM -0300, Thiago Macieira wrote: > On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote: > > On 2017-04-25 16:34, Lars Knoll wrote: > > [...] > > > > > But I agree with Thiago, that we should have this written down in a > > > QUIP, ideally with a list of the classes we consider ok to use in our > > > APIs. > > > > [...] > > > > I'd make the QUIP define the updated BC guarantee. The list of std types > > available for use in Qt APIs should be in QtBase Git, though, to be > > versioned on a per-branch basis. > > Why does it need to be versioned on a per-branch basis? Because of when we > deprecate older compilers, we can update the list? Since the rules will likely differ per branch I actually think it's a good idea to have the rules close to the locations to which they apply. Changing files with rules with QUIP status should require the same level of approval as QUIPs themselves, though. Andre' From mwoehlke.floss at gmail.com Tue Apr 25 20:45:12 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 25 Apr 2017 14:45:12 -0400 Subject: [Development] QList In-Reply-To: <31771025.Xza7NClrka@tjmaciei-mobl1> References: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> <201704250814.54738.marc.mutz@kdab.com> <31771025.Xza7NClrka@tjmaciei-mobl1> Message-ID: <58FF9938.2030708@gmail.com> On 2017-04-25 09:48, Thiago Macieira wrote: > Basically the discussion is: what should happen to QArrayList or > QArrayList? > > a) fail to compile > b) become an array list > c) become a vector > > I point out that (c) is what QList does, and we don't need the same behaviour > as QList already has. > > Marc proposed (a), which is the simplest solution to the problem. I wanted > (b), which would require duplication of code and Marc was unwilling to do > that. Why would a container type fail to compile for such basic types? For what types *would* it compile? It would help for context if people didn't have to read the review request. (Okay, having gone and read the review request...) FWIW, I think (b) makes more long-term sense... if we provide a container type whose purpose is to makes explicit guarantees about indirect storage and guaranteed reference stability, I'd hope that container would work for *all* types. Maybe an alternate approach makes sense? 1. Rename QList -> QArrayList. 2. Remove special case of inline storage. 3. Add QList as an alias to either QArrayList or QVector depending on T. No code duplication, no change in *observed* behavior of QList, but QList itself can be deprecated and eventually removed. (Maybe even in 6.x, since the removal is BC, and there is a work-around - declare and specialize it yourself - for anyone that for some reason can't just switch to QVector/QArrayList.) And, no, I don't think std::vector> can replace QArrayList; the item semantics are too different from std::vector. (I'd like to see a std::indirect_vector or such...) -- Matthew From mwoehlke.floss at gmail.com Tue Apr 25 20:45:12 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 25 Apr 2017 14:45:12 -0400 Subject: [Development] QList In-Reply-To: <31771025.Xza7NClrka@tjmaciei-mobl1> References: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> <201704250814.54738.marc.mutz@kdab.com> <31771025.Xza7NClrka@tjmaciei-mobl1> Message-ID: <58FF9938.2030708@gmail.com> On 2017-04-25 09:48, Thiago Macieira wrote: > Basically the discussion is: what should happen to QArrayList or > QArrayList? > > a) fail to compile > b) become an array list > c) become a vector > > I point out that (c) is what QList does, and we don't need the same behaviour > as QList already has. > > Marc proposed (a), which is the simplest solution to the problem. I wanted > (b), which would require duplication of code and Marc was unwilling to do > that. Why would a container type fail to compile for such basic types? For what types *would* it compile? It would help for context if people didn't have to read the review request. (Okay, having gone and read the review request...) FWIW, I think (b) makes more long-term sense... if we provide a container type whose purpose is to makes explicit guarantees about indirect storage and guaranteed reference stability, I'd hope that container would work for *all* types. Maybe an alternate approach makes sense? 1. Rename QList -> QArrayList. 2. Remove special case of inline storage. 3. Add QList as an alias to either QArrayList or QVector depending on T. No code duplication, no change in *observed* behavior of QList, but QList itself can be deprecated and eventually removed. (Maybe even in 6.x, since the removal is BC, and there is a work-around - declare and specialize it yourself - for anyone that for some reason can't just switch to QVector/QArrayList.) And, no, I don't think std::vector> can replace QArrayList; the item semantics are too different from std::vector. (I'd like to see a std::indirect_vector or such...) -- Matthew From marc.mutz at kdab.com Tue Apr 25 20:59:45 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 25 Apr 2017 20:59:45 +0200 Subject: [Development] QList In-Reply-To: <58FF9938.2030708@gmail.com> References: <26fb8804-af51-4a30-d0e5-02e3853155e7@familiesomers.nl> <201704250814.54738.marc.mutz@kdab.com> <31771025.Xza7NClrka@tjmaciei-mobl1> <58FF9938.2030708@gmail.com> Message-ID: <5a22ed1fddc245e10f3496ab637b321d@kdab.com> On 2017-04-25 20:45, Matthew Woehlke wrote: > On 2017-04-25 09:48, Thiago Macieira wrote: >> Basically the discussion is: what should happen to QArrayList or >> QArrayList? >> >> a) fail to compile >> b) become an array list >> c) become a vector >> >> I point out that (c) is what QList does, and we don't need the same >> behaviour >> as QList already has. >> >> Marc proposed (a), which is the simplest solution to the problem. I >> wanted >> (b), which would require duplication of code and Marc was unwilling to >> do >> that. > > Why would a container type fail to compile for such basic types? For > what types *would* it compile? It would help for context if people > didn't have to read the review request. > > (Okay, having gone and read the review request...) > > FWIW, I think (b) makes more long-term sense... if we provide a > container type whose purpose is to makes explicit guarantees about > indirect storage and guaranteed reference stability, I'd hope that > container would work for *all* types. > > Maybe an alternate approach makes sense? > > 1. Rename QList -> QArrayList. > 2. Remove special case of inline storage. > 3. Add QList as an alias to either QArrayList or QVector > depending on T. > > No code duplication, no change in *observed* behavior of QList, but > QList itself can be deprecated and eventually removed. (Maybe even in > 6.x, since the removal is BC, and there is a work-around - declare and > specialize it yourself - for anyone that for some reason can't just > switch to QVector/QArrayList.) > > And, no, I don't think std::vector> can replace > QArrayList; the item semantics are too different from std::vector. > (I'd like to see a std::indirect_vector or such...) This is precisely what I suggested previously in this thread. For Qt 6. The discussion here is what to do in Qt 5. My opinion on this is covered in my latest QList exit strategy that you will find in this thread, too. Thanks, Marc From apoenitz at t-online.de Tue Apr 25 20:12:02 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 25 Apr 2017 20:12:02 +0200 Subject: [Development] Introductions? In-Reply-To: References: Message-ID: <20170425181202.GA2171@klara.mpi.htwm.de> On Tue, Apr 25, 2017 at 08:09:50AM +0000, Edward Welbourne wrote: > Steve Schilz asked me (24 April 2017 19:10) a pertinent question (heavily edited): > > I’m not really sure what/where your role is… and I’m curious. > > Perhaps an introduction on the mailing list (say, from Lars Knoll?) > > for people further out in the Qt orbit is in order, or perhaps I > > missed it? > > which prompts me to a suggestion, as much the same is relevant for any > approver or maintainer: perhaps we should tweak our process for > introducing candidates for those stations within the community; ask that > each introduce self in the course of it - possibly *after* we've made > our decision, so we won't be prejudiced by their weird hobbies. ISTR > Lars, when proposing me, just linked to my review history in gerrit; > that probably should suffice for the decision on whether to accept a > candidate - but it might be worth, once the decision is made, as a > matter of course, having the new approver or maintainer introduce self, > or link to web pages that do so. That could be a short summary of > career, hobbies and life, like > > I've been making software less bad for about three decades, starting > in 1982, with several breaks. I've only had limited exposure to Qt > prior to joining the Core and Network team at TQtC a year and a half > ago; and I'm (not so) secretly a closet C programmer still learning > new things in C++. I refactor algebra as a hobby and write about > various topics on a web-site [0] that deserves more of my time than > I've lately found the enthusiasm to spend on it. > > Or it could just be a link to a CV [1], if you have it on-line. > > [0] http://www.chaos.org.uk/~eddy/ > [1] http://www.chaos.org.uk/~eddy/cv/ > (a little out of date, I now notice) > > Doing this might leave more of us with a sense of who each other are, > which seems like a natural thing in a community. > > What do folk think ? -2 Andre' From thiago.macieira at intel.com Tue Apr 25 21:28:53 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Apr 2017 16:28:53 -0300 Subject: [Development] Use of std::function in Qt API In-Reply-To: <20170425173050.GA1654@klara.mpi.htwm.de> References: <1539354.QoJSJod02y@tjmaciei-mobl1> <20170425173050.GA1654@klara.mpi.htwm.de> Message-ID: <1670982.G9eVHbBear@tjmaciei-mobl1> On Tuesday, 25 April 2017 14:30:50 -03 André Pönitz wrote: > > Why does it need to be versioned on a per-branch basis? Because of when we > > deprecate older compilers, we can update the list? > > Since the rules will likely differ per branch I actually think it's > a good idea to have the rules close to the locations to which they > apply. > > Changing files with rules with QUIP status should require the same > level of approval as QUIPs themselves, though. Fair enough, that makes sense. Last time we went through this, the file that was proposed was in a format I had no idea how to read. Let's use the file format that we have a generator for: qdoc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Apr 25 21:35:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Apr 2017 16:35:01 -0300 Subject: [Development] QList In-Reply-To: <58FF9938.2030708@gmail.com> References: <31771025.Xza7NClrka@tjmaciei-mobl1> <58FF9938.2030708@gmail.com> Message-ID: <373313771.XDykYE3meA@tjmaciei-mobl1> On Tuesday, 25 April 2017 15:45:12 -03 Matthew Woehlke wrote: > Maybe an alternate approach makes sense? > > 1. Rename QList -> QArrayList. > 2. Remove special case of inline storage. > 3. Add QList as an alias to either QArrayList or QVector > depending on T. QVector and QList don't have the same API. They're slightly different. What'sm ore, QList has a beginning-of-list optimisation, whereas QVector doesn't (not even my copy, I stopped development shortly before I got to that part, even if I did add a QArrayData::GrowsBackward flag to support the case). Also note that QList is different from QVector. QList would need to be backed by QVector and a proper casting. We can't use an alias either, we'd need a full class, with constructors, destructors, etc., to keep binary compatibility. And I don't think we can keep data compatibility, as QList's internals are very different from QVector's (different shared_null, different allocation strategies, different deallocation function, etc.). So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we don't want this mess, so QList as it is simply goes away. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alex at vikingsoft.eu Tue Apr 25 22:49:16 2017 From: alex at vikingsoft.eu (Alejandro Exojo) Date: Tue, 25 Apr 2017 22:49:16 +0200 Subject: [Development] QList In-Reply-To: <373313771.XDykYE3meA@tjmaciei-mobl1> References: <58FF9938.2030708@gmail.com> <373313771.XDykYE3meA@tjmaciei-mobl1> Message-ID: <2153094.IffkD5fuS9@walt> On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote: > QVector and QList don't have the same API. They're slightly different. > What'sm ore, QList has a beginning-of-list optimisation, whereas QVector > doesn't (not even my copy, I stopped development shortly before I got to > that part, even if I did add a QArrayData::GrowsBackward flag to support > the case). > (...) > So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we > don't want this mess, so QList as it is simply goes away. By the way, which is the exit strategy for QQueue? Specially given the first paragraph that I quoted. It's been a while since the whole thread, but I don't think it's been mentioned, and given that Ville will be making a summary, it's worth refreshing, I think. It's hard to measure how common the usage of a class is, but I think that QList is quite a common use case for when you have something that is similar enough to a queue, but not necessarily strict. Like when you add pointers to requests to the pending ones list. Most likely the ones added before will be removed before. So what's the suggested alternative here? std::deque? -- Viking Software, Qt and C++ developers for hire http://www.vikingsoft.eu From thiago.macieira at intel.com Tue Apr 25 23:04:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Apr 2017 18:04:43 -0300 Subject: [Development] QList In-Reply-To: <2153094.IffkD5fuS9@walt> References: <373313771.XDykYE3meA@tjmaciei-mobl1> <2153094.IffkD5fuS9@walt> Message-ID: <1551729.UuXyyjN8vl@tjmaciei-mobl1> On Tuesday, 25 April 2017 17:49:16 -03 Alejandro Exojo wrote: > On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote: > > QVector and QList don't have the same API. They're slightly different. > > What'sm ore, QList has a beginning-of-list optimisation, whereas QVector > > doesn't (not even my copy, I stopped development shortly before I got to > > that part, even if I did add a QArrayData::GrowsBackward flag to support > > the case). > > > > (...) > > > > So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we > > don't want this mess, so QList as it is simply goes away. > > By the way, which is the exit strategy for QQueue? Do we need one? The only reason that QQueue uses QList is because QList has that takeFirst() optimisation, while QVector does not. Once we implement that for QVector, we should be able to use QQueue with QVector too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed Apr 26 07:02:49 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 26 Apr 2017 07:02:49 +0200 Subject: [Development] QList In-Reply-To: <1551729.UuXyyjN8vl@tjmaciei-mobl1> References: <373313771.XDykYE3meA@tjmaciei-mobl1> <2153094.IffkD5fuS9@walt> <1551729.UuXyyjN8vl@tjmaciei-mobl1> Message-ID: On 2017-04-25 23:04, Thiago Macieira wrote: > On Tuesday, 25 April 2017 17:49:16 -03 Alejandro Exojo wrote: >> On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote: >> > QVector and QList don't have the same API. They're slightly different. >> > What'sm ore, QList has a beginning-of-list optimisation, whereas QVector >> > doesn't (not even my copy, I stopped development shortly before I got to >> > that part, even if I did add a QArrayData::GrowsBackward flag to support >> > the case). >> > >> > (...) >> > >> > So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we >> > don't want this mess, so QList as it is simply goes away. >> >> By the way, which is the exit strategy for QQueue? > > Do we need one? > > The only reason that QQueue uses QList is because QList has that > takeFirst() > optimisation, while QVector does not. Once we implement that for > QVector, we > should be able to use QQueue with QVector too. FWIW: I'm against adding even more pessimising goodies to QVector. An area for push_front is such a goodie. The addition this causes is probably the reason why a QList, even for optimal payloads, is outperformed by QVector in my well-known benchmark from -Wmarc. Users that need a queue can use std::deque. If you don't iterate over it, it's a more than acceptable container. Thanks, Marc From marc.mutz at kdab.com Wed Apr 26 07:04:45 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 26 Apr 2017 07:04:45 +0200 Subject: [Development] Use of std::function in Qt API In-Reply-To: <1539354.QoJSJod02y@tjmaciei-mobl1> References: <70d61ecb8d45a49e12e8f4999c281b0f@kdab.com> <1539354.QoJSJod02y@tjmaciei-mobl1> Message-ID: <4de91cc577abe598fb8a6d263e15bd06@kdab.com> On 2017-04-25 19:41, Thiago Macieira wrote: > On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote: >> On 2017-04-25 16:34, Lars Knoll wrote: >> [...] >> >> > But I agree with Thiago, that we should have this written down in a >> > QUIP, ideally with a list of the classes we consider ok to use in our >> > APIs. >> >> [...] >> >> I'd make the QUIP define the updated BC guarantee. The list of std >> types >> available for use in Qt APIs should be in QtBase Git, though, to be >> versioned on a per-branch basis. > > Why does it need to be versioned on a per-branch basis? Because of when > we > deprecate older compilers, we can update the list? Correct. From marc.mutz at kdab.com Wed Apr 26 08:39:52 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 26 Apr 2017 08:39:52 +0200 Subject: [Development] Introductions? In-Reply-To: References: Message-ID: <201704260839.52590.marc.mutz@kdab.com> On Tuesday 25 April 2017 10:09:50 Edward Welbourne wrote: [,,,] > ask that > each introduce self in the course of it - possibly *after* we've made > our decision, so we won't be prejudiced by their weird hobbies. ISTR > Lars, when proposing me, just linked to my review history in gerrit; > that probably should suffice for the decision on whether to accept a > candidate - but it might be worth, once the decision is made, as a > matter of course, having the new approver or maintainer introduce self, > or link to web pages that do so. [...] +1 http://lists.qt-project.org/pipermail/development/2012-August/005697.html Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From christoph.welsch at etm.at Wed Apr 26 10:01:06 2017 From: christoph.welsch at etm.at (Welsch, Christoph) Date: Wed, 26 Apr 2017 08:01:06 +0000 Subject: [Development] Automatic detection of Visual Studio Compiler Message-ID: Hi, I've noticed that in QT 5.9 beta 2 the mkspecs for Visual Studio have changed to some kind of automatic detection. If I use win32-msvc, it seems that the studio version is not correctly detected and the configure script fails. 2017-04-25 15:47:56: Info: creating super cache file D:\QtBuild\Qt-Win64\build\.qmake.super Project ERROR: msvc-version.conf loaded but QMAKE_MSC_VER isn't set If I set the variables MSC_VER = 1900 MSVC_VER = 14.0 In the win32-msvc/qmake.conf manually, it works. My Configure call: D:/QtBuild/src/qt-everywhere-opensource-src-5.9.0-beta/configure.bat -commercial -confirm-license -prefix D:/QtBuild/Qt-Win64/installdir/ -openssl -force-debug-info -nomake examples -nomake tests -release -skip qtwebengine -icu -qt-zlib -opengl dynamic -I D:/QtBuild/Qt-Win64/Qt5-WinDeps-64bit/openssl-win64\include -L D:/QtBuild/Qt-Win64/Qt5-WinDeps-64bit/openssl-win64\lib -I D:/QtBuild/Qt-Win64/Qt5-WinDeps-64bit/windeps/icu4c/icu/include\ -L D:/QtBuild/Qt-Win64/Qt5-WinDeps-64bit/windeps/icu4c/icu/lib64\ Is there anything else to it that I might be missing? Best Regrads, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at qt.io Wed Apr 26 11:23:44 2017 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Wed, 26 Apr 2017 11:23:44 +0200 Subject: [Development] Automatic detection of Visual Studio Compiler In-Reply-To: References: Message-ID: <10e28b10-94cc-b485-691c-83aa1de9ebf4@qt.io> On 26/04/2017 10:01, Welsch, Christoph wrote: > I’ve noticed that in QT 5.9 beta 2 the mkspecs for Visual Studio have > changed to some kind of automatic detection. If I use win32-msvc, it > seems that the studio version is not correctly detected and the > configure script fails. As far as I can tell your configure line looks OK. Please create a bug report for this at https://bugreports.qt.io/ to track this. Please include a description of how you've set up your build environment, exact VS version etc. BR, Joerg From thiago.macieira at intel.com Wed Apr 26 14:34:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 26 Apr 2017 09:34:39 -0300 Subject: [Development] QList In-Reply-To: References: <1551729.UuXyyjN8vl@tjmaciei-mobl1> Message-ID: <2171962.kofFcnayBM@tjmaciei-mobl1> On Wednesday, 26 April 2017 02:02:49 -03 Marc Mutz wrote: > FWIW: I'm against adding even more pessimising goodies to QVector. An > area for push_front is such a goodie. The addition this causes is > probably the reason why a QList, even for optimal payloads, is > outperformed by QVector in my well-known benchmark from -Wmarc. Users > that need a queue can use std::deque. If you don't iterate over it, it's > a more than acceptable container. We don't need to preallocate area in the beginning. But in the case the user is doing prepend() or takeFirst(), the optimisation can kick in. The former can happen entirely behind the scenes by QArrayData; the latter can be as simple as advacing the begin pointer instead of memmove()ing the elements. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Friedemann.Kleint at qt.io Wed Apr 26 14:36:01 2017 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Wed, 26 Apr 2017 14:36:01 +0200 Subject: [Development] Automatic detection of Visual Studio Compiler In-Reply-To: <10e28b10-94cc-b485-691c-83aa1de9ebf4@qt.io> References: <10e28b10-94cc-b485-691c-83aa1de9ebf4@qt.io> Message-ID: Hi, please make sure you don't have QMAKESPEC set in the environment (see https://bugreports.qt.io/browse/QTBUG-60016 ). Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From thiago.macieira at intel.com Wed Apr 26 14:37:32 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 26 Apr 2017 09:37:32 -0300 Subject: [Development] Automatic detection of Visual Studio Compiler In-Reply-To: <10e28b10-94cc-b485-691c-83aa1de9ebf4@qt.io> References: <10e28b10-94cc-b485-691c-83aa1de9ebf4@qt.io> Message-ID: <2271974.3ORrZp2LNW@tjmaciei-mobl1> On Wednesday, 26 April 2017 06:23:44 -03 Joerg Bornemann wrote: > On 26/04/2017 10:01, Welsch, Christoph wrote: > > Project ERROR: msvc-version.conf loaded but QMAKE_MSC_VER isn't set > > I’ve noticed that in QT 5.9 beta 2 the mkspecs for Visual Studio have > > changed to some kind of automatic detection. If I use win32-msvc, it > > seems that the studio version is not correctly detected and the > > configure script fails. > > As far as I can tell your configure line looks OK. Please create a bug > report for this at https://bugreports.qt.io/ to track this. > Please include a description of how you've set up your build > environment, exact VS version etc. Before you do, please NUKE your build dir and make sure your source dir is squeaky clean (delete and unpack again). Another person reported the same error and this solved the configure step for them. When I had that issue, it was a matter of cleaning up. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alex at vikingsoft.eu Wed Apr 26 23:33:51 2017 From: alex at vikingsoft.eu (Alejandro Exojo) Date: Wed, 26 Apr 2017 23:33:51 +0200 Subject: [Development] QList In-Reply-To: References: <1551729.UuXyyjN8vl@tjmaciei-mobl1> Message-ID: <14787341.SjEeMPdzPT@walt> On Wednesday 26 April 2017 07:02:49 Marc Mutz wrote: > FWIW: I'm against adding even more pessimising goodies to QVector. An > area for push_front is such a goodie. The addition this causes is > probably the reason why a QList, even for optimal payloads, is > outperformed by QVector in my well-known benchmark from -Wmarc. Users > that need a queue can use std::deque. If you don't iterate over it, it's > a more than acceptable container. I'm afraid is not so well-known. The benchmark I know is found in: https://marcmutz.wordpress.com/effective-qt/containers/ There you say: "I didn’t check prepending, because the results should be comparable to appending, at least for those containers which efficiently support them. I also didn’t test insertions in the middle, since they’re rather rare." The closest I know is the one that Stroustrup has shown in his talks (thanks Ville for the link; I mentioned this in other thread, but I did not know which conference was): https://isocpp.org/blog/2014/06/stroustrup-lists But that's a comparison of std::list vs std::vector, and the benchmark is just with the container holding integers. -- Viking Software, Qt and C++ developers for hire http://www.vikingsoft.eu From annulen at yandex.ru Wed Apr 26 23:38:56 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 27 Apr 2017 00:38:56 +0300 Subject: [Development] QList In-Reply-To: References: <373313771.XDykYE3meA@tjmaciei-mobl1> <2153094.IffkD5fuS9@walt> <1551729.UuXyyjN8vl@tjmaciei-mobl1> Message-ID: <630451493242736@web49j.yandex.ru> 26.04.2017, 08:04, "Marc Mutz" : > On 2017-04-25 23:04, Thiago Macieira wrote: >>  On Tuesday, 25 April 2017 17:49:16 -03 Alejandro Exojo wrote: >>>  On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote: >>>  > QVector and QList don't have the same API. They're slightly different. >>>  > What'sm ore, QList has a beginning-of-list optimisation, whereas QVector >>>  > doesn't (not even my copy, I stopped development shortly before I got to >>>  > that part, even if I did add a QArrayData::GrowsBackward flag to support >>>  > the case). >>>  > >>>  > (...) >>>  > >>>  > So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we >>>  > don't want this mess, so QList as it is simply goes away. >>> >>>  By the way, which is the exit strategy for QQueue? >> >>  Do we need one? >> >>  The only reason that QQueue uses QList is because QList has that >>  takeFirst() >>  optimisation, while QVector does not. Once we implement that for >>  QVector, we >>  should be able to use QQueue with QVector too. > > FWIW: I'm against adding even more pessimising goodies to QVector. An > area for push_front is such a goodie. The addition this causes is > probably the reason why a QList, even for optimal payloads, is > outperformed by QVector in my well-known benchmark from -Wmarc. Users > that need a queue can use std::deque. If you don't iterate over it, it's > a more than acceptable container. std::deque is not a contiguous container, unlike QList or QVector, so it cannot be a drop-in replacement. > > Thanks, > Marc > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From marc.mutz at kdab.com Thu Apr 27 06:19:16 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 27 Apr 2017 06:19:16 +0200 Subject: [Development] QList In-Reply-To: <630451493242736@web49j.yandex.ru> References: <373313771.XDykYE3meA@tjmaciei-mobl1> <2153094.IffkD5fuS9@walt> <1551729.UuXyyjN8vl@tjmaciei-mobl1> <630451493242736@web49j.yandex.ru> Message-ID: On 2017-04-26 23:38, Konstantin Tokarev wrote: > 26.04.2017, 08:04, "Marc Mutz" : >> Users >> that need a queue can use std::deque. If you don't iterate over it, >> it's >> a more than acceptable container. > > std::deque is not a contiguous container, unlike QList or QVector Here's news for you: QList is not a contiguous container. From marc.mutz at kdab.com Thu Apr 27 06:33:09 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 27 Apr 2017 06:33:09 +0200 Subject: [Development] QList In-Reply-To: <14787341.SjEeMPdzPT@walt> References: <1551729.UuXyyjN8vl@tjmaciei-mobl1> <14787341.SjEeMPdzPT@walt> Message-ID: <64a3e8c3eaebc52ee751f56b686d195d@kdab.com> On 2017-04-26 23:33, Alejandro Exojo wrote: > On Wednesday 26 April 2017 07:02:49 Marc Mutz wrote: >> FWIW: I'm against adding even more pessimising goodies to QVector. An >> area for push_front is such a goodie. The addition this causes is >> probably the reason why a QList, even for optimal payloads, is >> outperformed by QVector in my well-known benchmark from -Wmarc. Users >> that need a queue can use std::deque. If you don't iterate over it, >> it's >> a more than acceptable container. > > I'm afraid is not so well-known. The benchmark I know is found in: > > https://marcmutz.wordpress.com/effective-qt/containers/ Yes, that was sloppy of me. Of course, if you optimise for a use-case (like repeated prepends), then that use-case should benefit. The fear I have is that, like in QList, this corner-case optimisation will pessimise the common case (appends, iterations). And I consider that not acceptable. If you need fast prepends, pay the price by using a std::deque (or a vector, or a vector with separate start/end indexes), but don't make every user of a vector pay for it. This is what happened in QList, which, to get to its begin(), needs to perform an addition (and, without having checked, two to reach its end()). And that's, I suspect, what makes QVector outperform QList even for QString payloads, as seen in, say, the first diagram in http://www.kdab.com/~marc/effective-qt/containers/results-append-tickcounter-linux_x86-64_473_gcc43-zoom-qt.html (uncheck all of QList/QVector). Thanks, Marc From heikki.halmet at qt.io Thu Apr 27 11:29:08 2017 From: heikki.halmet at qt.io (Heikki Halmet) Date: Thu, 27 Apr 2017 09:29:08 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes Message-ID: Hi, Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. Please comment if the proposal is insufficient or the changes are unacceptable somehow. Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: RHEL 7.2 -> RHEL 7.3 (Any benefits?) OpenSUSE 42.1 -> OpenSUSE 42.2 Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 INTEGRITY GHS 2016.5.4 -> 2017.1.x Support for Android 8 (if available on time) iOS 11 support (if available on time. Current rumors -> september) MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. This means that we can only use Preview release of 10.13 for testing before final official release is out. That can cause situation that we don't have enough time to get 10.13 in before 5.10 release so we can't give guarantees that 10.13 will be supported in 5.10. NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. With all others we'll do the best we can but we can't commit that those will be supported in 5.10. Best regards Heikki Halmet The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland Email: heikki.halmet at qt.io Phone: +358408672112 www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Thu Apr 27 13:00:26 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 27 Apr 2017 11:00:26 +0000 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.0' started Message-ID: Hi, We have soft branched '5.9.0' from '5.9'. Please start using '5.9.0' for new changes targeted to Qt 5.9.0 release. There should be enough time to finalize ongoing changes in '5.9'; final downmerge will happen Thursday 4th May. br, Jani From Jake.Petroules at qt.io Thu Apr 27 13:11:51 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 27 Apr 2017 11:11:51 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: Message-ID: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> > On Apr 27, 2017, at 2:29 AM, Heikki Halmet wrote: > > Hi, > > Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. > Please comment if the proposal is insufficient or the changes are unacceptable somehow. > > Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > RHEL 7.2 -> RHEL 7.3 (Any benefits?) > OpenSUSE 42.1 -> OpenSUSE 42.2 > Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. > macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) 8.3.2, please. > Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > INTEGRITY GHS 2016.5.4 -> 2017.1.x > Support for Android 8 (if available on time) > iOS 11 support (if available on time. Current rumors -> september) > > MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. > This means that we can only use Preview release of 10.13 for testing before final official release is out. > That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. How do you know it won't be called macOS 11? ;) The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. > > NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. > With all others we'll do the best we can but we can't commit that those will be supported in 5.10. > > > > Best regards > Heikki Halmet > > The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland > Email: heikki.halmet at qt.io > Phone: +358408672112 > www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Shawn.Rutledge at qt.io Thu Apr 27 13:58:57 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 27 Apr 2017 11:58:57 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: Message-ID: <55857DDB-4288-4962-9088-C930E98FC59A@qt.io> > On 27 Apr 2017, at 11:29, Heikki Halmet wrote: > > Hi, > > Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. > Please comment if the proposal is insufficient or the changes are unacceptable somehow. > > Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > RHEL 7.2 -> RHEL 7.3 (Any benefits?) > OpenSUSE 42.1 -> OpenSUSE 42.2 > Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) > macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) > Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > INTEGRITY GHS 2016.5.4 -> 2017.1.x > Support for Android 8 (if available on time) > iOS 11 support (if available on time. Current rumors -> september) > > MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. > This means that we can only use Preview release of 10.13 for testing before final official release is out. > That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. > > NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. > With all others we'll do the best we can but we can't commit that those will be supported in 5.10. Giuseppe was asking on IRC for GCC 7 and Clang 4. Which are quite bleeding edge for almost all distros at this point, I suppose; Arch recently got Clang 4 but not GCC 7 yet. From tero.kojo at qt.io Thu Apr 27 14:00:22 2017 From: tero.kojo at qt.io (Tero Kojo) Date: Thu, 27 Apr 2017 12:00:22 +0000 Subject: [Development] Qt World Summit 2017 Call for Presentations Message-ID: Hello, This year Qt World Summit will be taking place in Berlin between 10th and 12th October. The venue will be the bcc, Berlin Congress Center. You can find more information on the event site at https://www.qtworldsummit.com/ The Call for Presentations has just been published on the Qt Blog: http://blog.qt.io/blog/2017/04/27/qt-world-summit-2017-call-presentations/ Please read through the post and then submit your presentation idea for review. As a summary, the main topics of interest this year are: * Future of software with Qt * 3D User interfaces and Graphics, including AR and VR * Automotive solutions * Application development and Qt enabling application ecosystems * Tools, methods and processes for the embedded device life-cycle * Automation systems As always this is not a complete list, and we are open to all Qt related presentations. Qt World Summit 2017 will also feature a business track, where the topics of interest include: * Cases and examples of Qt in use * Time to market * Software life-cycle * Development team setup and composition * Ecosystems from the business aspect Early Bird tickets are on sale now at: https://www.qtworldsummit.com/ The site will be updated as we have more information to share. This year Qt World Summit will also feature Qt Contributors' Days right before the actual Qt World Summit. The Qt Contributors' Days will replace Qt Contributors' Summit for this year. Everyone who has contributed in any way (code, bugs, answering questions on forums and lists) is welcome to the Contributors' Days. Please note, this year you will need a ticket for Contributors' Days. These are available form https://www.qtworldsummit.com/ For practical reasons we have had to put a nominal fee on the Qt Contributors' Days. If you are sure you are coming, and the nominal fee is an issue, please contact me directly. Best Regards, Tero -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.voutilainen at gmail.com Thu Apr 27 14:02:33 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 27 Apr 2017 15:02:33 +0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <55857DDB-4288-4962-9088-C930E98FC59A@qt.io> References: <55857DDB-4288-4962-9088-C930E98FC59A@qt.io> Message-ID: On 27 April 2017 at 14:58, Shawn Rutledge wrote: > Giuseppe was asking on IRC for GCC 7 and Clang 4. Which are quite bleeding edge for almost all distros at this point, I suppose; Arch recently got Clang 4 but not GCC 7 yet. That's because GCC 7 hasn't been released yet, but it will be soon, and then it will be in almost every linux distro as a system compiler before we ship Qt 5.10, so I think it would be quite wise to have it in CI as soon as possible. From bstottle at ford.com Thu Apr 27 14:07:10 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Thu, 27 Apr 2017 12:07:10 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <55857DDB-4288-4962-9088-C930E98FC59A@qt.io> References: <55857DDB-4288-4962-9088-C930E98FC59A@qt.io> Message-ID: > Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html That page has the following for QNX: “QNX 6.6.0, 7.0 (armv7le and x86)” As QNX 7.0 includes 64-bit support, are aarch64le and x86_64 supported on 5.9? If not, can they be added for 5.10? Regards, Brett From tuukka.turunen at qt.io Thu Apr 27 16:07:48 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 27 Apr 2017 14:07:48 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> Message-ID: <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> Hi, Related to the Apple platforms, could we consider the following for Qt 5.10: - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) Yours, Tuukka On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" wrote: > On Apr 27, 2017, at 2:29 AM, Heikki Halmet wrote: > > Hi, > > Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. > Please comment if the proposal is insufficient or the changes are unacceptable somehow. > > Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > RHEL 7.2 -> RHEL 7.3 (Any benefits?) > OpenSUSE 42.1 -> OpenSUSE 42.2 > Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. > macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) 8.3.2, please. > Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > INTEGRITY GHS 2016.5.4 -> 2017.1.x > Support for Android 8 (if available on time) > iOS 11 support (if available on time. Current rumors -> september) > > MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. > This means that we can only use Preview release of 10.13 for testing before final official release is out. > That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. How do you know it won't be called macOS 11? ;) The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. > > NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. > With all others we'll do the best we can but we can't commit that those will be supported in 5.10. > > > > Best regards > Heikki Halmet > > The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland > Email: heikki.halmet at qt.io > Phone: +358408672112 > www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Thu Apr 27 16:34:41 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 27 Apr 2017 14:34:41 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io>, <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> Message-ID: Correcting myself: Drop ARMv7 and ARMv7s support for iOS, meaning we only support 64bit iOS devices from Qt 5.10 onwards. Yours, Tuukka ________________________________ From: Development on behalf of Tuukka Turunen Sent: Thursday, April 27, 2017 4:07:48 PM To: Jake Petroules; Heikki Halmet; development at qt-project.org Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations changes Hi, Related to the Apple platforms, could we consider the following for Qt 5.10: - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) Yours, Tuukka On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" wrote: > On Apr 27, 2017, at 2:29 AM, Heikki Halmet wrote: > > Hi, > > Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. > Please comment if the proposal is insufficient or the changes are unacceptable somehow. > > Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > RHEL 7.2 -> RHEL 7.3 (Any benefits?) > OpenSUSE 42.1 -> OpenSUSE 42.2 > Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. > macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) 8.3.2, please. > Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > INTEGRITY GHS 2016.5.4 -> 2017.1.x > Support for Android 8 (if available on time) > iOS 11 support (if available on time. Current rumors -> september) > > MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. > This means that we can only use Preview release of 10.13 for testing before final official release is out. > That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. How do you know it won't be called macOS 11? ;) The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. > > NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. > With all others we'll do the best we can but we can't commit that those will be supported in 5.10. > > > > Best regards > Heikki Halmet > > The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland > Email: heikki.halmet at qt.io > Phone: +358408672112 > www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmcdonnell at blackberry.com Thu Apr 27 16:40:04 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Thu, 27 Apr 2017 14:40:04 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <55857DDB-4288-4962-9088-C930E98FC59A@qt.io> Message-ID: The mkspecs are there. https://codereview.qt-project.org/#/c/192579/ is needed to make them work (again). On 2017-04-27, 8:07 AM, "Development on behalf of Stottlemyer, Brett (B.S.)" wrote: >> Please refer to Qt 5.9 Supported platforms -> >>http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > >That page has the following for QNX: ³QNX 6.6.0, 7.0 (armv7le and x86)² > >As QNX 7.0 includes 64-bit support, are aarch64le and x86_64 supported on >5.9? If not, can they be added for 5.10? > >Regards, >Brett > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From bogdan.vatra at kdab.com Thu Apr 27 16:40:21 2017 From: bogdan.vatra at kdab.com (BogDan Vatra) Date: Thu, 27 Apr 2017 17:40:21 +0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: Message-ID: For Android I'd like to support 64 bit platforms (arm and x86) BogDan. On April 27, 2017 12:29:08 PM GMT+03:00, Heikki Halmet wrote: >Hi, > > > >Below we have proposal for changes in supported platforms and >configurations from Qt 5.9 to 5.10. > >Please comment if the proposal is insufficient or the changes are >unacceptable somehow. > > > >Please refer to Qt 5.9 Supported platforms -> >http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > > >LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > >RHEL 7.2 -> RHEL 7.3 (Any benefits?) > >OpenSUSE 42.1 -> OpenSUSE 42.2 > >Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > >macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) > >macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) > >Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > >Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > >INTEGRITY GHS 2016.5.4 -> 2017.1.x > >Support for Android 8 (if available on time) > >iOS 11 support (if available on time. Current rumors -> september) > > > >MacOS 10.13 will be released September 2017 hopefully. Feature Freeze >for 5.10 is at the beginning of August. > >This means that we can only use Preview release of 10.13 for testing >before final official release is out. > >That can cause situation that we don't have enough time to get 10.13 in >before 5.10 release so we can't give guarantees that 10.13 will be >supported in 5.10. > > > >NOTE! We will commit to wanted platform and software changes as long as >those are available straight after 5.9 release is out in the end of the >May. >With all others we'll do the best we can but we can't commit that those >will be supported in 5.10. > > > >Best regards >Heikki Halmet > >The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland >Email: heikki.halmet at qt.io >Phone: +358408672112 >www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: >@qtproject, @Qtproject Facebook: >www.facebook.com/qt -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Apr 27 16:57:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 27 Apr 2017 11:57:58 -0300 Subject: [Development] QList In-Reply-To: References: <630451493242736@web49j.yandex.ru> Message-ID: <5004229.iNTmZlkdfe@tjmaciei-mobl1> On Thursday, 27 April 2017 01:19:16 -03 Marc Mutz wrote: > On 2017-04-26 23:38, Konstantin Tokarev wrote: > > 26.04.2017, 08:04, "Marc Mutz" : > >> Users > >> that need a queue can use std::deque. If you don't iterate over it, > >> it's > >> a more than acceptable container. > > > > std::deque is not a contiguous container, unlike QList or QVector > > Here's news for you: QList is not a contiguous container. Sometimes it is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Thu Apr 27 16:59:12 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 27 Apr 2017 14:59:12 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> Message-ID: <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> > On Apr 27, 2017, at 7:07 AM, Tuukka Turunen wrote: > > > Hi, > > Related to the Apple platforms, could we consider the following for Qt 5.10: > - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) > - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional. As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing... Something like the following seems nice: Tier 1 - the most rigorously tested configurations, tested in CI Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). > - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :) Current list is: - Qt 5.6 - supports macOS 10.7 and up - Qt 5.7 - supports macOS 10.8 and up - Qt 5.8 - supports macOS 10.9 and up - Qt 5.9 - supports macOS 10.10 and up Planned: - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10 - Qt 5.11 - supports macOS 10.11 and up By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported". If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright. But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10) > > Yours, > > Tuukka > > On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" wrote: > > >> On Apr 27, 2017, at 2:29 AM, Heikki Halmet wrote: >> >> Hi, >> >> Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. >> Please comment if the proposal is insufficient or the changes are unacceptable somehow. >> >> Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html >> >> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: >> RHEL 7.2 -> RHEL 7.3 (Any benefits?) >> OpenSUSE 42.1 -> OpenSUSE 42.2 >> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) >> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) > > Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. > >> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) > > 8.3.2, please. > >> Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 >> Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 >> INTEGRITY GHS 2016.5.4 -> 2017.1.x >> Support for Android 8 (if available on time) >> iOS 11 support (if available on time. Current rumors -> september) >> >> MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. >> This means that we can only use Preview release of 10.13 for testing before final official release is out. >> That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. > > How do you know it won't be called macOS 11? ;) > > The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. > > Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. > >> >> NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. >> With all others we'll do the best we can but we can't commit that those will be supported in 5.10. >> >> >> >> Best regards >> Heikki Halmet >> >> The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland >> Email: heikki.halmet at qt.io >> Phone: +358408672112 >> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Jake.Petroules at qt.io Thu Apr 27 17:00:58 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 27 Apr 2017 15:00:58 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: Message-ID: > On Apr 27, 2017, at 7:40 AM, BogDan Vatra wrote: > > For Android I'd like to support 64 bit platforms (arm and x86) They are already supported. Feel free to compile Qt with the appropriate -arch options. Do you mean you want them in CI and want us to start shipping binaries for android amd64 and arm64? I'm not sure there's enough 64-bit devices out there to justify it yet. Android moves very slow... > > BogDan. > > On April 27, 2017 12:29:08 PM GMT+03:00, Heikki Halmet wrote: > Hi, > > > Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. > > Please comment if the proposal is insufficient or the changes are unacceptable somehow. > > > Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > > LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > > RHEL 7.2 -> RHEL 7.3 (Any benefits?) > > OpenSUSE 42.1 -> OpenSUSE 42.2 > > Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > > macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) > > macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) > > Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > > Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > > INTEGRITY GHS 2016.5.4 -> 2017.1.x > > Support for Android 8 (if available on time) > > iOS 11 support (if available on time. Current rumors -> september) > > > MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. > > This means that we can only use Preview release of 10.13 for testing before final official release is out. > > That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. > > > NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. > > With all others we'll do the best we can but we can't commit that those will be supported in 5.10. > > > > > Best regards > > Heikki Halmet > > > The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland > > Email: heikki.halmet at qt.io > > Phone: +358408672112 > > www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity._______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Thu Apr 27 17:01:03 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 27 Apr 2017 12:01:03 -0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <55857DDB-4288-4962-9088-C930E98FC59A@qt.io> Message-ID: <5437072.SWD4eWnPfH@tjmaciei-mobl1> On Thursday, 27 April 2017 09:02:33 -03 Ville Voutilainen wrote: > That's because GCC 7 hasn't been released yet, but it will be soon, > and then it will be in almost every linux distro as a system > compiler before we ship Qt 5.10, so I think it would be quite wise to > have it in CI as soon as possible. If not "before we ship 5.10", it will be the compiler of choice for Linux distros in 2018, which is when 5.10 is supposed to be used. That said, we will be testing ourselves (I've already updated my openSUSE Tumbleweed for it), so it's not like it will be broken. I've also been building Qt 5.9 with Clang 5.0 (trunk). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Wolfgang.Baron at gmx.net Thu Apr 27 22:50:08 2017 From: Wolfgang.Baron at gmx.net (Wolfgang Baron) Date: Thu, 27 Apr 2017 22:50:08 +0200 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes Message-ID: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> Hi, I would like to see msvc_2017 support on the Windows plattform for any version as soon as possible. Best regards, Wolfgang Baron From cavendish.qi at gmail.com Thu Apr 27 22:54:14 2017 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 27 Apr 2017 22:54:14 +0200 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> Message-ID: On 27 April 2017 at 22:50, Wolfgang Baron wrote: > Hi, > > I would like to see msvc_2017 support on the Windows plattform for any > version as soon as possible. That will happen soon in 5.9, please follow up https://codereview.qt-project.org/#/c/191981/ and etc. Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wolfgang.Baron at gmx.net Thu Apr 27 23:03:32 2017 From: Wolfgang.Baron at gmx.net (Wolfgang Baron) Date: Thu, 27 Apr 2017 23:03:32 +0200 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> Message-ID: HI, Am 27.04.2017 um 22:54 schrieb Liang Qi: > On 27 April 2017 at 22:50, Wolfgang Baron > wrote: > > Hi, > > I would like to see msvc_2017 support on the Windows plattform for > any version as soon as possible. > > That will happen soon in 5.9, please follow up > https://codereview.qt-project.org/#/c/191981/ and etc. Thanks, I didn't see that and don't see a "msvc2017 64-bit" for "Qt 5.9 Beta2" in the online installer, so I was afraid it would not be in the release either. Good to hear it will be there for the release! Kind regards, Wolfgang Baron -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Apr 27 23:39:29 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 27 Apr 2017 18:39:29 -0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> Message-ID: <10926758.q7UjD6t0fh@tjmaciei-mobl1> On Thursday, 27 April 2017 18:03:32 -03 Wolfgang Baron wrote: > Thanks, I didn't see that and don't see a "msvc2017 64-bit" for "Qt 5.9 > Beta2" in the online installer, so I was afraid it would not be in the > release either. Good to hear it will be there for the release! There's no need. You can use the MSVC 2015 installer.: -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Apr 27 23:37:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 27 Apr 2017 18:37:10 -0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> Message-ID: <1735160.4qW3MTuc9m@tjmaciei-mobl1> On Thursday, 27 April 2017 17:50:08 -03 Wolfgang Baron wrote: > Hi, > > I would like to see msvc_2017 support on the Windows plattform for any > version as soon as possible. Do you mean "support" as in "it works" or as in "it's tested in the CI". Because if you mean the former, it's already supported in 5.8. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Fri Apr 28 00:09:48 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 28 Apr 2017 00:09:48 +0200 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <1735160.4qW3MTuc9m@tjmaciei-mobl1> References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> <1735160.4qW3MTuc9m@tjmaciei-mobl1> Message-ID: Il 27/04/2017 23:37, Thiago Macieira ha scritto: > Because if you mean the former, it's already supported in 5.8. But not in 5.8.0. So, effectively, in no released 5.8 version. [grumbles] Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From lars.knoll at qt.io Fri Apr 28 08:28:23 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 28 Apr 2017 06:28:23 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> Message-ID: <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> On 27 Apr 2017, at 16:59, Jake Petroules > wrote: On Apr 27, 2017, at 7:07 AM, Tuukka Turunen > wrote: Hi, Related to the Apple platforms, could we consider the following for Qt 5.10: - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional. Agree, there is a difference between the two. What I think we should however do for 5.10 is remove 32bit support for iOS from CI and our binary packages. And that means that things will be untested on 32bit iOS, and thus is likely to break at some point. As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing… For the commercial version, it’s to a large extent up to TQtC to define the support offering. The open source project anyway does not offer any official support for the Qt versions released. All you can do is ask on the mailing lists or file a bug report and hope for the best. Or of course sit down, fix it yourself and submit a patch :) Something like the following seems nice: Tier 1 - the most rigorously tested configurations, tested in CI Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement I’m ok to describe things in tiers, as that’s what we have in practice. We don’t test e.g. FreeBSD in CI, but we will accept patches if something’s broken on that platform and someone cares enough to fix it. Same would be true for 32bit iOS in 5.10 then. But the only thing the Qt project will be able to give some guarantees for are the configurations tested in CI. Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). Dropping it has other benefits. Currently iOS is on the critical path in the CI system for qt5.git integrations and thus package creation. Dropping 32bit support going to significantly cut down on iOS compile times, and should thus lead to faster turn around times for package creation. Lars - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :) Current list is: - Qt 5.6 - supports macOS 10.7 and up - Qt 5.7 - supports macOS 10.8 and up - Qt 5.8 - supports macOS 10.9 and up - Qt 5.9 - supports macOS 10.10 and up Planned: - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10 - Qt 5.11 - supports macOS 10.11 and up By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported". If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright. But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10) Yours, Tuukka On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" on behalf of Jake.Petroules at qt.io> wrote: On Apr 27, 2017, at 2:29 AM, Heikki Halmet > wrote: Hi, Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. Please comment if the proposal is insufficient or the changes are unacceptable somehow. Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: RHEL 7.2 -> RHEL 7.3 (Any benefits?) OpenSUSE 42.1 -> OpenSUSE 42.2 Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) 8.3.2, please. Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 INTEGRITY GHS 2016.5.4 -> 2017.1.x Support for Android 8 (if available on time) iOS 11 support (if available on time. Current rumors -> september) MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. This means that we can only use Preview release of 10.13 for testing before final official release is out. That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. How do you know it won't be called macOS 11? ;) The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. With all others we'll do the best we can but we can't commit that those will be supported in 5.10. Best regards Heikki Halmet The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland Email: heikki.halmet at qt.io Phone: +358408672112 www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.vatra at kdab.com Fri Apr 28 08:43:09 2017 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Fri, 28 Apr 2017 09:43:09 +0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: Message-ID: <2197626.CNu6KINRyb@zmeu> Hi Jake, On joi, 27 aprilie 2017 15:00:58 EEST Jake Petroules wrote: > > On Apr 27, 2017, at 7:40 AM, BogDan Vatra wrote: > > > > For Android I'd like to support 64 bit platforms (arm and x86) > > > They are already supported. Feel free to compile Qt with the appropriate > -arch options. I know about that option, because, well, I implement it :). > Do you mean you want them in CI and want us to start > shipping binaries for android amd64 and arm64? Yes, this is what I mean! > I'm not sure there's enough 64-bit devices out there to justify it yet. > Android moves very slow... My hunch is that in 2016 there were shipped more Android arm64 devices than iOS ones ;-). x86_64 bins will be used only for chromebooks, though it seems google is moving way from x86 also on chromebooks, so x86_64 are low priority. Cheers, BogDan. From Simon.Hausmann at qt.io Fri Apr 28 08:43:33 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 28 Apr 2017 06:43:33 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io>, <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> Message-ID: Hi, Exactly cutting down the time it takes for the CI to complete a build of all of Qt is one of the motivation factors. And note how in dev (and bus 5.10) we are spending extra time building for WatchOS and TvOS, so it would seem like a trade to me ;) Simon On 28. Apr 2017, at 08:28, Lars Knoll > wrote: On 27 Apr 2017, at 16:59, Jake Petroules > wrote: On Apr 27, 2017, at 7:07 AM, Tuukka Turunen > wrote: Hi, Related to the Apple platforms, could we consider the following for Qt 5.10: - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional. Agree, there is a difference between the two. What I think we should however do for 5.10 is remove 32bit support for iOS from CI and our binary packages. And that means that things will be untested on 32bit iOS, and thus is likely to break at some point. As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing… For the commercial version, it’s to a large extent up to TQtC to define the support offering. The open source project anyway does not offer any official support for the Qt versions released. All you can do is ask on the mailing lists or file a bug report and hope for the best. Or of course sit down, fix it yourself and submit a patch :) Something like the following seems nice: Tier 1 - the most rigorously tested configurations, tested in CI Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement I’m ok to describe things in tiers, as that’s what we have in practice. We don’t test e.g. FreeBSD in CI, but we will accept patches if something’s broken on that platform and someone cares enough to fix it. Same would be true for 32bit iOS in 5.10 then. But the only thing the Qt project will be able to give some guarantees for are the configurations tested in CI. Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). Dropping it has other benefits. Currently iOS is on the critical path in the CI system for qt5.git integrations and thus package creation. Dropping 32bit support going to significantly cut down on iOS compile times, and should thus lead to faster turn around times for package creation. Lars - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :) Current list is: - Qt 5.6 - supports macOS 10.7 and up - Qt 5.7 - supports macOS 10.8 and up - Qt 5.8 - supports macOS 10.9 and up - Qt 5.9 - supports macOS 10.10 and up Planned: - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10 - Qt 5.11 - supports macOS 10.11 and up By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported". If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright. But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10) Yours, Tuukka On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" on behalf of Jake.Petroules at qt.io> wrote: On Apr 27, 2017, at 2:29 AM, Heikki Halmet > wrote: Hi, Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. Please comment if the proposal is insufficient or the changes are unacceptable somehow. Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: RHEL 7.2 -> RHEL 7.3 (Any benefits?) OpenSUSE 42.1 -> OpenSUSE 42.2 Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) 8.3.2, please. Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 INTEGRITY GHS 2016.5.4 -> 2017.1.x Support for Android 8 (if available on time) iOS 11 support (if available on time. Current rumors -> september) MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. This means that we can only use Preview release of 10.13 for testing before final official release is out. That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. How do you know it won't be called macOS 11? ;) The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. With all others we'll do the best we can but we can't commit that those will be supported in 5.10. Best regards Heikki Halmet The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland Email: heikki.halmet at qt.io Phone: +358408672112 www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Fri Apr 28 08:54:09 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 28 Apr 2017 06:54:09 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> Message-ID: <88DDBF45-4CB8-4596-BB3E-79C7F95C88D3@qt.io> > On 27 Apr 2017, at 16:59, Jake Petroules wrote: > > Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). Well, the latest iOS versions don’t run on devices of a certain age (and in other cases, you can upgrade but you’d better not, because you’ll regret it) - that’s their way of shaking you down. But as long as developers can keep enabling continued use of those devices somehow rather than sending them promptly to the shredder as soon as Apple wants you to, I think we should support them in their efforts, or at least not interfere. > On 27 Apr 2017, at 17:00, Jake Petroules wrote: > >> On Apr 27, 2017, at 7:40 AM, BogDan Vatra wrote: >> >> For Android I'd like to support 64 bit platforms (arm and x86) > > They are already supported. Feel free to compile Qt with the appropriate -arch options. Do you mean you want them in CI and want us to start shipping binaries for android amd64 and arm64? > > I'm not sure there's enough 64-bit devices out there to justify it yet. Android moves very slow... Lollipop came out in 2014. And there were 64-bit devices available by then. So I suspect the majority of new devices are 64-bit by now. If _users_ are slow to upgrade their devices, that’s really good on them, not going along with the planned obsolescence nonsense which is purely harmful: to your wallet, to the environment, to the sense of guilt that you feel when you do the wrong thing, and increasing inequality in the economy. Apple gets a black mark in my book for trying so hard to remove that choice. From jani.heikkinen at qt.io Fri Apr 28 08:56:22 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 28 Apr 2017 06:56:22 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> , Message-ID: Hi, Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get pre-built binaries available before final release; let's see if we can make it happen br, jani ________________________________________ From: Development on behalf of Wolfgang Baron Sent: Friday, April 28, 2017 12:03 AM To: Liang Qi Cc: development at qt-project.org Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations changes HI, Am 27.04.2017 um 22:54 schrieb Liang Qi: On 27 April 2017 at 22:50, Wolfgang Baron > wrote: Hi, I would like to see msvc_2017 support on the Windows plattform for any version as soon as possible. That will happen soon in 5.9, please follow up https://codereview.qt-project.org/#/c/191981/ and etc. Thanks, I didn't see that and don't see a "msvc2017 64-bit" for "Qt 5.9 Beta2" in the online installer, so I was afraid it would not be in the release either. Good to hear it will be there for the release! Kind regards, Wolfgang Baron From marc.mutz at kdab.com Fri Apr 28 09:35:09 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 28 Apr 2017 09:35:09 +0200 Subject: [Development] [docs] changing the way overloads are documented and presented Message-ID: <201704280935.10085.marc.mutz@kdab.com> Hi. TL;DR: I propose to document overloaded functions with a single comment block, containing multiple \fn's and a common documentation text, to be rendered as one documentation block preceded by a listing of all the \fn's, instead of as individual functions. Since I learned that a qdoc comment block can contain multiple \fn statements, I have tried to use it to document overloads with less duplication. E.g.: /*! \fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) const \fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs) const \fn bool QStringView::startsWith(QChar ch) const \fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const Returns \c true if this string-view starts with string-view \a str, Latin-1 string \a l1, or character \a ch, respectively; otherwise returns \c false. If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive; otherwise the search is case-insensitive. \sa endsWith(), qStartsWith() */ instead of /*! \fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) const Returns \c true if this string-view starts with string-view \a str; otherwise returns \c false. If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive; otherwise the search is case-insensitive. \sa endsWith(), qStartsWith() */ /*! \fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs) const Returns \c true if this string-view starts with Latin-1 string \a l1; otherwise returns \c false. If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive; otherwise the search is case-insensitive. \sa endsWith(), qStartsWith() */ /*! \fn bool QStringView::startsWith(QChar ch) const Returns \c true if this string-view starts with character \a ch; otherwise returns \c false. The search is case-sensitive. \sa endsWith(), qStartsWith() */ /*! \fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const Returns \c true if this string-view starts with character \a ch; otherwise returns \c false. If \a cs is Qt::CaseSensitive, the search is case-sensitive; otherwise the search is case-insensitive. \sa endsWith(), qStartsWith() */ And that's just startsWith(). QString::contains() current has 8, QString::arg() has 14, not counting the 8 additional multi-arg() overloads. Each of them contains mostly the same text. It's a long time since I had to consult QString documentation, but I guess for users, this is as hard to read as it is for us to write. Sure. cut-n-paste gives you fast initial results. But fear the day when you have to make a change to all of the contains() documentation blocks, and be it just for adding a missing hyphen. So, I hear you say, if qdoc already supports multiple \fn in one comment block, why don't you just use it. This is where http://bugreports.qt.io/browse/QTBUG-60420 comes in. Currently, any content in a multi-\fn block pertains to all functions designated by an included \fn, with no way to change. The initial example, e.g., copies the text, which is clearly written to refer to the overload set, not any particular funciton, verbatim for each of the four functions. As a consequence of this, it also throws warnings about invalid \a references. So, name the parameters the same in every overload... That works as long as all overloads were added in the same Qt release, because, as I said, all content, and thus \since, pertains to all \fn's. IOW: you cannot represent the fact that one overload was added in a later Qt version. What I would like to see is something more akin to the presentation in cppreference.com. Before you shout: no, I don't like the numbered listing of all overloads followed dumbly by a numbered listing of documentation for each overload. What I like is the numbered listing of the overloads, followed by free-form text, as in the initial example. It's up to the individual documentation writer and his reviewers to avoid falling into a cppreference.com-style of itemised text. I think that the initial example is an elegant way of how to document that particular set of overloads without having to refer to any of them in particular. I would like to see a multi-\fn comment block (and only those) transformed into a multi-function block in the documentation, too, first listing all the functions designated by the \fn's, with \since, \obsolete, ... attached to a function (like in cppreference.com, following the signature, in parentheses), not the whole block, followed by the free-form block. Naturally, there'd need to be a way to reference any particular overload. This could be done with a \label added to each function, or just a number: \1, \2, referring to their position in the listing of \fn's. This would probably shrink the length of the QString and QStringView page by more than half, and, if we would add \until into the mix, would allow to represent even complicated cases like QSharedPointer::create() very naturally: \fn QSharedPointer::create() \since 5.1 \until 5.7 \fn QSharedPointer::create(const Arg &arg) \since 5.4 \until 5.7 \fn QSharedPointer::create(Args &&...args) \since 5.4 Overload \3 requires C++11, which used to be optional. When Qt made support for C++11 a requirement in 5.7, overloads \1 and \2 were dropped, since \3 can represent them. Rendered as: 1. QSharedPointer QSharedPointer::create() [static] (since 5.1) (until 5.7) 2. QSharedPointer QSharedPointer::create(const Arg &arg) [static] (since 5.4) (until 5.7) 3. QSharedPointer QSharedPointer::create(const Arg &arg) [static] (since 5.4) Overload (3) requires ... What do you think? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From sean.harmer at kdab.com Fri Apr 28 10:07:46 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 28 Apr 2017 09:07:46 +0100 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: <201704280935.10085.marc.mutz@kdab.com> References: <201704280935.10085.marc.mutz@kdab.com> Message-ID: <4127448.hDaRlznfBZ@cartman> On Friday 28 April 2017 09:35:09 Marc Mutz wrote: > What do you think? I like the idea. +1 Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From Martin.Smith at qt.io Fri Apr 28 10:09:29 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 28 Apr 2017 08:09:29 +0000 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: <4127448.hDaRlznfBZ@cartman> References: <201704280935.10085.marc.mutz@kdab.com>, <4127448.hDaRlznfBZ@cartman> Message-ID: I haven't looked at all of it, but +1 on the general idea. martin ________________________________________ From: Development on behalf of Sean Harmer Sent: Friday, April 28, 2017 10:07:46 AM To: development at qt-project.org Subject: Re: [Development] [docs] changing the way overloads are documented and presented On Friday 28 April 2017 09:35:09 Marc Mutz wrote: > What do you think? I like the idea. +1 Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From samuel.gaist at edeltech.ch Fri Apr 28 11:24:42 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Fri, 28 Apr 2017 11:24:42 +0200 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: <201704280935.10085.marc.mutz@kdab.com> References: <201704280935.10085.marc.mutz@kdab.com> Message-ID: <4993F1F3-9546-4DCE-B754-F64CEF858D2A@edeltech.ch> > On 28 Apr 2017, at 09:35, Marc Mutz wrote: > > Hi. > > TL;DR: I propose to document overloaded functions with a single comment block, > containing multiple \fn's and a common documentation text, to be rendered as > one documentation block preceded by a listing of all the \fn's, instead of as > individual functions. > > Since I learned that a qdoc comment block can contain multiple \fn statements, > I have tried to use it to document overloads with less duplication. E.g.: > > /*! > \fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) const > \fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs) > const > \fn bool QStringView::startsWith(QChar ch) const > \fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const > > Returns \c true if this string-view starts with string-view \a str, > Latin-1 string \a l1, or character \a ch, respectively; > otherwise returns \c false. > > If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive; > otherwise the search is case-insensitive. > > \sa endsWith(), qStartsWith() > */ > > instead of > > /*! > \fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) const > > Returns \c true if this string-view starts with string-view \a str; > otherwise returns \c false. > > If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive; > otherwise the search is case-insensitive. > > \sa endsWith(), qStartsWith() > */ > > /*! > \fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs) > const > > Returns \c true if this string-view starts with Latin-1 string \a l1; > otherwise returns \c false. > > If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive; > otherwise the search is case-insensitive. > > \sa endsWith(), qStartsWith() > */ > > /*! > \fn bool QStringView::startsWith(QChar ch) const > > Returns \c true if this string-view starts with character \a ch; > otherwise returns \c false. > > The search is case-sensitive. > > \sa endsWith(), qStartsWith() > */ > > /*! > \fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const > > Returns \c true if this string-view starts with character \a ch; > otherwise returns \c false. > > If \a cs is Qt::CaseSensitive, the search is case-sensitive; > otherwise the search is case-insensitive. > > \sa endsWith(), qStartsWith() > */ > > And that's just startsWith(). QString::contains() current has 8, > QString::arg() has 14, not counting the 8 additional multi-arg() overloads. > > Each of them contains mostly the same text. It's a long time since I had to > consult QString documentation, but I guess for users, this is as hard to read > as it is for us to write. Sure. cut-n-paste gives you fast initial results. > But fear the day when you have to make a change to all of the contains() > documentation blocks, and be it just for adding a missing hyphen. > > So, I hear you say, if qdoc already supports multiple \fn in one comment > block, why don't you just use it. > > This is where http://bugreports.qt.io/browse/QTBUG-60420 comes in. > > Currently, any content in a multi-\fn block pertains to all functions > designated by an included \fn, with no way to change. The initial example, > e.g., copies the text, which is clearly written to refer to the overload set, > not any particular funciton, verbatim for each of the four functions. As a > consequence of this, it also throws warnings about invalid \a references. > > So, name the parameters the same in every overload... > > That works as long as all overloads were added in the same Qt release, > because, as I said, all content, and thus \since, pertains to all \fn's. IOW: > you cannot represent the fact that one overload was added in a later Qt > version. > > What I would like to see is something more akin to the presentation in > cppreference.com. Before you shout: no, I don't like the numbered listing of > all overloads followed dumbly by a numbered listing of documentation for each > overload. What I like is the numbered listing of the overloads, followed by > free-form text, as in the initial example. It's up to the individual > documentation writer and his reviewers to avoid falling into a > cppreference.com-style of itemised text. I think that the initial example is > an elegant way of how to document that particular set of overloads without > having to refer to any of them in particular. > > I would like to see a multi-\fn comment block (and only those) transformed > into a multi-function block in the documentation, too, first listing all the > functions designated by the \fn's, with \since, \obsolete, ... attached to a > function (like in cppreference.com, following the signature, in parentheses), > not the whole block, followed by the free-form block. > > Naturally, there'd need to be a way to reference any particular overload. This > could be done with a \label added to each function, or just a number: \1, \2, > referring to their position in the listing of \fn's. > > This would probably shrink the length of the QString and QStringView page by > more than half, and, if we would add \until into the mix, would allow to > represent even complicated cases like QSharedPointer::create() very naturally: > > > \fn QSharedPointer::create() > \since 5.1 > \until 5.7 > \fn QSharedPointer::create(const Arg &arg) > \since 5.4 > \until 5.7 > \fn QSharedPointer::create(Args &&...args) > \since 5.4 > > > > Overload \3 requires C++11, which used to be optional. When Qt made support > for C++11 a requirement in 5.7, overloads \1 and \2 were dropped, since \3 > can represent them. > > Rendered as: > > 1. QSharedPointer QSharedPointer::create() [static] (since 5.1) > (until 5.7) > 2. QSharedPointer QSharedPointer::create(const Arg &arg) [static] (since 5.4) > (until 5.7) > 3. QSharedPointer QSharedPointer::create(const Arg &arg) [static] (since 5.4) > > > > Overload (3) requires ... > > What do you think? > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, +1 I think it’s a pretty good idea. That will make the documentation more concise which isn’t a bad thing when looking for overloads. Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From rjvbertin at gmail.com Fri Apr 28 11:32:04 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 28 Apr 2017 11:32:04 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? Message-ID: <1691504.8p7tJBIcV1@bola> Hello, Together with the principal maintainer I am looking into issues in a style plugin related to its use of DBus (to be informed of desktop-wide changes): https://bugs.kde.org/show_bug.cgi?id=363753 The ticket above is about a reproducible issue in a custom cleanup handler that is designed to disconnect from the session DBus when the style plugin is unloaded. This mostly works fine but there are cases where a crash occurs inside QDBusConnection::sessionBus() (looks like accessing a deleted class instance). The documentation for that function does not mention anything about situations where the function is unsafe to be called. There is a second, underlying issue which is the reason why the cleanup handler was designed. Apparently it is possible for DBus signals to arrive *after* the style plugin was dlclose'd (unmapped?) without having first deleted all existing style instances (QCommonStyle subclass). It seems that the time slot in which this is possible ought to be very short, but if signals do come in the application jumps into "unmapped code" which evidently causes a crash. It is surprising that Qt unloads the style plugin without having first deleted the style instances, esp. when those instances are not created directly by user and there is not a single such instance (typically I see 5 - 7 instances being created). We're currently testing an approach in which the style plugin and style keep track of the number of instances created and delete all remaining copies before unloading the plugin (and in addition the DBus disconnect is also triggered through QCoreApplication::aboutToQuit). That seems excessive. At first glance one could consider this as 2 bugs in Qt; a missing verification in QDBusConnection::sessionBus() and allowing style plugins to be unloaded before all known style instances have been deleted. Before we file bug report(s) though I'd like to be certain these are not known issues, and that we're not doing something wrong in our code. Thanks, René From jani.heikkinen at qt.io Fri Apr 28 11:41:08 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 28 Apr 2017 09:41:08 +0000 Subject: [Development] Heads up - 5.9 string freeze In-Reply-To: References: Message-ID: Hi, As informed a week a go string freeze for Qt 5.9 is now in effect. So please, no changes to translatable strings from this point, unless approved by the documentation team. br, Jani ________________________________________ From: Jani Heikkinen Sent: Thursday, April 20, 2017 7:56 AM To: localization at qt-project.org Subject: Heads up - 5.9 soft string freeze Hi all, Qt 5.9 beta is out & work towards final release continues. One step on the way is String Freeze which should happen really soon to be able to minimize time needed between beta and RC. So let's start keeping the translatable strings as it is & fix remaining important issues. And let's have the official String Freeze 28th April 2017. Br, Jani Heikkinen Release Manager From oswald.buddenhagen at qt.io Fri Apr 28 13:39:09 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 28 Apr 2017 13:39:09 +0200 Subject: [Development] Heads up - 5.9 string freeze In-Reply-To: References: Message-ID: <20170428113909.GD2928@troll08> On Fri, Apr 28, 2017 at 09:41:08AM +0000, Jani Heikkinen wrote: > Hi, > > As informed a week a go string freeze for Qt 5.9 is now in effect. So please, no changes to translatable strings from this point, unless approved by the documentation team. > btw, the "unless approved by the documentation team" is to be understood as "the old text is so bad that we cannot possibly release it like that". that means that the docu team is supposed to act as an actual gatekeeper, not to rubber-stamp random gratuitous changes. > br, > Jani > ________________________________________ > From: Jani Heikkinen > Sent: Thursday, April 20, 2017 7:56 AM > To: localization at qt-project.org > Subject: Heads up - 5.9 soft string freeze > > Hi all, > > Qt 5.9 beta is out & work towards final release continues. One step on the way is String Freeze which should happen really soon to be able to minimize time needed between beta and RC. So let's start keeping the translatable strings as it is & fix remaining important issues. And let's have the official String Freeze 28th April 2017. > > Br, > Jani Heikkinen > Release Manager > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Fri Apr 28 14:20:38 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 28 Apr 2017 12:20:38 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io>, <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> Message-ID: >> Something like the following seems nice: >> Tier 1 - the most rigorously tested configurations, tested in CI >> Tier 2 - we actively try to make it work but it's a lower priority; >> will make and accept patches and provide support but isn't tested in >> CI >> Unsupported - we remove code that makes the functionality work; will >> refuse any related patches, commercial support refers queries to a >> separate (paid) business engagement Lars Knoll (28 April 2017 08:28): > I’m ok to describe things in tiers, as that’s what we have in > practice. We don’t test e.g. FreeBSD in CI, but we will accept patches > if something’s broken on that platform and someone cares enough to fix > it. Same would be true for 32bit iOS in 5.10 then. But the only thing > the Qt project will be able to give some guarantees for are the > configurations tested in CI. It remains that the distinction between "if you get it fixed, we'll take it in" and "we don't want our code complicated with fixes for that". We do need to make clear which platforms are in the former (Tier 2) state and which in the latter (Unsupported) - if only so that reviewers know to be consistent, Eddy. From thiago.macieira at intel.com Fri Apr 28 14:23:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 28 Apr 2017 09:23:23 -0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> Message-ID: <124475062.nFnjdNndlm@tjmaciei-mobl1> On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote: > Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get > pre-built binaries available before final release; let's see if we can > make it happen I remember a discussion about whether we needed MSVC 2017 binaries in the first place, since they're binary compatible with MSVC 2015 and we don't have "win32-msvc2015" anymore, which concluded we did. I don't remember the reason. Does anyone? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Apr 28 14:21:25 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 28 Apr 2017 09:21:25 -0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1691504.8p7tJBIcV1@bola> References: <1691504.8p7tJBIcV1@bola> Message-ID: <2761678.Yka5Oal6DZ@tjmaciei-mobl1> On Friday, 28 April 2017 06:32:04 -03 René J.V. Bertin wrote: > Together with the principal maintainer I am looking into issues in a style > plugin related to its use of DBus (to be informed of desktop-wide changes): > > https://bugs.kde.org/show_bug.cgi?id=363753 Before I read any of the rest: confirm that you've patched QtDBus with the patch "fix crashes at exit" 5.6: https://codereview.qt-project.org/157488 & https://codereview.qt-project.org/161056 5.8: https://codereview.qt-project.org/180231 & https://codereview.qt-project.org/180232 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Shawn.Rutledge at qt.io Fri Apr 28 14:27:48 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 28 Apr 2017 12:27:48 +0000 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1691504.8p7tJBIcV1@bola> References: <1691504.8p7tJBIcV1@bola> Message-ID: <6EBA4DDD-A367-486E-B07C-BE4065D6657C@qt.io> > On 28 Apr 2017, at 11:32, René J.V. Bertin wrote: > > Hello, > > Together with the principal maintainer I am looking into issues in a style plugin related to its use of DBus (to be informed of desktop-wide changes): > > https://bugs.kde.org/show_bug.cgi?id=363753 That says that this fixes it https://codereview.qt-project.org/#/c/161056/ and that in turn says that https://codereview.qt-project.org/#/c/180232/ is the equivalent for 5.8. So I suppose we’d better get it into 5.9 then, right? Writing a bug doesn’t hurt anything, and in fact will help to make the case that the patch is urgently required. But are you convinced that it’s the right fix? From b.terrier at gmail.com Fri Apr 28 14:51:58 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Fri, 28 Apr 2017 14:51:58 +0200 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <124475062.nFnjdNndlm@tjmaciei-mobl1> References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> <124475062.nFnjdNndlm@tjmaciei-mobl1> Message-ID: 2017-04-28 14:23 GMT+02:00 Thiago Macieira : > On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote: >> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get >> pre-built binaries available before final release; let's see if we can >> make it happen > > I remember a discussion about whether we needed MSVC 2017 binaries in the first > place, since they're binary compatible with MSVC 2015 and we don't have > "win32-msvc2015" anymore, which concluded we did. I don't remember the reason. > > Does anyone? I recall this (it's from you): > We can't drop it from the CI. I don't think we can drop it from the build > packages either, since usually you compile with the oldest you plan to use. So > if you're correct and VS2017 is binary-compatible, then we are already > providing the packages for VS2017. http://lists.qt-project.org/pipermail/development/2017-February/028768.html BR, Benjamin From andre at familiesomers.nl Fri Apr 28 15:19:14 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 28 Apr 2017 15:19:14 +0200 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: <201704280935.10085.marc.mutz@kdab.com> References: <201704280935.10085.marc.mutz@kdab.com> Message-ID: <6d160693-028f-8618-42c2-d5f2cc6cdc1b@familiesomers.nl> Op 28/04/2017 om 09:35 schreef Marc Mutz: > Hi. > > TL;DR: I propose to document overloaded functions with a single comment block, > containing multiple \fn's and a common documentation text, to be rendered as > one documentation block preceded by a listing of all the \fn's, instead of as > individual functions. > Generally, I like the idea. Thank you for that suggestion! It would really clean up the docs for some classes, and make it easier to find perhaps more suitable overloads for your case. Do you also propose to use it to group related functions instead of mere overloads, like again cppreference is doing for its standard algorithms (ie. find/find_if/find_if_not and any_of/all_of/none_of)? However, I am a bit worried about having a good way to describe the specifics of a specific overload or group thereof. Having that all in running text will lead to situations where such information is harder to find and takes more time to read through than it currently does. To go back to your QString::arg example, I do not want to have to do a text analysis of the docs belonging to 22 overloads to just get around how to use _one_ of these. Then again, many of the overloads are very similar. Perhaps we could have some form of grouping within such blocks (where groups of functions may be of size 1) to allow more specific docs for such groups with an easy link to them? Taking the QString::arg overloads, you'd probably get 2 or 3 groups: 1: the overloads taking a single value argument 1a: the overloads taking a numeric value argument 1b: the overloads taking a string or QChar 2: the overloads taking multiple QStrings You might get something like: \fngroup numeric Numeric single value overloads \fn QString::arg(qulonglong a, int fieldWidth = 0, int base = 10, QChar fillChar = QLatin1Char( ' ' )) const \fn QString::arg(long a, int fieldWidth = 0, int base = 10, QChar fillChar = QLatin1Char( ' ' )) const \fn QString::arg(int a, int fieldWidth = 0, int base = 10, QChar fillChar = QLatin1Char( ' ' )) const ... \fnendgroup \fngroup other Other single value overloads \fn QString::arg(const QString &a, int fieldWidth = 0, QChar fillChar = QLatin1Char( ' ' )) const \fn QString::arg(QChar a, int fieldWidth = 0, QChar fillChar = QLatin1Char( ' ' )) const \fnendgroup \fngroup multi Multi-value overloads \fn QString::arg(const QString &a1, const QString &a2) const \fn QString::arg(const QString &a1, const QString &a2, const QString &a3) const ... \endgroup Returns a copy of this string with the lowest numbered place marker replaced by string a, i.e., %1, %2, ..., %99. \groupdoc numeric fieldWidth specifies the minimum amount of space that a is padded to and filled with the character fillChar. A positive value produces right-aligned text; a negative value produces left-aligned text. (...) \endgroupdoc \groupdoc other .... \groupdoc other \groupdoc multi This is functionaly the same as str.arg(a1).arg(a2), except that the argument strings are replaced in one pass. This is faster, and it can make a difference if a1 contains e.g. %1: (...) \groupdoc multi Which, I image, would render as a list like Marc described, only grouped as indicated with the different groups directly linking to the right contents block. That contents block could then again indicate the name of the group and perhaps which overloads are part of that. André -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Fri Apr 28 15:48:35 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 28 Apr 2017 13:48:35 +0000 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: <6d160693-028f-8618-42c2-d5f2cc6cdc1b@familiesomers.nl> References: <201704280935.10085.marc.mutz@kdab.com>, <6d160693-028f-8618-42c2-d5f2cc6cdc1b@familiesomers.nl> Message-ID: >I am a bit worried about having a good way to describe the specifics of a >specific overload or group thereof. Remember you will still have the option of giving an overload its own qdoc comment instead of including it in the common \fn comment. martin ________________________________________ From: Development on behalf of André Somers Sent: Friday, April 28, 2017 3:19:14 PM To: development at qt-project.org Subject: Re: [Development] [docs] changing the way overloads are documented and presented Op 28/04/2017 om 09:35 schreef Marc Mutz: Hi. TL;DR: I propose to document overloaded functions with a single comment block, containing multiple \fn's and a common documentation text, to be rendered as one documentation block preceded by a listing of all the \fn's, instead of as individual functions. Generally, I like the idea. Thank you for that suggestion! It would really clean up the docs for some classes, and make it easier to find perhaps more suitable overloads for your case. Do you also propose to use it to group related functions instead of mere overloads, like again cppreference is doing for its standard algorithms (ie. find/find_if/find_if_not and any_of/all_of/none_of)? However, I am a bit worried about having a good way to describe the specifics of a specific overload or group thereof. Having that all in running text will lead to situations where such information is harder to find and takes more time to read through than it currently does. To go back to your QString::arg example, I do not want to have to do a text analysis of the docs belonging to 22 overloads to just get around how to use _one_ of these. Then again, many of the overloads are very similar. Perhaps we could have some form of grouping within such blocks (where groups of functions may be of size 1) to allow more specific docs for such groups with an easy link to them? Taking the QString::arg overloads, you'd probably get 2 or 3 groups: 1: the overloads taking a single value argument 1a: the overloads taking a numeric value argument 1b: the overloads taking a string or QChar 2: the overloads taking multiple QStrings You might get something like: \fngroup numeric Numeric single value overloads \fn QString::arg(qulonglong a, int fieldWidth = 0, int base = 10, QChar fillChar = QLatin1Char( ' ' )) const \fn QString::arg(long a, int fieldWidth = 0, int base = 10, QChar fillChar = QLatin1Char( ' ' )) const \fn QString::arg(int a, int fieldWidth = 0, int base = 10, QChar fillChar = QLatin1Char( ' ' )) const ... \fnendgroup \fngroup other Other single value overloads \fn QString::arg(const QString &a, int fieldWidth = 0, QChar fillChar = QLatin1Char( ' ' )) const \fn QString::arg(QChar a, int fieldWidth = 0, QChar fillChar = QLatin1Char( ' ' )) const \fnendgroup \fngroup multi Multi-value overloads \fn QString::arg(const QString &a1, const QString &a2) const \fn QString::arg(const QString &a1, const QString &a2, const QString &a3) const ... \endgroup Returns a copy of this string with the lowest numbered place marker replaced by string a, i.e., %1, %2, ..., %99. \groupdoc numeric fieldWidth specifies the minimum amount of space that a is padded to and filled with the character fillChar. A positive value produces right-aligned text; a negative value produces left-aligned text. (...) \endgroupdoc \groupdoc other .... \groupdoc other \groupdoc multi This is functionaly the same as str.arg(a1).arg(a2), except that the argument strings are replaced in one pass. This is faster, and it can make a difference if a1 contains e.g. %1: (...) \groupdoc multi Which, I image, would render as a list like Marc described, only grouped as indicated with the different groups directly linking to the right contents block. That contents block could then again indicate the name of the group and perhaps which overloads are part of that. André From rjvbertin at gmail.com Fri Apr 28 15:59:26 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 28 Apr 2017 15:59:26 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <6EBA4DDD-A367-486E-B07C-BE4065D6657C@qt.io> References: <1691504.8p7tJBIcV1@bola> <6EBA4DDD-A367-486E-B07C-BE4065D6657C@qt.io> Message-ID: <4993623.sxi4UcBqgt@bola> On Friday April 28 2017 12:27:48 Shawn Rutledge wrote: >That says that this fixes it https://codereview.qt-project.org/#/c/161056/ and that in turn says that https://codereview.qt-project.org/#/c/180232/ is the equivalent for 5.8. So I suppose we’d better get it into 5.9 then, right? Dang, that happens with huge and long-lived tickets like this: I forgot about that patch. That may explain too why I'm not seeing the crash myself... >Writing a bug doesn’t hurt anything, and in fact will help to make the case that the patch is urgently required. > >But are you convinced that it’s the right fix? Convinced it's THE right and ONLY fix, no, I don't have enough experience in this context to be that affirmative. I am pretty convinced though that it'd be a very good idea to add protections that make it safe to use QtDBus during global destruction after "QtDBus has already destroyed its internals". That's all the more important if you cannot easily test whether global destruction is going on. Will that also protect against incoming DBus signals? I guess not because the very fact those are apparently handled suggests that QtDBus is still up and running. But note that I haven't seen a representative backtrace of that kind of event yet. I'll try to find some time to write a proper report this weekend then. It might also help provide a(nother) test-case to trigger DBus-related crashes. One that needs KF5 applications, but QtCurve itself can be built without KF5 dependencies and should be just as vulnerable. On a related note: does QCoreApplication::startingUp() provide a proper starting-up equivalent for QCoreApplication::aboutToQuit ("QCoreApplication::readyToRoll", signal or method)? If multiple style instances are being created outside of our control we could at least try not to do DBus connections from the instances that aren't going to be used... R. From edward.welbourne at qt.io Fri Apr 28 16:05:41 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 28 Apr 2017 14:05:41 +0000 Subject: [Development] Introductions? In-Reply-To: References: , Message-ID: On 25 April 2017 at 10:09 I wrote (inter alia): > [...] the same is relevant for any approver or maintainer: perhaps we > should tweak our process for introducing candidates for those stations > within the community; ask that each introduce self in the course of it > - possibly *after* we've made our decision, so we won't be prejudiced > by their weird hobbies. ISTR Lars, when proposing me, just linked to > my review history in gerrit; that probably should suffice for the > decision on whether to accept a candidate - but it might be worth, > once the decision is made, as a matter of course, having the new > approver or maintainer introduce self, or link to web pages that do > so. Just to clarify, as one off-list discussion raised concerns about pressuring folk to share more than might feel comfortable: I do, of course, intend no more than that we invite the newly-chosen to say as much about themselves as they feel comfortable saying. If they wish to keep their public exposure to what's visible already on gerrit, they are of course free to do so. [...] > What do folk think ? We've heard one +1 and no other public response. Any other opinions ? Eddy. From christian.kandeler at qt.io Fri Apr 28 16:19:22 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 28 Apr 2017 16:19:22 +0200 Subject: [Development] Introductions? In-Reply-To: References: Message-ID: On 04/28/2017 04:05 PM, Edward Welbourne wrote: > On 25 April 2017 at 10:09 I wrote (inter alia): >> [...] the same is relevant for any approver or maintainer: perhaps we >> should tweak our process for introducing candidates for those stations >> within the community; ask that each introduce self in the course of it >> - possibly *after* we've made our decision, so we won't be prejudiced >> by their weird hobbies. ISTR Lars, when proposing me, just linked to >> my review history in gerrit; that probably should suffice for the >> decision on whether to accept a candidate - but it might be worth, >> once the decision is made, as a matter of course, having the new >> approver or maintainer introduce self, or link to web pages that do >> so. > > Just to clarify, as one off-list discussion raised concerns about > pressuring folk to share more than might feel comfortable: I do, of > course, intend no more than that we invite the newly-chosen to say as > much about themselves as they feel comfortable saying. If they wish to > keep their public exposure to what's visible already on gerrit, they are > of course free to do so. > > [...] >> What do folk think ? > > We've heard one +1 and no other public response. I see one +1 and one -2. Christian From annulen at yandex.ru Fri Apr 28 16:54:53 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 28 Apr 2017 17:54:53 +0300 Subject: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake Message-ID: <4249651493391293@web36j.yandex.ru> Hello, There is a strange situation involving official Qt SDK (>=5.8.0) binaries for Linux, ICU, cmake, and WebKit project files, I'm not sure which side really needs to be fixed. (Qt)WebKit uses custom module to find ICU, you can see its code at [1]. Module uses quite popular practise of invoking pkg-config first, and then performing search of libs and headers by passing them as HINTS to find_path() and find_library(). Doing so allows to have a meaningful fallback if pkg-config is missing, misconfigured, or e.g. returns host libs when cross-compilation is needed. Before Qt 5.8.0, Qt SDK didn't include unversioned symlinks for ICU libraries, e.g. 5.7 had only libicuuc.so.56 and libicuuc.so.56.1, but not libicuuc.so. Starting from 5.8.0, unversioned symlinks are also provided. Now, if someone sets CMAKE_PREFIX_PATH to the Qt root in SDK, cmake starts to find ICU libraries in SDK, because priority logic of find_library makes CMAKE_PREFIX_PATH preferred to the HINTS provided by pkg-config. At the same time, there are no ICU headers in Qt SDK, so include paths are taken from pkg-config, that detects system-wide installation of ICU. Note that ICU uses versioned suffixes in symbol names, so different versions are binary incompatible, resulting in the broken build when headers don't match libraries. There are a few possible solutions: * Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU libraries, required for QtCore, can be reused in other projects that use Qt and ICU, e.g. for building of experimental QtWebKit versions against binary SDK. * Remove unversioned symlinks like libicuuc.so from SDK, so that they are not found by FindICU.cmake, and also by linker if it's given -licuuc * Avoid using CMAKE_PREFIX_PATH with Qt SDK, using Qt5_DIR and similar variables instead * Change FindICU to ignore libraries Qt-related paths - ugly hack, also FindICU.cmake is technically 3rd party code for QtWebKit * Change priorities in CMake's find_library - probably off-topic for this list, and may be impossible because of backward compatibility reasons. Thoughts? [1] https://github.com/annulen/webkit/blob/qtwebkit-stable/Source/cmake/FindICU.cmake -- Regards, Konstantin From andre at familiesomers.nl Fri Apr 28 17:01:21 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 28 Apr 2017 17:01:21 +0200 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: References: <201704280935.10085.marc.mutz@kdab.com> <6d160693-028f-8618-42c2-d5f2cc6cdc1b@familiesomers.nl> Message-ID: <21992042-9f51-4ceb-f4fa-49dddb073448@familiesomers.nl> Op 28/04/2017 om 15:48 schreef Martin Smith: >> I am a bit worried about having a good way to describe the specifics of a >specific overload or group thereof. > Remember you will still have the option of giving an overload its own qdoc comment instead of including it in the common \fn comment. True, but that would negate some of the benefits: having a good overview of the different overloads all together as well as sharing the common documentation between the overloads. André From edward.welbourne at qt.io Fri Apr 28 17:46:33 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 28 Apr 2017 15:46:33 +0000 Subject: [Development] Introductions? In-Reply-To: References: , Message-ID: Christian Kandeler (28 April 2017 16:19) > I see one +1 and one -2. ah - sorry - I though that one was off-list. Andre: do you feel your concern is addressed by my clarified proposal ? Eddy. From oktal3700 at gmail.com Fri Apr 28 17:50:41 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Fri, 28 Apr 2017 16:50:41 +0100 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> <124475062.nFnjdNndlm@tjmaciei-mobl1> Message-ID: On 28 April 2017 at 13:51, Benjamin TERRIER wrote: > 2017-04-28 14:23 GMT+02:00 Thiago Macieira : > > On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote: > >> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get > >> pre-built binaries available before final release; let's see if we can > >> make it happen > > > > I remember a discussion about whether we needed MSVC 2017 binaries in > the first > > place, since they're binary compatible with MSVC 2015 and we don't have > > "win32-msvc2015" anymore, which concluded we did. I don't remember the > reason. > > > > Does anyone? > > I recall this Also these: http://lists.qt-project.org/pipermail/development/2017-March/029200.html [Marc] http://lists.qt-project.org/pipermail/development/2017-March/029202.html [Thiago] tldr: MSVC expects to see linker symbols for inline member functions of exported classes. When such a function is defined within #ifdef Q_COMPILER_foo (being a macro that is defined for 2017 but not 2015) this could mean linker errors. Unknown if this effect has actually been observed or is merely theoretical. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Apr 28 17:54:24 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 28 Apr 2017 12:54:24 -0300 Subject: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake In-Reply-To: <4249651493391293@web36j.yandex.ru> References: <4249651493391293@web36j.yandex.ru> Message-ID: <7276035.Nv0fPNS4pE@tjmaciei-mobl1> On Friday, 28 April 2017 11:54:53 -03 Konstantin Tokarev wrote: > Hello, > > There is a strange situation involving official Qt SDK (>=5.8.0) binaries > for Linux, ICU, cmake, and WebKit project files, I'm not sure which side > really needs to be fixed. > > (Qt)WebKit uses custom module to find ICU, you can see its code at [1]. > Module uses quite popular practise of invoking pkg-config first, and then > performing search of libs and headers by passing them as HINTS to > find_path() and find_library(). Doing so allows to have a meaningful > fallback if pkg-config is missing, misconfigured, or e.g. returns host libs > when cross-compilation is needed. qtwebkit is built using qmake, so any CMake modules are irrelevant at this point. CMake is only used for building user applications. > There are a few possible solutions: > > * Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU > libraries, required for QtCore, can be reused in other projects that use Qt > and ICU, e.g. for building of experimental QtWebKit versions against binary > SDK. Out of scope and you should be using qmake. > * Remove unversioned symlinks like libicuuc.so from SDK, so that they > are not found by FindICU.cmake, and also by linker if it's given -licuuc That seems like the right solution for me. If we're not supplying the headers (and it's not our business to), then we shouldn't supply the *.so symlinks either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Apr 28 17:48:29 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 28 Apr 2017 12:48:29 -0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> <124475062.nFnjdNndlm@tjmaciei-mobl1> Message-ID: <2415977.MZ87aLhLMG@tjmaciei-mobl1> On Friday, 28 April 2017 09:51:58 -03 Benjamin TERRIER wrote: > 2017-04-28 14:23 GMT+02:00 Thiago Macieira : > > On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote: > >> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get > >> pre-built binaries available before final release; let's see if we can > >> make it happen > > > > I remember a discussion about whether we needed MSVC 2017 binaries in the > > first place, since they're binary compatible with MSVC 2015 and we don't > > have "win32-msvc2015" anymore, which concluded we did. I don't remember > > the reason. > > > > Does anyone? > > I recall this (it's from you): > > We can't drop it from the CI. I don't think we can drop it from the build > > packages either, since usually you compile with the oldest you plan to > > use. So if you're correct and VS2017 is binary-compatible, then we are > > already providing the packages for VS2017. > > http://lists.qt-project.org/pipermail/development/2017-February/028768.html That's the opposite: that's the argument of why we should not need a VS2017 binary. I'm asking if anyone remembers the argument why we should. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Fri Apr 28 18:48:47 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 28 Apr 2017 16:48:47 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <88DDBF45-4CB8-4596-BB3E-79C7F95C88D3@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> <88DDBF45-4CB8-4596-BB3E-79C7F95C88D3@qt.io> Message-ID: <8BE2F646-BC90-4B94-B57F-66723B95CA30@qt.io> > On Apr 27, 2017, at 11:54 PM, Shawn Rutledge wrote: > > >> On 27 Apr 2017, at 16:59, Jake Petroules wrote: >> >> Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). > > Well, the latest iOS versions don’t run on devices of a certain age (and in other cases, you can upgrade but you’d better not, because you’ll regret it) - that’s their way of shaking you down. But as long as developers can keep enabling continued use of those devices somehow rather than sending them promptly to the shredder as soon as Apple wants you to, I think we should support them in their efforts, or at least not interfere. Removing 32-bit support from our packages only drops the iPhone 5 from support by Qt. The 5s and above are all 64-bit so this has been a long time coming. I'm all for dropping 32-bit "support" (from the CI). If people REALLY need 32-bit, they can go compile it themselves. > >> On 27 Apr 2017, at 17:00, Jake Petroules wrote: >> >>> On Apr 27, 2017, at 7:40 AM, BogDan Vatra wrote: >>> >>> For Android I'd like to support 64 bit platforms (arm and x86) >> >> They are already supported. Feel free to compile Qt with the appropriate -arch options. Do you mean you want them in CI and want us to start shipping binaries for android amd64 and arm64? >> >> I'm not sure there's enough 64-bit devices out there to justify it yet. Android moves very slow... > > Lollipop came out in 2014. And there were 64-bit devices available by then. So I suspect the majority of new devices are 64-bit by now. > > If _users_ are slow to upgrade their devices, that’s really good on them, not going along with the planned obsolescence nonsense which is purely harmful: to your wallet, to the environment, to the sense of guilt that you feel when you do the wrong thing, and increasing inequality in the economy. Apple gets a black mark in my book for trying so hard to remove that choice. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From aclaure at gmail.com Fri Apr 28 18:49:16 2017 From: aclaure at gmail.com (Adalid Claure) Date: Fri, 28 Apr 2017 12:49:16 -0400 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed Message-ID: I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI. When the app starts I see the following errors in Console: kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit My build process is pretty straight forward: 1. Run macdeployqt on the app, using the -appstore-compliant. 2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file. 3. Sign QtWebEngineProcess.app with the following entitlements file: com.apple.security.app-sandbox com.apple.security.inherit 4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2. I have tried numerous things all in combination with one another, including: a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes. html#mac-app-store-compatibility) b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. d. tried linking with Qt 5.7 e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because: ------------------------------- Your app uses or references the following non-public API(s): framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit' : NSAccessibilityUnregisterUniqueIdForUIElement : _NSAppendToKillRing : _NSDrawCarbonThemeBezel : _NSDrawCarbonThemeListBox : _NSInitializeKillRing : _NSNewKillRingSequence : _NSPrependToKillRing : _NSSetKillRingToYankedState : _NSYankFromKillRing framework: '/System/Library/Frameworks/ApplicationServices.framework/ Versions/A/ApplicationServices' : CGSSetDenyWindowServerConnections : CGSShutdownServerConnections : CTFontCopyDefaultCascadeList The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. ------------------------------- I have chronicled a lot of this in this thread here ( https://forum.qt.io/topic/78518/sandbox-app-for-the-mac- app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Fri Apr 28 18:58:32 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 28 Apr 2017 16:58:32 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> Message-ID: > On Apr 27, 2017, at 11:28 PM, Lars Knoll wrote: > > >> On 27 Apr 2017, at 16:59, Jake Petroules wrote: >> >>> >>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen wrote: >>> >>> >>> Hi, >>> >>> Related to the Apple platforms, could we consider the following for Qt 5.10: >>> - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) >>> - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support >> >> I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional. > > Agree, there is a difference between the two. > > What I think we should however do for 5.10 is remove 32bit support for iOS from CI and our binary packages. And that means that things will be untested on 32bit iOS, and thus is likely to break at some point. I think 32-bit support on iOS is kind of unlikely to break accidentally, but I agree we should remove it from our binary packages. The iPhone 5 is dead. >> >> As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing… > > For the commercial version, it’s to a large extent up to TQtC to define the support offering. The open source project anyway does not offer any official support for the Qt versions released. All you can do is ask on the mailing lists or file a bug report and hope for the best. Or of course sit down, fix it yourself and submit a patch :) My point was that if a commercial customer goes to support with a bug in a 32-bit build of Qt for iOS, support won't say "we do not support that, go away". They will fix the problem, regardless of the fact that it isn't part of a reference configuration. If a customer sets the minimum deployment target of Qt for iOS to 5.0 and then goes to support saying Qt doesn't work, support WILL tell them "we do not support that (because we deliberately broke it), we can't help you and you'll have to talk to Services and pay money if you want it working that badly". That's the real-world outcome, which is why I don't like using the term "supported" as a synonym for "is a reference configuration in CI". A reference configuration in CI always constitutes something that is supported. However, something that's supported is not necessarily a reference configuration in CI. We should make this clear to our users by not using the term "supported" in a misleading way. > >> >> Something like the following seems nice: >> Tier 1 - the most rigorously tested configurations, tested in CI >> Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI >> Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement > > I’m ok to describe things in tiers, as that’s what we have in practice. We don’t test e.g. FreeBSD in CI, but we will accept patches if something’s broken on that platform and someone cares enough to fix it. Same would be true for 32bit iOS in 5.10 then. But the only thing the Qt project will be able to give some guarantees for are the configurations tested in CI. >> >> Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). > > Dropping it has other benefits. Currently iOS is on the critical path in the CI system for qt5.git integrations and thus package creation. Dropping 32bit support going to significantly cut down on iOS compile times, and should thus lead to faster turn around times for package creation. > > Lars > >> >>> - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) >> >> Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :) >> >> Current list is: >> - Qt 5.6 - supports macOS 10.7 and up >> - Qt 5.7 - supports macOS 10.8 and up >> - Qt 5.8 - supports macOS 10.9 and up >> - Qt 5.9 - supports macOS 10.10 and up >> >> Planned: >> - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10 >> - Qt 5.11 - supports macOS 10.11 and up >> >> By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported". >> >> If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright. >> >> But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10) >> >>> >>> Yours, >>> >>> Tuukka >>> >>> On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" wrote: >>> >>> >>>> On Apr 27, 2017, at 2:29 AM, Heikki Halmet wrote: >>>> >>>> Hi, >>>> >>>> Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. >>>> Please comment if the proposal is insufficient or the changes are unacceptable somehow. >>>> >>>> Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html >>>> >>>> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: >>>> RHEL 7.2 -> RHEL 7.3 (Any benefits?) >>>> OpenSUSE 42.1 -> OpenSUSE 42.2 >>>> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) >>>> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) >>> >>> Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. >>> >>>> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) >>> >>> 8.3.2, please. >>> >>>> Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 >>>> Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 >>>> INTEGRITY GHS 2016.5.4 -> 2017.1.x >>>> Support for Android 8 (if available on time) >>>> iOS 11 support (if available on time. Current rumors -> september) >>>> >>>> MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. >>>> This means that we can only use Preview release of 10.13 for testing before final official release is out. >>>> That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. >>> >>> How do you know it won't be called macOS 11? ;) >>> >>> The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. >>> >>> Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. >>> >>>> >>>> NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. >>>> With all others we'll do the best we can but we can't commit that those will be supported in 5.10. >>>> >>>> >>>> >>>> Best regards >>>> Heikki Halmet >>>> >>>> The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland >>>> Email: heikki.halmet at qt.io >>>> Phone: +358408672112 >>>> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petroules at qt.io >>> The Qt Company - Silicon Valley >>> Qbs build tool evangelist - qbs.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> >> -- >> Jake Petroules - jake.petroules at qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From annulen at yandex.ru Sat Apr 29 11:22:20 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 29 Apr 2017 12:22:20 +0300 Subject: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake In-Reply-To: <7276035.Nv0fPNS4pE@tjmaciei-mobl1> References: <4249651493391293@web36j.yandex.ru> <7276035.Nv0fPNS4pE@tjmaciei-mobl1> Message-ID: <5127991493457740@web8j.yandex.ru> 28.04.2017, 18:58, "Thiago Macieira" : > On Friday, 28 April 2017 11:54:53 -03 Konstantin Tokarev wrote: >>  Hello, >> >>  There is a strange situation involving official Qt SDK (>=5.8.0) binaries >>  for Linux, ICU, cmake, and WebKit project files, I'm not sure which side >>  really needs to be fixed. >> >>  (Qt)WebKit uses custom module to find ICU, you can see its code at [1]. >>  Module uses quite popular practise of invoking pkg-config first, and then >>  performing search of libs and headers by passing them as HINTS to >>  find_path() and find_library(). Doing so allows to have a meaningful >>  fallback if pkg-config is missing, misconfigured, or e.g. returns host libs >>  when cross-compilation is needed. > > qtwebkit is built using qmake, so any CMake modules are irrelevant at this > point. CMake is only used for building user applications. > >>  There are a few possible solutions: >> >>  * Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU >>  libraries, required for QtCore, can be reused in other projects that use Qt >>  and ICU, e.g. for building of experimental QtWebKit versions against binary >>  SDK. > > Out of scope and you should be using qmake. I understand your point, but it seems impractical to provide wrapper qmake project as an interface for packagers. They know know how to deal with qmake or cmake packages, but dealing with cmake wrapped with qmake is a totally different business, and can easily double amount of issues to solve, especially when cross-compiling. That said, it works fine in Coin. Maintaining old qmake-based build was not considered because I don't have resources to maintain a build system that duplicate's one maintained by upstream. If there are volunteers to do that I can reconsider, but note that you will have to deal with lots of custom code generators, that are changed over time, and it would be much harder to backport upsream patches (that already include necessary cmake changes) As a side effect, having cmake build that is usable as a public build interface helps with IDE integration, e.g. I'm using existing cmake support in Qt Creator for development. > >>  * Remove unversioned symlinks like libicuuc.so from SDK, so that they >>  are not found by FindICU.cmake, and also by linker if it's given -licuuc > > That seems like the right solution for me. If we're not supplying the headers > (and it's not our business to), then we shouldn't supply the *.so symlinks > either. Fine with me. Looks like the problem is that archive [1] contains only necessary files, but [2] contains all ICU libraries + unversioned links. Archive [2] is unpacked into SDK image since 5.8.0. [1] http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel6.6-x64.7z Files: Extracting libicudata.so.56 Extracting libicui18n.so.56 Extracting libicuuc.so.56 Extracting libicudata.so.56.1 Extracting libicui18n.so.56.1 Extracting libicuuc.so.56.1 [2] http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel7.2-x64.7z Files: Extracting libicudata.so Extracting libicui18n.so Extracting libicuio.so Extracting libicule.so Extracting libiculx.so Extracting libicutest.so Extracting libicutu.so Extracting libicuuc.so Extracting libicudata.so.56 Extracting libicui18n.so.56 Extracting libicuio.so.56 Extracting libicule.so.56 Extracting libiculx.so.56 Extracting libicutest.so.56 Extracting libicutu.so.56 Extracting libicuuc.so.56 Extracting libicudata.so.56.1 Extracting libicui18n.so.56.1 Extracting libicuio.so.56.1 Extracting libicule.so.56.1 Extracting libiculx.so.56.1 Extracting libicutest.so.56.1 Extracting libicutu.so.56.1 Extracting libicuuc.so.56.1 > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Simon.Hausmann at qt.io Sat Apr 29 13:38:10 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sat, 29 Apr 2017 11:38:10 +0000 Subject: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake In-Reply-To: <5127991493457740@web8j.yandex.ru> References: <4249651493391293@web36j.yandex.ru> <7276035.Nv0fPNS4pE@tjmaciei-mobl1>, <5127991493457740@web8j.yandex.ru> Message-ID: <29B43443-F555-4055-BB8D-ED5694B417CA@qt.io> Hi, Yeah, the rhel 7.2 icu packages on download.qt.io should not contain the .so symlinks. Iikka, is this something you could help us with? Simon > On 29. Apr 2017, at 11:22, Konstantin Tokarev wrote: > > > > 28.04.2017, 18:58, "Thiago Macieira" : >>> On Friday, 28 April 2017 11:54:53 -03 Konstantin Tokarev wrote: >>> Hello, >>> >>> There is a strange situation involving official Qt SDK (>=5.8.0) binaries >>> for Linux, ICU, cmake, and WebKit project files, I'm not sure which side >>> really needs to be fixed. >>> >>> (Qt)WebKit uses custom module to find ICU, you can see its code at [1]. >>> Module uses quite popular practise of invoking pkg-config first, and then >>> performing search of libs and headers by passing them as HINTS to >>> find_path() and find_library(). Doing so allows to have a meaningful >>> fallback if pkg-config is missing, misconfigured, or e.g. returns host libs >>> when cross-compilation is needed. >> >> qtwebkit is built using qmake, so any CMake modules are irrelevant at this >> point. CMake is only used for building user applications. >> >>> There are a few possible solutions: >>> >>> * Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU >>> libraries, required for QtCore, can be reused in other projects that use Qt >>> and ICU, e.g. for building of experimental QtWebKit versions against binary >>> SDK. >> >> Out of scope and you should be using qmake. > > I understand your point, but it seems impractical to provide wrapper qmake project > as an interface for packagers. They know know how to deal with qmake or cmake > packages, but dealing with cmake wrapped with qmake is a totally different business, > and can easily double amount of issues to solve, especially when cross-compiling. > That said, it works fine in Coin. > > Maintaining old qmake-based build was not considered because I don't have > resources to maintain a build system that duplicate's one maintained by upstream. > If there are volunteers to do that I can reconsider, but note that you will have to deal > with lots of custom code generators, that are changed over time, and it would be > much harder to backport upsream patches (that already include necessary cmake > changes) > > As a side effect, having cmake build that is usable as a public build interface helps > with IDE integration, e.g. I'm using existing cmake support in Qt Creator for development. > >> >>> * Remove unversioned symlinks like libicuuc.so from SDK, so that they >>> are not found by FindICU.cmake, and also by linker if it's given -licuuc >> >> That seems like the right solution for me. If we're not supplying the headers >> (and it's not our business to), then we shouldn't supply the *.so symlinks >> either. > > Fine with me. Looks like the problem is that archive [1] contains only necessary files, > but [2] contains all ICU libraries + unversioned links. Archive [2] is unpacked into > SDK image since 5.8.0. > > [1] http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel6.6-x64.7z > > Files: > > Extracting libicudata.so.56 > Extracting libicui18n.so.56 > Extracting libicuuc.so.56 > Extracting libicudata.so.56.1 > Extracting libicui18n.so.56.1 > Extracting libicuuc.so.56.1 > > [2] http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel7.2-x64.7z > > Files: > > Extracting libicudata.so > Extracting libicui18n.so > Extracting libicuio.so > Extracting libicule.so > Extracting libiculx.so > Extracting libicutest.so > Extracting libicutu.so > Extracting libicuuc.so > Extracting libicudata.so.56 > Extracting libicui18n.so.56 > Extracting libicuio.so.56 > Extracting libicule.so.56 > Extracting libiculx.so.56 > Extracting libicutest.so.56 > Extracting libicutu.so.56 > Extracting libicuuc.so.56 > Extracting libicudata.so.56.1 > Extracting libicui18n.so.56.1 > Extracting libicuio.so.56.1 > Extracting libicule.so.56.1 > Extracting libiculx.so.56.1 > Extracting libicutest.so.56.1 > Extracting libicutu.so.56.1 > Extracting libicuuc.so.56.1 > >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Sat Apr 29 21:46:16 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 29 Apr 2017 21:46:16 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <2761678.Yka5Oal6DZ@tjmaciei-mobl1> Message-ID: <1838622.cEx5RcgSvt@patux.local> Thiago Macieira wrote: > 5.6: https://codereview.qt-project.org/157488 & > https://codereview.qt-project.org/161056 > > 5.8: https://codereview.qt-project.org/180231 & > https://codereview.qt-project.org/180232 I have, and that's the reason I cannot easily attempt to produce backtraces myself Are those patches in any way a possible fix for DBus signals being delivered to slots in libraries that have already been dlclose'd? The fact this can happen suggests QtDbus is still very much up and running, no? I don't think the other author (Yichao) runs a patched Qt version and I'm pretty sure that the various users reporting crashes don't either. It could help if you would confirm that until those patches can go in the "official" workaround to avoid crashing is a) don't do QtDBus cleanup (disconnects) and/or b) do that in reaction to QCoreApplication::aboutToQuit(). R From thiago.macieira at intel.com Sat Apr 29 22:06:29 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 29 Apr 2017 17:06:29 -0300 Subject: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake In-Reply-To: <5127991493457740@web8j.yandex.ru> References: <4249651493391293@web36j.yandex.ru> <7276035.Nv0fPNS4pE@tjmaciei-mobl1> <5127991493457740@web8j.yandex.ru> Message-ID: <5477262.h95Sq2iNnq@tjmaciei-mobl1> On Saturday, 29 April 2017 06:22:20 -03 Konstantin Tokarev wrote: > > Out of scope and you should be using qmake. > > I understand your point, but it seems impractical to provide wrapper qmake > project as an interface for packagers. They know know how to deal with > qmake or cmake packages, but dealing with cmake wrapped with qmake is a > totally different business, and can easily double amount of issues to > solve, especially when cross-compiling. That said, it works fine in Coin. My point is that there should be no cmake involved at all. The qtwebkit build has worked with qmake for 10 years, why should it stop now? > Maintaining old qmake-based build was not considered because I don't have > resources to maintain a build system that duplicate's one maintained by > upstream. If there are volunteers to do that I can reconsider, but note > that you will have to deal with lots of custom code generators, that are > changed over time, and it would be much harder to backport upsream patches > (that already include necessary cmake changes) Was the one that used to exist removed? > As a side effect, having cmake build that is usable as a public build > interface helps with IDE integration, e.g. I'm using existing cmake support > in Qt Creator for development. And the existing qmake support in Qt Creator did not work? > >> * Remove unversioned symlinks like libicuuc.so from SDK, so that they > >> are not found by FindICU.cmake, and also by linker if it's given -licuuc > > > > That seems like the right solution for me. If we're not supplying the > > headers (and it's not our business to), then we shouldn't supply the *.so > > symlinks either. > > Fine with me. Looks like the problem is that archive [1] contains only > necessary files, but [2] contains all ICU libraries + unversioned links. > Archive [2] is unpacked into SDK image since 5.8.0. Then let's do it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Apr 29 22:31:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 29 Apr 2017 17:31:23 -0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> Message-ID: <5497234.Nm7GsXRHTr@tjmaciei-mobl1> On Friday, 28 April 2017 12:50:41 -03 Mat Sutcliffe wrote: > tldr: MSVC expects to see linker symbols for inline member functions of > exported classes. When such a function is defined within #ifdef > Q_COMPILER_foo (being a macro that is defined for 2017 but not 2015) this > could mean linker errors. Unknown if this effect has actually been observed > or is merely theoretical. Thanks Mat. If this is the only issue, then it's only a potential issue that will not affect us. There's exactly one Q_COMPILER_foo macro that is in 2017 that isn't in 2015: Q_COMPILER_CONSTEXPR And the totality of its use in public headers, aside from the definition in qcompilerdetection.h, is: - qtbase/src/corelib/thread/qbasicatomic.h #elif defined(Q_COMPILER_ATOMICS) && (defined(Q_COMPILER_CONSTEXPR) || defined(Q_OS_QNX)) # include // We only support one fallback: MSVC, because even on version 2015, it lacks full constexpr support #elif defined(Q_CC_MSVC) # include [...] #if defined(Q_COMPILER_CONSTEXPR) && defined(Q_COMPILER_DEFAULT_MEMBERS) && defined(Q_COMPILER_DELETE_MEMBERS) # define QT_BASIC_ATOMIC_HAS_CONSTRUCTORS #endif - qtbase/src/corelib/arch/qatomic_cxx11.h #if defined(Q_COMPILER_CONSTEXPR) && defined(Q_COMPILER_DEFAULT_MEMBERS) && defined(Q_COMPILER_DELETE_MEMBERS) # define Q_BASIC_ATOMIC_INITIALIZER(a) { a } #else # define Q_BASIC_ATOMIC_INITIALIZER(a) { ATOMIC_VAR_INIT(a) } #endif - qtbase/src/corelib/global/qnamespace.h #if defined(Q_COMPILER_CLASS_ENUM) && defined(Q_COMPILER_CONSTEXPR) enum class Initialization { Uninitialized }; static constexpr Q_DECL_UNUSED Initialization Uninitialized = Initialization::Uninitialized; #else enum Initialization { Uninitialized }; #endif None of those affect an exported class. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sat Apr 29 23:29:03 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 30 Apr 2017 00:29:03 +0300 Subject: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake In-Reply-To: <5477262.h95Sq2iNnq@tjmaciei-mobl1> References: <4249651493391293@web36j.yandex.ru> <7276035.Nv0fPNS4pE@tjmaciei-mobl1> <5127991493457740@web8j.yandex.ru> <5477262.h95Sq2iNnq@tjmaciei-mobl1> Message-ID: <5793911493501343@web33j.yandex.ru> 29.04.2017, 23:18, "Thiago Macieira" : > On Saturday, 29 April 2017 06:22:20 -03 Konstantin Tokarev wrote: >>  > Out of scope and you should be using qmake. >> >>  I understand your point, but it seems impractical to provide wrapper qmake >>  project as an interface for packagers. They know know how to deal with >>  qmake or cmake packages, but dealing with cmake wrapped with qmake is a >>  totally different business, and can easily double amount of issues to >>  solve, especially when cross-compiling. That said, it works fine in Coin. > > My point is that there should be no cmake involved at all. The qtwebkit build > has worked with qmake for 10 years, why should it stop now? It's getting to the side way from the original topic, but let me tell you the story of WebKit build systems. When Apple opened WebKit source, initially it had only build system based on Xcode projects. Of course it didn't work for others, and every WebKit port started to maintain own build system. Qt port, of course, used qmake. GTK port initially used qmake as well to avoid duplicating work, but later switched to autotools. Windows ports (AppleWin and WinCairo) used VS project files. wxWidgets port used waf. Google used gyp for Chromium and makefiles for Android (that was a separate port that time). EFL port used CMake, but later other ports, namely Blackberry and WinCE, also used its build system. Shared build system that could work for different WebKit ports was born. Time passed, several ports ceased their existence. In 2013 GTK port decided to switch from autotools to this shared CMake build system. AppleWin and WinCairo also switched. Apple maintains CMake build for Mac port as well, AFAIK it is not used for production builds but provides faster build times, so they are evaluating if they can do full switch in the future. So, current state of WebKit build systems is: * All active ports except iOS have cmake as the only build option, or at least as one of the options (Mac) * CMake is likely the only build system that could be accepted in case Qt port would ever return to trunk, or any other new port * Port-independent improvements to CMake build that benefit Qt port are accepted (and reviewed) by upstream. > >>  Maintaining old qmake-based build was not considered because I don't have >>  resources to maintain a build system that duplicate's one maintained by >>  upstream. If there are volunteers to do that I can reconsider, but note >>  that you will have to deal with lots of custom code generators, that are >>  changed over time, and it would be much harder to backport upsream patches >>  (that already include necessary cmake changes) > > Was the one that used to exist removed? Yes. After 3 years of being not updated, it would require a ton of changes and debugging to work with new WebKit. Changed file lists (that are always in flux) is only part of the probem. Other part is figuring out how code generation is done, that would require analysis of cmake code and reimplementing it with qmake. WebKit has lots of different code generators with lots of peculiarities, that resulted in very arcane qmake code in the past. And my name is not Ossi, I'm just a mere mortal with very limited magic abilities :) Switching to CMake from the start allowed me to get things building very fast, without even knowing all gory details. I would estimate net result of build system switch for now as neutral, because a lot of work was required to make it working in Coin and to restore installation layouts provided by qmake for free. However, I expect next updates of WebKit engine mostly flawless on build system side, as Qt-specific parts won't need huge modifications anymore, and port-independent changes will come from upstream directly. Bonus: in case of weird build issues like [1] I can now just backport necessary cmake incantation instead of figuring everything myself. [1] https://bugs.webkit.org/show_bug.cgi?id=161697 > >>  As a side effect, having cmake build that is usable as a public build >>  interface helps with IDE integration, e.g. I'm using existing cmake support >>  in Qt Creator for development. > > And the existing qmake support in Qt Creator did not work? It would work, if there was something to work with. > >>  >> * Remove unversioned symlinks like libicuuc.so from SDK, so that they >>  >> are not found by FindICU.cmake, and also by linker if it's given -licuuc >>  > >>  > That seems like the right solution for me. If we're not supplying the >>  > headers (and it's not our business to), then we shouldn't supply the *.so >>  > symlinks either. >> >>  Fine with me. Looks like the problem is that archive [1] contains only >>  necessary files, but [2] contains all ICU libraries + unversioned links. >>  Archive [2] is unpacked into SDK image since 5.8.0. > > Then let's do it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oktal3700 at gmail.com Sun Apr 30 00:14:54 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Sat, 29 Apr 2017 23:14:54 +0100 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: <5497234.Nm7GsXRHTr@tjmaciei-mobl1> References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> <5497234.Nm7GsXRHTr@tjmaciei-mobl1> Message-ID: On 29 April 2017 at 21:31, Thiago Macieira wrote: > On Friday, 28 April 2017 12:50:41 -03 Mat Sutcliffe wrote: > > tldr: MSVC expects to see linker symbols for inline member functions of > > exported classes. When such a function is defined within #ifdef > > Q_COMPILER_foo (being a macro that is defined for 2017 but not 2015) this > > could mean linker errors. Unknown if this effect has actually been > observed > > or is merely theoretical. > > Thanks Mat. > > If this is the only issue, then it's only a potential issue that will not > affect us. There's exactly one Q_COMPILER_foo macro that is in 2017 that > isn't > in 2015: > Q_COMPILER_CONSTEXPR > > And the totality of its use in public headers, aside from the definition in > qcompilerdetection.h, is... It also controls whether Q_DECL_CONSTEXPR expands to constexpr or nothing. But I don't think that should alter whether or not a function is inline, because functions declared with Q_DECL_CONSTEXPR should already be inline anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Apr 30 00:51:22 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 29 Apr 2017 19:51:22 -0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1838622.cEx5RcgSvt@patux.local> References: <1691504.8p7tJBIcV1@bola> <2761678.Yka5Oal6DZ@tjmaciei-mobl1> <1838622.cEx5RcgSvt@patux.local> Message-ID: <13013557.Mnue7YQq09@tjmaciei-mobl1> On Saturday, 29 April 2017 16:46:16 -03 René J. V. Bertin wrote: > Are those patches in any way a possible fix for DBus signals being delivered > to slots in libraries that have already been dlclose'd? The fact this can > happen suggests QtDbus is still very much up and running, no? They may be related, especially if the delivery happens at shutdown time. Since those patches affect the unloading and shutting down process, they could affect. If the issue happens during normal execution, then it's a coincidence. > I don't think the other author (Yichao) runs a patched Qt version and I'm > pretty sure that the various users reporting crashes don't either. > > It could help if you would confirm that until those patches can go in the > "official" workaround to avoid crashing is a) don't do QtDBus cleanup > (disconnects) and/or b) do that in reaction to > QCoreApplication::aboutToQuit(). Every Linux distribution should apply the patch. No one should use QtDBus without them. I will not support any use or investigate any crash report of a build that doesn't have them applied. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Apr 30 01:20:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 29 Apr 2017 20:20:06 -0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <9e345858-63bb-bb61-e778-13b1e48b4ed6@gmx.net> <5497234.Nm7GsXRHTr@tjmaciei-mobl1> Message-ID: <2078067.j67qYnsQoT@tjmaciei-mobl1> On Saturday, 29 April 2017 19:14:54 -03 Mat Sutcliffe wrote: > It also controls whether Q_DECL_CONSTEXPR expands to constexpr or nothing. > But I don't think that should alter whether or not a function is inline, > because functions declared with Q_DECL_CONSTEXPR should already be inline > anyway. All constexpr functions are by definition inline. The question is whether MSVC 2017 mangles them especially because of that fact. With the simple attached testcase, I compiled with MSVC 2017. The resulting symbols were: ?normal_inline at Foo@@QEAAHXZ ; Foo::normal_inline ?constexpr_inline at Foo@@QEAAHXZ ; Foo::constexpr_inline The mangling QEAAHXZ expands to: Q public E __far64 / __ptr64 A no cv-qualification A __cdecl H return type: int X parameter list: void Z throw list: ... [unused, all functions end in Z] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: test.cpp Type: text/x-c++src Size: 143 bytes Desc: not available URL: From rjvbertin at gmail.com Sun Apr 30 15:46:04 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 30 Apr 2017 15:46:04 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <2761678.Yka5Oal6DZ@tjmaciei-mobl1> <1838622.cEx5RcgSvt@patux.local> <13013557.Mnue7YQq09@tjmaciei-mobl1> Message-ID: <3769950.cUxRZ2AYE2@patux.local> Thiago Macieira wrote: > Every Linux distribution should apply the patch. No one should use QtDBus > without them. I will not support any use or investigate any crash report of a > build that doesn't have them applied. If you're so certain of the patches why haven't they still been incorporated?! Seems there's an internal act that has to be gotten together! From thiago.macieira at intel.com Sun Apr 30 15:55:31 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 30 Apr 2017 10:55:31 -0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <3769950.cUxRZ2AYE2@patux.local> References: <1691504.8p7tJBIcV1@bola> <13013557.Mnue7YQq09@tjmaciei-mobl1> <3769950.cUxRZ2AYE2@patux.local> Message-ID: <12577474.OERONMxfOn@tjmaciei-mobl1> On Sunday, 30 April 2017 10:46:04 -03 René J. V. Bertin wrote: > Thiago Macieira wrote: > > Every Linux distribution should apply the patch. No one should use QtDBus > > without them. I will not support any use or investigate any crash report > > of a build that doesn't have them applied. > > If you're so certain of the patches why haven't they still been > incorporated?! Seems there's an internal act that has to be gotten > together! Because they fail in the CI. There's a regression. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center