Re: [Development] Qt 5.5.0 header diff
On 11/06/15 12:29, Knoll Lars lars.kn...@theqtcompany.com wrote: qtwebengine A src/webenginewidgets/api/qwebenginedownloaditem.h A src/webenginewidgets/api/qwebengineprofile.h A src/webenginewidgets/api/qwebenginescript.h A src/webenginewidgets/api/qwebenginescriptcollection.h Some smaller issues here, talked to Pierre and he’ll submit a patch today. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 11/06/15 14:28, Marc Mutz marc.m...@kdab.com wrote: On Thursday 11 June 2015 12:29:06 Knoll Lars wrote: A src/network/ssl/qsslellipticcurve.h A src/network/ssl/qsslpresharedkeyauthenticator.h Fine imho (but I was partially involved in their upbringing, so another set of eyes wouldn't hurt). Well, QSslEllipticCurve is problematic IMO. The class only contains one int and accesses it inline. Since we might have other backends than openssl implementing this in the future, I’d like have this non inline and a qint64 as data type (so we could replace it with a d pointer later on if required). The presharedkey authenticator is missing a copy constructor taking a rvalue ref, but that’s minor and can be fixed BC in 5.6 as well. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Thursday 11 June 2015 12:29:06 Knoll Lars wrote: A src/multimedia/camera/qcameraviewfindersettings.h Aprt from the changes already uploaded to Gerrit, I would suggest to use the new QCamera::FrameRateRange class instead of separate minimumFrameRate/maximumFrameRate properties. That *may* indicate that FrameRateRange shouldn't be a nested class within QCamera, I don't know QtMM enough. A src/multimedia/video/qabstractvideofilter.h Apart from the change already uploaded to Gerrit: - QVideoFilterRunnable::RunFlag needs a 0x0 value. - Runnable is a bad name, since it doesn't inherit QRunnable. - QAbstractVideoFilter should re-use QObject::d_ptr instead of adding its own (though its unclear why it's inheriting QObject in the first place). - QAbstractVideoFilter::createFilterRunnable() should probably be const A src/qtmultimediaquicktools/qsgvideonode_yuv.h Private header (not exported, inline virtuals, no override keyword...). Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 11/06/15 11:38, Marc Mutz marc.m...@kdab.com wrote: On Tuesday 09 June 2015 13:35:14 Oswald Buddenhagen wrote: On Tue, Jun 09, 2015 at 10:59:32AM +, Heikkinen Jani wrote: Hi, I tried to create error reports about the findings to be able to follow-up the progress. Please create new one if something is missing. the point was about the entirely new headers that were not in the diffs, i.e., entirely new apis. it's a quite different (and much bigger) task than ensuring compatibility with existing api revisions. i can create a task, but it's not up to me to actually schedule it. lars (or multiple other maintainers) need to make that call. Any news on this? Will we set aside time to look at the new API in more depth before publishing or will we rush out 5.5 with known and unknown API issues? (yes, this question is meant to be suggestive :) Well, afaik the new APIs have been reviewed, but maybe not as widely as we should have. But so far, I haven’t seen bigger issues apart from the one in Qt Network. We’ll have to weight things against each other. Looking at that, I don’t believe delaying 5.5 is a good option as we’re getting extremely close to the summer break. I don’t think releasing in August is a better idea. So I propose we’ll sit down here in the office today and tomorrow with a few people and go through the new APIs to be certain we didn’t miss any big issues. That’s the fastest way to get some certainty without too large risks to delay our release. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 11/06/15 14:19, Marc Mutz marc.m...@kdab.com wrote: On Thursday 11 June 2015 12:29:06 Knoll Lars wrote: A src/multimedia/camera/qcameraviewfindersettings.h Aprt from the changes already uploaded to Gerrit, I would suggest to use the new QCamera::FrameRateRange class instead of separate minimumFrameRate/maximumFrameRate properties. That would be nice. That *may* indicate that FrameRateRange shouldn't be a nested class within QCamera, I don't know QtMM enough. The viewfinder class is closely bound to the camera. It sounds correct to have the framerate in the camera class. A src/multimedia/video/qabstractvideofilter.h Apart from the change already uploaded to Gerrit: - QVideoFilterRunnable::RunFlag needs a 0x0 value. Agree, but not a showstopper for 5.5.0 - Runnable is a bad name, since it doesn't inherit QRunnable. QVideoFilterEngine? But I don’t think it’s too much of a problem as it’s a very specialized class. - QAbstractVideoFilter should re-use QObject::d_ptr instead of adding its own (though its unclear why it's inheriting QObject in the first place). It could, since the module depends on private apis in Qt Core anyway. Still, no show stopper for me. And it’s a QObject, because it gets exposed to QML. - QAbstractVideoFilter::createFilterRunnable() should probably be const I tend to agree, but it’s also a minor issue. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 11/06/15 10:55, Knoll Lars lars.kn...@theqtcompany.com wrote:
On 11/06/15 11:38, Marc Mutz marc.m...@kdab.com wrote:
On Tuesday 09 June 2015 13:35:14 Oswald Buddenhagen wrote:
On Tue, Jun 09, 2015 at 10:59:32AM +, Heikkinen Jani wrote:
Hi,
I tried to create error reports about the findings to be able to
follow-up the progress. Please create new one if something is
missing.
the point was about the entirely new headers that were not in the
diffs,
i.e., entirely new apis. it's a quite different (and much bigger) task
than ensuring compatibility with existing api revisions.
i can create a task, but it's not up to me to actually schedule it.
lars
(or multiple other maintainers) need to make that call.
Any news on this? Will we set aside time to look at the new API in more
depth
before publishing or will we rush out 5.5 with known and unknown API
issues?
(yes, this question is meant to be suggestive :)
Well, afaik the new APIs have been reviewed, but maybe not as widely as we
should have. But so far, I haven’t seen bigger issues apart from the one
in Qt Network.
We’ll have to weight things against each other. Looking at that, I don’t
believe delaying 5.5 is a good option as we’re getting extremely close to
the summer break. I don’t think releasing in August is a better idea.
So I propose we’ll sit down here in the office today and tomorrow with a
few people and go through the new APIs to be certain we didn’t miss any
big issues. That’s the fastest way to get some certainty without too large
risks to delay our release.
Ok, here’s the list of public headers that got added between 5.4 and 5.5.
I used the command below
git diff --name-status origin/5.4..origin/5.5 src | grep '^A' | grep \.h
| grep -v _p.h | grep -v 3rdparty | grep -v plugins
The list of headers that we need to go through is then:
On 11/06/15 10:55, Knoll Lars lars.kn...@theqtcompany.com wrote:
On 11/06/15 11:38, Marc Mutz marc.m...@kdab.com wrote:
On Tuesday 09 June 2015 13:35:14 Oswald Buddenhagen wrote:
On Tue, Jun 09, 2015 at 10:59:32AM +, Heikkinen Jani wrote:
Hi,
I tried to create error reports about the findings to be able to
follow-up the progress. Please create new one if something is missing.
the point was about the entirely new headers that were not in the diffs,
i.e., entirely new apis. it's a quite different (and much bigger) task
than ensuring compatibility with existing api revisions.
i can create a task, but it's not up to me to actually schedule it. lars
(or multiple other maintainers) need to make that call.
Any news on this? Will we set aside time to look at the new API in more
depth
before publishing or will we rush out 5.5 with known and unknown API
issues?
(yes, this question is meant to be suggestive :)
Well, afaik the new APIs have been reviewed, but maybe not as widely as we
should have. But so far, I haven’t seen bigger issues apart from the one
in Qt Network.
We’ll have to weight things against each other. Looking at that, I don’t
believe delaying 5.5 is a good option as we’re getting extremely close to
the summer break. I don’t think releasing in August is a better idea.
So I propose we’ll sit down here in the office today and tomorrow with a
few people and go through the new APIs to be certain we didn’t miss any
big issues. That’s the fastest way to get some certainty without too large
risks to delay our release.
Ok, here’s the list of public headers that got added between 5.4 and 5.5.
(generated using
git diff --name-status origin/5.4..origin/5.5 src | grep '^A' | grep \.h
| grep -v _p.h | grep -v 3rdparty | grep -v plugins)
The list of headers that we need to go through is then:
qtbase
A src/network/ssl/qsslellipticcurve.h
A src/network/ssl/qsslpresharedkeyauthenticator.h
qtmultimedia
A src/multimedia/camera/qcameraviewfindersettings.h
A src/multimedia/video/qabstractvideofilter.h
A src/qtmultimediaquicktools/qsgvideonode_yuv.h
qtwebengine
A src/webenginewidgets/api/qwebenginedownloaditem.h
A src/webenginewidgets/api/qwebengineprofile.h
A src/webenginewidgets/api/qwebenginescript.h
A src/webenginewidgets/api/qwebenginescriptcollection.h
For reference the full set of output of the script is attached, but most
of the files are not relevant to review for different reasons.
There are a couple of new modules as well:
Qt Canvas3D: Basically just a QML import exposing WebGL to QML.
Implemented a w3c/khronos standard, so not much to review here.
Qt 3D: In technology preview, API not yet frozen
Qt Location: The APIs underwent some changes from the 4.8 mobility API,
but the module got a good review during Nokia times.
I’ll get to reviewing the added files now, but others feel free to have a
look as well.
Cheers,
Lars
{\rtf1\ansi\ansicpg1252\cocoartf1344\cocoasubrtf720
{\fonttbl\f0\fnil\fcharset0 Consolas;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
\deftab720
\pard\pardeftab720
Re: [Development] Qt 5.5.0 header diff
On Thursday 11 June 2015 12:29:06 Knoll Lars wrote: Qt Location: The APIs underwent some changes from the 4.8 mobility API, but the module got a good review during Nokia times. The QtMultimedia changes I uploaded and described in my previous mail show what - IMHO - needs to be done to each of the QtLocation classes. I won't have time to look at QtLocation myself, but the changes are fairly trivial. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Thu, Jun 11, 2015 at 08:55:24AM +, Knoll Lars wrote: On Tuesday 09 June 2015 13:35:14 Oswald Buddenhagen wrote: On Tue, Jun 09, 2015 at 10:59:32AM +, Heikkinen Jani wrote: Hi, I tried to create error reports about the findings to be able to follow-up the progress. Please create new one if something is missing. the point was about the entirely new headers that were not in the diffs, i.e., entirely new apis. it's a quite different (and much bigger) task than ensuring compatibility with existing api revisions. i can create a task, but it's not up to me to actually schedule it. lars (or multiple other maintainers) need to make that call. Any news on this? Will we set aside time to look at the new API in more depth before publishing or will we rush out 5.5 with known and unknown API issues? (yes, this question is meant to be suggestive :) Well, afaik the new APIs have been reviewed, but maybe not as widely as we should have. But so far, I haven’t seen bigger issues apart from the one in Qt Network. We’ll have to weight things against each other. Looking at that, I don’t believe delaying 5.5 is a good option as we’re getting extremely close to the summer break. I don’t think releasing in August is a better idea. So I propose we’ll sit down here in the office today and tomorrow with a few people and go through the new APIs to be certain we didn’t miss any big issues. That’s the fastest way to get some certainty without too large risks to delay our release. I'd guess that's pretty much the best solution for now. Looking a bit further: (More or less) consistent API used to be one of the core values of Qt. Right now introducing new API in a consistent way seems to work mostly by inertia - *if* it works. I also doubt it will work that way for eternity, as accidents (and worse, intentional deviations from established patterns and conventions by some approvers) accumulate. To be blunt: Even though some of the existing patterns and conventions *are* unfashionable in 2015, consistency is a value by itself. Any *partial* modernization of the API destroys that consistency, and therefore value. So even if use pattern B instead of A is uncontroversial when considered isolated, it's not a given that using B instead of A in new Qt API is a win. And that ignores the fact that there's rarely an situaion of a B being *uniformly* better than an A. Sitting down with a few people *is* a way to fix things up last minute, but I'd feel more comfortable if something to the same effect was formal part of the process. I am not sure about the concrete abilities of gerrit infrastructure, but having a bot adding a specific user (or two, or three) to any change introducing new API does not seem completely impossible. Regarding the specific user(s): Less is more. Looking back, the time it worked best for me was when it was clear who the single person to ask about names and conventions was. Yes, that's a bottleneck for the process, but getting uniformity by simulated annealing is extremely unlikely if the initial solution is immutable. Such as our API after the first release. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
Marc Mutz schreef op 11-6-2015 om 16:33: BTW: Can someone send a summary of Qt 5.6 vs. C++11 to the ML, for those that couldn't attend? I made notes. Available from here: https://wiki.qt.io/QtCS2015_ModernCpp André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 11/06/15 16:26, Marc Mutz marc.m...@kdab.com wrote: On Thursday 11 June 2015 13:56:12 Knoll Lars wrote: - QAbstractVideoFilter should re-use QObject::d_ptr instead of adding its own (though its unclear why it's inheriting QObject in the first place). It could, since the module depends on private apis in Qt Core anyway. Still, no show stopper for me. Can't be changed later, as it would be BiC. And since it only adds a bool, having its own d_ptr is kinda _really_, _really_ overkill. And it’s a QObject, because it gets exposed to QML. That's not a reason, is it? There's other ways (Q_GADGET?) to get stuff into QML without carrying the baggage of a QObject around, aren't there? The semantics for gadgets and objects in QML are different. The QObject makes sense here. I don’t see a big problem, as you’ll never instantiate thousands of these objects anyway. Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 11/06/15 16:33, Marc Mutz marc.m...@kdab.com wrote: On Thursday 11 June 2015 13:43:15 Knoll Lars wrote: Well, QSslEllipticCurve is problematic IMO. The class only contains one int and accesses it inline. Since we might have other backends than openssl implementing this in the future, I’d like have this non inline and a qint64 as data type (so we could replace it with a d pointer later on if required). Please read the discussion on https://codereview.qt-project.org/94022 TL;DR: There will never be more than a few dozen elliptic curves. They will never be mutable. So their state can be kept in a read-only location with the int indexing into it. The urge to hide everything behind a d-pointer is strong in Qt, but here, it makes no sense. Ok for me. Just wanted to make sure we’re all fine with this. The presharedkey authenticator is missing a copy constructor taking a rvalue ref, but that’s minor and can be fixed BC in 5.6 as well. Can't have an inline move ctor, as it's using QSharedDataPointer. Can't have an out-of-line move ctor, since that's currently forbidden. Maybe in 5.6, if we require rvalue refs. BTW: Can someone send a summary of Qt 5.6 vs. C++11 to the ML, for those that couldn't attend? The short summary (full one will hopefully still come from whoever took notes): Compiler wise we’ll have VS2012 and gcc 4.7 as a baseline. It’s ok to use the C++11 language features supported by these compilers unconditionally in Qt (both in headers and implementations). This also means we can remove some ifdefs for rvalue refs, Q_DECL_OVERRIDE etc. Some care is still required when using STL features that might cause BC issues for us. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Thursday 11 June 2015 13:56:12 Knoll Lars wrote: - QAbstractVideoFilter should re-use QObject::d_ptr instead of adding its own (though its unclear why it's inheriting QObject in the first place). It could, since the module depends on private apis in Qt Core anyway. Still, no show stopper for me. Can't be changed later, as it would be BiC. And since it only adds a bool, having its own d_ptr is kinda _really_, _really_ overkill. And it’s a QObject, because it gets exposed to QML. That's not a reason, is it? There's other ways (Q_GADGET?) to get stuff into QML without carrying the baggage of a QObject around, aren't there? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Thursday 11 June 2015 13:43:15 Knoll Lars wrote: Well, QSslEllipticCurve is problematic IMO. The class only contains one int and accesses it inline. Since we might have other backends than openssl implementing this in the future, I’d like have this non inline and a qint64 as data type (so we could replace it with a d pointer later on if required). Please read the discussion on https://codereview.qt-project.org/94022 TL;DR: There will never be more than a few dozen elliptic curves. They will never be mutable. So their state can be kept in a read-only location with the int indexing into it. The urge to hide everything behind a d-pointer is strong in Qt, but here, it makes no sense. The presharedkey authenticator is missing a copy constructor taking a rvalue ref, but that’s minor and can be fixed BC in 5.6 as well. Can't have an inline move ctor, as it's using QSharedDataPointer. Can't have an out-of-line move ctor, since that's currently forbidden. Maybe in 5.6, if we require rvalue refs. BTW: Can someone send a summary of Qt 5.6 vs. C++11 to the ML, for those that couldn't attend? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Thursday 11 June 2015 22:07:00 André Pönitz wrote: To be blunt: Even though some of the existing patterns and conventions are unfashionable in 2015, consistency is a value by itself. Any partial modernization of the API destroys that consistency, and therefore value. So even if use pattern B instead of A is uncontroversial when considered isolated, it's not a given that using B instead of A in new Qt API is a win. And that ignores the fact that there's rarely an situaion of a B being uniformly better than an A. Would you mind being more specific about what Pattern A and Pattern B you have in mind? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Friday 12 June 2015 00:28:05 Marc Mutz wrote: On Thursday 11 June 2015 22:07:00 André Pönitz wrote: To be blunt: Even though some of the existing patterns and conventions are unfashionable in 2015, consistency is a value by itself. Any partial modernization of the API destroys that consistency, and therefore value. So even if use pattern B instead of A is uncontroversial when considered isolated, it's not a given that using B instead of A in new Qt API is a win. And that ignores the fact that there's rarely an situaion of a B being uniformly better than an A. Would you mind being more specific about what Pattern A and Pattern B you have in mind? Nevermind, just saw your other mail... -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Tuesday 09 June 2015 13:35:14 Oswald Buddenhagen wrote: On Tue, Jun 09, 2015 at 10:59:32AM +, Heikkinen Jani wrote: Hi, I tried to create error reports about the findings to be able to follow-up the progress. Please create new one if something is missing. the point was about the entirely new headers that were not in the diffs, i.e., entirely new apis. it's a quite different (and much bigger) task than ensuring compatibility with existing api revisions. i can create a task, but it's not up to me to actually schedule it. lars (or multiple other maintainers) need to make that call. Any news on this? Will we set aside time to look at the new API in more depth before publishing or will we rush out 5.5 with known and unknown API issues? (yes, this question is meant to be suggestive :) Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Tue, Jun 09, 2015 at 07:35:45AM +, Knoll Lars wrote: On 08/06/15 23:58, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Monday 08 June 2015 22:31:15 Marc Mutz wrote: It would probably be a good idea to do an additional header diff (incl. new headers) on the ML after the alpha. I don't follow the development of modules other than QtBase closely, nor do I want to, and apparently I'm too strict a reviewer to be regularly invited on new API Agree. Let's put this into our planning for 5.6. One header diff/review at the time we branch 5.6, and a final one to cross-check before the RC. Well, that's exactly the kind of people we want reviewing our APIs... Thiago's right. If there's one place we want to be very strict it's on our APIs. Everything else we can still fix later on, but APIs are out there and will stick for a long time, so we better get them right. wouldn't that mean pulling the emergency brake on 5.5 and allowing a further ~two week slip in the schedule to actually fix the problem now that we are aware of it? i think we already have enough experience with how well next time works in practice ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtCore.diff
On Monday 8. June 2015 17:57:23 Thiago Macieira wrote:
On Monday 08 June 2015 15:58:23 Olivier Goffart wrote:
There is no reason to stop improving qmetatype.
The qFatal was there for a good reason.
It was there for a good reason for the existing flags.
But for new flags of course it does not make sens.
It did make sense: the idea was that registering new flags would cause the
very incompatibility we're seeing here. I'm not entirely convinced that we
discussed all scenarios at QtCS, so I'm still skeptical about allowing the
IsGadget flag. I insist that we \omitvalue for now, until we understand the
consequences better.
No, the qFatal is there because a change in the other flags like the
MovableType is binary incompatible.
A change in the IsGadget flag is fine.
Old code did not need this flag. And code that relies on it requires anyway
that the code that register the types register the isGadget flag.
Even if one could build a complicated use case that breaks, it would be very
unlikely to happen.
And any change is dangerous. When we fix any small bug, there can always be
applications that breaks because it was relying on the bug for something.
Anyway, let us summarize the problem in that case.
In Qt = 5.4, QtLocation was using QML Private API to basically creates
QObject wrapper around QGeoCoordinate so it can be exposed in QML. But in Qt
5.5, one does not need private API, everybody can expose value types to QML
just by adding Q_GADGET to it and registering Q_PROPERTY or Q_INVOKABLE.
So QGeoCoordinate became a Q_GADGET. But for QML to be able to take advantage
of it, the type needs to be registered with the QMetaType::IsGadget flag. This
is automatic. But if the metatype is registered by code compiled with Qt 5.4
or before, the IsGadget flag is not present.
This is what is happening in a application that was compiled against Qt 5.4,
QGeoCoordinate was used in signal and slot and registered as a metatype by the
application. QMetaType will detect the difference in the flags on the second
registration and do a qFatal.
The solution is obviously not to do a qFatal, but take the new flags in
addition. And then everything works as expected.
Now the problem is: could there be code that relies in IsGadget that is run
and that the type is only registered by old code but not by new code. i.e:
could loading an old plugin compiled with an old code suddenly break a new
application using these new feature.
In theory this is possible, but in practice I don't think this will ever
happen.
Let's suppose an application called App 1.0 which has this code:
mystruct.h:
struct MyStruct {
int myValue;
};
Q_DECLARE_METATYPE(MyStruct);
myitem_p.h
class MyItem : public QObject {
Q_OBJECT
Q_INVOKABLE extractValue(const QVariant v) {
return qvariant_castMyStruct(v).myValue;
}
};
foo.qml:
MyItem {
function foobar(someObject) {
return extractValue(someObject.myStructProperty);
}
}
someObject is an object coming from a plugin which has a property
myStructProperty of type MyStruct.
Now, App 1.1 gets released and they simplify the code:
mystruct.h:
struct MyStruct {
Q_GADGET;
Q_PROPERTY(int myValue MEMBER myValue)
public:
int myValue;
};
foo.qml:
MyItem {
function foobar(someObject) {
// now that myStruct is a Q_GADGET i don't need the helper
return someObject.myStructProperty.myValue;
}
}
Then yes, if the MyStruct was only registered by the plugin we get a binary
compatibility problem in the application. But this is a problem for the
application, not Qt. And the solution is to make sure that MyStruct is
registered by manually registering it using qRegisterMetaType
And it's not just the flag. I'm not convinced about the template detection
either. You had to apply two late fixes to the detection so that we wouldn't
break source compatibility or create unnecessary warnings.
Yes, I had to apply fixes after the beta was released and it got tested in the
wild. But is that not what beta releases are for?
The freeze stays: no new flags in QMetaType until Qt 6, no more messing
with the template black magic.
You can't mandate that.
Yes, I can. As the maintainer, I have the authority and mandate to oversee
the changes to the module I maintain and that includes blocking changes I
am unsatisfied with.
A mailing list consensus can overrule me, as can the Chief Maintainer.
We stay frozen until further notice. If you have new flags you want to
propose, you can do it, but we'll need a mailing list discussion before the
change is allowed.
Well, then it will be reviewed as usual.
There are few improvements that can be done to QMetaType that we were
discussing at the summit, like the ability to modify list types (append and
such) or including some of the C++11 features. I bet one can simplify
qmetatype.h when we require C++11's decltype and proper SFINAE rules
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Tuesday 09 June 2015 00:27:40 Thiago Macieira wrote: But Qt API that doesn't explicitly need an array for the data should continue to use QList. I disagree insofar as it concerns new types. Either a new type put into a QList is optimally efficient (sizeof == sizeof void* and at least Q_MOVABLE_TYPE), or the new type is not put into QList. For existing types, I think we agree to keep them, unless a change is relatively painless (like the FormatRange in QTextEngine/QTextLayout) or the problem is relatively painful (also FormatRange) or other parts of Qt already keep the type in QVector (again, FormatRange). -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
Hi, I tried to create error reports about the findings to be able to follow-up the progress. Please create new one if something is missing. I have also linked all to the Qt5.5.0-RC blocker list so please try to close all as soon as possible. I'll ask LEs from responsible persons today to be able to estimate RC schedule Here is the errors I created: QTBUG-46555 not Qt-like API in QtGUI QTBUG-46556 Retroactive deprecations are not allowed. QTBUG-46557 QtTest.diff : API isn't finished QTBUG-46558 Some methods in wrong class QTBUG-46559 Q_DECL_OVERRIDEs missing from QtQuickWidgets API QTBUG-46560 QtQML: Rename qqmfile.h into qqmlfile_p.h. QTBUG-46561 Header Diff related issues in QtCore QTBUG-46562 Header diff issues in QtLocation QTBUG-46563 Header diff issues in QtMultimedia QTBUG-46564 Header diff issues in QtBluetooth br, Jani -Original Message- From: development-bounces+jani.heikkinen=theqtcompany.com@qt- project.org [mailto:development- bounces+jani.heikkinen=theqtcompany@qt-project.org] On Behalf Of Oswald Buddenhagen Sent: 9. kesäkuuta 2015 12:49 To: development@qt-project.org Subject: Re: [Development] Qt 5.5.0 header diff On Tue, Jun 09, 2015 at 07:35:45AM +, Knoll Lars wrote: On 08/06/15 23:58, development- bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany.com@qt- project.org on behalf of thiago.macie...@intel.com wrote: On Monday 08 June 2015 22:31:15 Marc Mutz wrote: It would probably be a good idea to do an additional header diff (incl. new headers) on the ML after the alpha. I don't follow the development of modules other than QtBase closely, nor do I want to, and apparently I'm too strict a reviewer to be regularly invited on new API Agree. Let's put this into our planning for 5.6. One header diff/review at the time we branch 5.6, and a final one to cross-check before the RC. Well, that's exactly the kind of people we want reviewing our APIs... Thiago's right. If there's one place we want to be very strict it's on our APIs. Everything else we can still fix later on, but APIs are out there and will stick for a long time, so we better get them right. wouldn't that mean pulling the emergency brake on 5.5 and allowing a further ~two week slip in the schedule to actually fix the problem now that we are aware of it? i think we already have enough experience with how well next time works in practice ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Tue, Jun 09, 2015 at 10:59:32AM +, Heikkinen Jani wrote: Hi, I tried to create error reports about the findings to be able to follow-up the progress. Please create new one if something is missing. the point was about the entirely new headers that were not in the diffs, i.e., entirely new apis. it's a quite different (and much bigger) task than ensuring compatibility with existing api revisions. i can create a task, but it's not up to me to actually schedule it. lars (or multiple other maintainers) need to make that call. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 08/06/15 23:58, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Monday 08 June 2015 22:31:15 Marc Mutz wrote: It would probably be a good idea to do an additional header diff (incl. new headers) on the ML after the alpha. I don't follow the development of modules other than QtBase closely, nor do I want to, and apparently I'm too strict a reviewer to be regularly invited on new API Agree. Let's put this into our planning for 5.6. One header diff/review at the time we branch 5.6, and a final one to cross-check before the RC. Well, that's exactly the kind of people we want reviewing our APIs... Thiago's right. If there's one place we want to be very strict it's on our APIs. Everything else we can still fix later on, but APIs are out there and will stick for a long time, so we better get them right. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Tuesday 09 June 2015 07:35:45 Knoll Lars wrote: On 08/06/15 23:58, development-bounces+lars.knoll=theqtcompany.com@qt- project.org on behalf of Thiago Macieira development- bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Monday 08 June 2015 22:31:15 Marc Mutz wrote: It would probably be a good idea to do an additional header diff (incl. new headers) on the ML after the alpha. I don't follow the development of modules other than QtBase closely, nor do I want to, and apparently I'm too strict a reviewer to be regularly invited on new API Agree. Let's put this into our planning for 5.6. One header diff/review at the time we branch 5.6, and a final one to cross-check before the RC. I don't think this is a header diff review. This is an API review, where we have people who've written new classes to come and present their API. They should do that in fact even as the feature is being finalised and is getting integrated. We can initiate it by doing a dump of new classes in the release. That should be easy, all we need is to compare include/QtXxxx/ file listing. We'd still need a header diff for new functions in existing classes. Usually, those are minor additions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtCore.diff
On Tuesday 09 June 2015 12:10:02 Olivier Goffart wrote: A change in the IsGadget flag is fine. Old code did not need this flag. And code that relies on it requires anyway that the code that register the types register the isGadget flag. Even if one could build a complicated use case that breaks, it would be very unlikely to happen. And yet it did happen, or we wouldn't be having this conversation. If Alex could do it in qtconnectivity, why can't others do it in other circumstances? And any change is dangerous. When we fix any small bug, there can always be applications that breaks because it was relying on the bug for something. The problem is the associated risk because this code is complex and varies depending on factors we usually don't think about. This isn't about your standard class that operates on data. Anyway, let us summarize the problem in that case. In Qt = 5.4, QtLocation was using QML Private API to basically creates QObject wrapper around QGeoCoordinate so it can be exposed in QML. But in Qt 5.5, one does not need private API, everybody can expose value types to QML just by adding Q_GADGET to it and registering Q_PROPERTY or Q_INVOKABLE. So QGeoCoordinate became a Q_GADGET. But for QML to be able to take advantage of it, the type needs to be registered with the QMetaType::IsGadget flag. This is automatic. But if the metatype is registered by code compiled with Qt 5.4 or before, the IsGadget flag is not present. This is what is happening in a application that was compiled against Qt 5.4, QGeoCoordinate was used in signal and slot and registered as a metatype by the application. QMetaType will detect the difference in the flags on the second registration and do a qFatal. The solution is obviously not to do a qFatal, but take the new flags in addition. And then everything works as expected. And register the metatype for the Q_GADGET, which it hadn't done before. My point is that you had not thought of this when you wrote the feature. Therefore, there shall be no more such features without major discussion because we are failing to see all the possible consequences. And I am not convinced yet we've found them all. What are the consequences of overriding the flag and the metatype? Could it be that the user did intentionally break compatibility, yet failed to recompile one module? That's what the qFatal was there for: a reminder. We're removing it. And it's not just the flag. I'm not convinced about the template detection either. You had to apply two late fixes to the detection so that we wouldn't break source compatibility or create unnecessary warnings. Yes, I had to apply fixes after the beta was released and it got tested in the wild. But is that not what beta releases are for? The problem is the precedent. We are not finding everything and this code is extremely complex. The more we add to it, the more complex it becomes (exponentially so). Well, then it will be reviewed as usual. There are few improvements that can be done to QMetaType that we were discussing at the summit, like the ability to modify list types (append and such) or including some of the C++11 features. I bet one can simplify qmetatype.h when we require C++11's decltype and proper SFINAE rules We will have to discuss each modification in the mailing list. And note that replacing the rules with C++11 simpler rules may have side- effects too, so you should not simplify for the sake of simplification. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtWidgets.diff
On 08 Jun 2015, at 11:07, Marc Mutz marc.m...@kdab.com wrote: On Friday 05 June 2015 10:11:27 Frederik Gladhorn wrote: diff --git a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h index a98d30f..5920c1f 100644 --- a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h +++ b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h @@ -52,7 +52,6 @@ public: NSView *nativeView() const; protected: -void init(NSView *parentView); bool event(QEvent *ev); private: This diff seems wrong. In Qt 5.5, the header That diff is actually for src/widgets/widgets/qmacnativewidget_mac.h . Change in question is cf5e5570. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtWidgets.diff
On Tuesday 09 June 2015 17:40:59 Sorvig Morten wrote: On 08 Jun 2015, at 11:07, Marc Mutz marc.m...@kdab.com wrote: On Friday 05 June 2015 10:11:27 Frederik Gladhorn wrote: diff --git a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h index a98d30f..5920c1f 100644 --- a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h +++ b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h @@ -52,7 +52,6 @@ public: NSView *nativeView() const; protected: -void init(NSView *parentView); bool event(QEvent *ev); private: This diff seems wrong. In Qt 5.5, the header That diff is actually for src/widgets/widgets/qmacnativewidget_mac.h . Change in question is cf5e5570. Ok, looks good then (ftr: no definition was present for the function) -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On 09/06/15 16:41, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Tuesday 09 June 2015 07:35:45 Knoll Lars wrote: On 08/06/15 23:58, development-bounces+lars.knoll=theqtcompany.com@qt- project.org on behalf of Thiago Macieira development- bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Monday 08 June 2015 22:31:15 Marc Mutz wrote: It would probably be a good idea to do an additional header diff (incl. new headers) on the ML after the alpha. I don't follow the development of modules other than QtBase closely, nor do I want to, and apparently I'm too strict a reviewer to be regularly invited on new API Agree. Let's put this into our planning for 5.6. One header diff/review at the time we branch 5.6, and a final one to cross-check before the RC. I don't think this is a header diff review. This is an API review, where we have people who've written new classes to come and present their API. They should do that in fact even as the feature is being finalised and is getting integrated. We can initiate it by doing a dump of new classes in the release. That should be easy, all we need is to compare include/QtXxxx/ file listing. We'd still need a header diff for new functions in existing classes. Usually, those are minor additions. Sorry, maybe bad wording from my side. But with a header diff I meant a full diff that would include also new files/classes. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtDeclarative.diff
I started working on something that would diff QML API changes a while ago: https://codereview.qt-project.org/#/c/52625/ It's a little tricky, but it basically is just diffing the plugins.qmltypes files. After regenerating them and having old full copies because of the manual editing that occurs sometimes. And you need to diff the parsed tree because the order of lines changes sometimes. But I suppose the biggest hurdle to getting that tool in is that I wanted it to run as an autotest and fail if new symbols appear which aren't properly versioned (a little more work than just listing changes). -- Alan Alpert On Sat, Jun 6, 2015 at 2:23 AM, Liang Qi cavendish...@gmail.com wrote: On 6 June 2015 at 10:52, Allan Sandfeld Jensen k...@carewolf.com wrote: On Friday 05 June 2015, Frederik Gladhorn wrote: Would there be any way to generate diffs or changes for QML APIs? Perhaps a diff for all plugins.qmltypes files? But I guess that not all were updated yet. -- http://www.qiliang.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtTest.diff
On Monday 08 June 2015 15:29:46 Thiago Macieira wrote: On Monday 08 June 2015 15:26:26 Marc Mutz wrote: On Saturday 06 June 2015 10:11:45 Thiago Macieira wrote: return a QTemporaryDir (which implies passing in by output parameter) Or simply return QSharedPointerQTemporaryDir... Right, but no one has done it yet. https://codereview.qt-project.org/113933 -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Monday 08 June 2015 15:36:21 Thiago Macieira wrote: On Thursday 04 June 2015 15:29:10 Frederik Gladhorn wrote: It's time for the header diffs, please help review the changes (Qt 5.4.2 to 5.5.0) to make sure nothing that was added to the public headers slipped through when it shouldn't be there. We seem to be doing API reviews and finding mistakes in the code. Please note that the header diff does not include new files, so we're not doing API reviews on any new classes. API reviews should have been done twice already, before RC stage. It needs to be done once before the API is merged and once again between the alpha and beta releases. Are we skimping on our processes? Looking at some of the classes in modules other than QtBase, I get the feeling they were not widely reviewed, no. It would probably be a good idea to do an additional header diff (incl. new headers) on the ML after the alpha. I don't follow the development of modules other than QtBase closely, nor do I want to, and apparently I'm too strict a reviewer to be regularly invited on new API :) Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Monday 08 June 2015 15:40:01 Milian Wolff wrote: On Monday 08 June 2015 09:32:42 Thiago Macieira wrote: On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote: On 08-Jun-15 15:38, Marc Mutz wrote: QListQSize should be QVectorQSize Speaking of that, should we adjust the following recommendation in the docs? For most purposes, QList is the right class to use. Its index-based API is more convenient than QLinkedList's iterator-based API, and it is usually faster than QVector because of the way it stores its items in memory. It also expands to less code in your executable. No. Why not? It's simply a bad recommendation. See the other email: we want to keep QList in the API. We could expand the recommendation with more uses, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtCore.diff
On Monday 08 June 2015 15:58:23 Olivier Goffart wrote: There is no reason to stop improving qmetatype. The qFatal was there for a good reason. It was there for a good reason for the existing flags. But for new flags of course it does not make sens. It did make sense: the idea was that registering new flags would cause the very incompatibility we're seeing here. I'm not entirely convinced that we discussed all scenarios at QtCS, so I'm still skeptical about allowing the IsGadget flag. I insist that we \omitvalue for now, until we understand the consequences better. And it's not just the flag. I'm not convinced about the template detection either. You had to apply two late fixes to the detection so that we wouldn't break source compatibility or create unnecessary warnings. The freeze stays: no new flags in QMetaType until Qt 6, no more messing with the template black magic. You can't mandate that. Yes, I can. As the maintainer, I have the authority and mandate to oversee the changes to the module I maintain and that includes blocking changes I am unsatisfied with. A mailing list consensus can overrule me, as can the Chief Maintainer. We stay frozen until further notice. If you have new flags you want to propose, you can do it, but we'll need a mailing list discussion before the change is allowed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Monday 08 June 2015 22:31:15 Marc Mutz wrote: It would probably be a good idea to do an additional header diff (incl. new headers) on the ML after the alpha. I don't follow the development of modules other than QtBase closely, nor do I want to, and apparently I'm too strict a reviewer to be regularly invited on new API Well, that's exactly the kind of people we want reviewing our APIs... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Mon, Jun 8, 2015 at 3:27 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Tuesday 09 June 2015 00:12:47 Milian Wolff wrote: Sorry Thiago, but imo your answers are not on topic: The documentation is /wrong/. QList is _not_ the right container class to use for most purposes. If, inside Qt, it is currently (ab)used for historical reasons, well then fine. But can be /please/ get rid of the prominent endorsement in the documentation? Saying it should be preferred when interacting with existing (Qt) API is something altogether different than saying it should be used by default. It is *not* usually faster than QVector, and that is /especially/ because of the way it stores items in memory. That it expands to less code is afaik true, but only to a small margin, according to the measurements done by e.g. Volker Krause on KF5 code. Fair enough, go ahead and change it. +1 for not lying to Qt users. Our company has had to change a lot of our critical-path code to use QVector in recent months, and we probably would've started that way if not for the offending documentation. Regards, Alex Montgomery Director of Tools Technology Telltale Games ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Tuesday 09 June 2015 00:12:47 Milian Wolff wrote: Sorry Thiago, but imo your answers are not on topic: The documentation is /wrong/. QList is _not_ the right container class to use for most purposes. If, inside Qt, it is currently (ab)used for historical reasons, well then fine. But can be /please/ get rid of the prominent endorsement in the documentation? Saying it should be preferred when interacting with existing (Qt) API is something altogether different than saying it should be used by default. It is *not* usually faster than QVector, and that is /especially/ because of the way it stores items in memory. That it expands to less code is afaik true, but only to a small margin, according to the measurements done by e.g. Volker Krause on KF5 code. Fair enough, go ahead and change it. But Qt API that doesn't explicitly need an array for the data should continue to use QList. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Monday 08 June 2015 17:50:31 Thiago Macieira wrote: On Monday 08 June 2015 15:40:01 Milian Wolff wrote: On Monday 08 June 2015 09:32:42 Thiago Macieira wrote: On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote: On 08-Jun-15 15:38, Marc Mutz wrote: QListQSize should be QVectorQSize Speaking of that, should we adjust the following recommendation in the docs? For most purposes, QList is the right class to use. Its index-based API is more convenient than QLinkedList's iterator-based API, and it is usually faster than QVector because of the way it stores its items in memory. It also expands to less code in your executable. No. Why not? It's simply a bad recommendation. See the other email: we want to keep QList in the API. We could expand the recommendation with more uses, though. Sorry Thiago, but imo your answers are not on topic: The documentation is /wrong/. QList is _not_ the right container class to use for most purposes. If, inside Qt, it is currently (ab)used for historical reasons, well then fine. But can be /please/ get rid of the prominent endorsement in the documentation? Saying it should be preferred when interacting with existing (Qt) API is something altogether different than saying it should be used by default. It is *not* usually faster than QVector, and that is /especially/ because of the way it stores items in memory. That it expands to less code is afaik true, but only to a small margin, according to the measurements done by e.g. Volker Krause on KF5 code. Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtPositioning.diff
-Original Message- Thiago Macieira On Friday 05 June 2015 10:10:50 Frederik Gladhorn wrote: -qreal distanceTo(const QGeoCoordinate other) const; -qreal azimuthTo(const QGeoCoordinate other) const; +Q_INVOKABLE qreal distanceTo(const QGeoCoordinate other) const; +Q_INVOKABLE qreal azimuthTo(const QGeoCoordinate other) const; From C++, the module looks good. From QML, should there be some Q_REVISION above? It is not required. The above two functions existed in Qt 5.4 already. We merely swap the C++ object handling the QML representation for QGeoCoordinate. QGeoCoordinate is the new C++ handler and it needs to make the functionality available via Q_INVOKABLE. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtWidgets.diff
On Monday 08 June 2015 11:07:26 Marc Mutz wrote:
On Friday 05 June 2015 10:11:27 Frederik Gladhorn wrote:
diff --git a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h
b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h index a98d30f..5920c1f
100644
--- a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h
+++ b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h
@@ -52,7 +52,6 @@ public:
NSView *nativeView() const;
protected:
-void init(NSView *parentView);
bool event(QEvent *ev);
private:
This diff seems wrong. In Qt 5.5, the header
src/widgets/widgets/qmaccocoaviewcontainer_mac.h looks like this:
QT_BEGIN_NAMESPACE
class QMacCocoaViewContainerPrivate;
class Q_WIDGETS_EXPORT QMacCocoaViewContainer : public QWidget
{
Q_OBJECT
public:
QMacCocoaViewContainer(NSView *cocoaViewToWrap, QWidget *parent = 0);
virtual ~QMacCocoaViewContainer();
void setCocoaView(NSView *view);
NSView *cocoaView() const;
private:
Q_DECLARE_PRIVATE(QMacCocoaViewContainer)
};
QT_END_NAMESPACE
There's no actual diff between 5.4 and 5.5 in this header file.
Rest looks good, too, though I'd have made QSpacerItem::sizePolicy() const
inline: https://codereview.qt-project.org/113873
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtWidgets.diff
On Friday 05 June 2015 10:11:27 Frederik Gladhorn wrote:
diff --git a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h
b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h index a98d30f..5920c1f
100644
--- a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h
+++ b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h
@@ -52,7 +52,6 @@ public:
NSView *nativeView() const;
protected:
-void init(NSView *parentView);
bool event(QEvent *ev);
private:
This diff seems wrong. In Qt 5.5, the header
src/widgets/widgets/qmaccocoaviewcontainer_mac.h looks like this:
QT_BEGIN_NAMESPACE
class QMacCocoaViewContainerPrivate;
class Q_WIDGETS_EXPORT QMacCocoaViewContainer : public QWidget
{
Q_OBJECT
public:
QMacCocoaViewContainer(NSView *cocoaViewToWrap, QWidget *parent = 0);
virtual ~QMacCocoaViewContainer();
void setCocoaView(NSView *view);
NSView *cocoaView() const;
private:
Q_DECLARE_PRIVATE(QMacCocoaViewContainer)
};
QT_END_NAMESPACE
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtCore.diff
On Saturday 6. June 2015 11:17:30 Thiago Macieira wrote: On Friday 05 June 2015 10:11:28 Frederik Gladhorn wrote: I can't tell if the qmetatype.h template magic is binary compatible or not. As evidenced by a recent push [1] about the IsGadget flag, it isn't. I'm going to put a stop to this. qmetatype.h template magic is now frozen as of Qt 5.5 and until Qt 6.0, aside from bugfixes or pure additions that do not modify existing template classes. [1] https://codereview.qt-project.org/113652 The problem here is the qFail. We can just remove the qFail in this case (what the patch does) and we will be fine. There is no reason to stop improving qmetatype. Q_DECLARE_FLAGS(LoadHints, LoadHint) +Q_FLAG(LoadHint) +Q_FLAG(LoadHints) Do we need both Q_FLAG? That looks like a mistake. The code was just moved from Q_FLAGS to Q_FLAG. Both were there before and I kept it like that. It cannot really be changed otherwise code like staticQtMetaObject.indexOfEnumerator(LoadHint) or staticQtMetaObject.indexOfEnumerator(LoadHints) will break. The use of Q_ENUMS and Q_FLAGS with QFlags types is not really consistent within Qt. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote:
+typedef QPairqreal, qreal FrameRateRange;
Should be a struct, not a QPair:
FrameRateChange chg = ...;
chg.first... // what's first???
chg.second... // what's second???
enum Status {
UnavailableStatus,
UnloadedStatus,
@@ -169,6 +172,21 @@ public:
void setViewfinder(QGraphicsVideoItem *viewfinder);
void setViewfinder(QAbstractVideoSurface *surface);
+QCameraViewfinderSettings viewfinderSettings() const;
+void setViewfinderSettings(const QCameraViewfinderSettings settings);
+
+QListQCameraViewfinderSettings supportedViewfinderSettings(
+const QCameraViewfinderSettings settings =
QCameraViewfinderSettings()) const;
QCameraViewFinderSettings isn't marked as movable, so should be held in
QVector instead.
+QListQSize supportedViewfinderResolutions(
+const QCameraViewfinderSettings settings =
QCameraViewfinderSettings()) const;
QListQSize should be QVectorQSize
+QListFrameRateRange supportedViewfinderFrameRateRanges(
+const QCameraViewfinderSettings settings =
QListFrameRateChange should be QVectorFrameRateChange
QCameraViewfinderSettings()) const; +
+QListQVideoFrame::PixelFormat supportedViewfinderPixelFormats(
+const QCameraViewfinderSettings settings =
QCameraViewfinderSettings()) const;
QListPixelFormat should be QVectorPixelFormat (enum PixelFormat)
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On 08-Jun-15 15:38, Marc Mutz wrote: QListQSize should be QVectorQSize Speaking of that, should we adjust the following recommendation in the docs? For most purposes, QList is the right class to use. Its index-based API is more convenient than QLinkedList's iterator-based API, and it is usually faster than QVector because of the way it stores its items in memory. It also expands to less code in your executable. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtCore.diff
On Monday 8. June 2015 09:34:30 Thiago Macieira wrote: On Monday 08 June 2015 11:28:48 Olivier Goffart wrote: On Saturday 6. June 2015 11:17:30 Thiago Macieira wrote: On Friday 05 June 2015 10:11:28 Frederik Gladhorn wrote: I can't tell if the qmetatype.h template magic is binary compatible or not. As evidenced by a recent push [1] about the IsGadget flag, it isn't. I'm going to put a stop to this. qmetatype.h template magic is now frozen as of Qt 5.5 and until Qt 6.0, aside from bugfixes or pure additions that do not modify existing template classes. [1] https://codereview.qt-project.org/113652 The problem here is the qFail. We can just remove the qFail in this case (what the patch does) and we will be fine. There is no reason to stop improving qmetatype. The qFatal was there for a good reason. It was there for a good reason for the existing flags. But for new flags of course it does not make sens. The freeze stays: no new flags in QMetaType until Qt 6, no more messing with the template black magic. You can't mandate that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtQml.diff
On Friday 05 June 2015 10:11:30 Frederik Gladhorn wrote: +static bool startTcpDebugServer(int port, bool block = false, +const QString hostName = QString()); boolean argument should be an enum. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtTest.diff
On Monday 08 June 2015 15:26:26 Marc Mutz wrote: On Saturday 06 June 2015 10:11:45 Thiago Macieira wrote: return a QTemporaryDir (which implies passing in by output parameter) Or simply return QSharedPointerQTemporaryDir... Right, but no one has done it yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Mon, Jun 08, 2015 at 01:17:26PM +, Lopes Yoann wrote: On 08 Jun 2015, at 15:38, Marc Mutz marc.m...@kdab.com wrote: On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote: +typedef QPairqreal, qreal FrameRateRange; Should be a struct, not a QPair: FrameRateChange chg = ...; chg.first... // what's first??? chg.second... // what's second??? It’s …Range, not “…Change ;) I think having ‘first’ and ‘second’ for a range is pretty self-explanatory. well, lower bound and upper bound are more natural. also, it's more consistent to standardize on no QPair in the api. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtLocation.diff
On Friday 05 June 2015 10:10:37 Frederik Gladhorn wrote:
diff --git a/src/location/maps/qgeocodereply.h
b/src/location/maps/qgeocodereply.h index a30a863..f713e42 100644
--- a/src/location/maps/qgeocodereply.h
+++ b/src/location/maps/qgeocodereply.h
@@ -56,7 +59,7 @@ class QGeoServiceProviderPrivate;
class Q_LOCATION_EXPORT QGeoServiceProvider : public QObject
{
Q_OBJECT
-
+Q_ENUMS(Error)
public:
enum Error {
NoError,
Should be Q_ENUM(Error) after the enum Error?
But can be fixed in BC way.
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtTest.diff
On Saturday 06 June 2015 10:11:45 Thiago Macieira wrote: return a QTemporaryDir (which implies passing in by output parameter) Or simply return QSharedPointerQTemporaryDir... -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Monday 08 June 2015 15:38:21 Marc Mutz wrote: +QListQSize supportedViewfinderResolutions( +const QCameraViewfinderSettings settings = QCameraViewfinderSettings()) const; QListQSize should be QVectorQSize We know that QList is defective, but let's keep it in API. We'll get a chance to fix QList for Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtBluetooth.diff
On Friday 05 June 2015 10:11:25 Frederik Gladhorn wrote: +bool operator==(const QBluetoothHostInfo other) const; +bool operator!=(const QBluetoothHostInfo other) const; + should be non-member (friends, if needed) -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtTest.diff
On Mon, Jun 08, 2015 at 03:26:26PM +0200, Marc Mutz wrote: On Saturday 06 June 2015 10:11:45 Thiago Macieira wrote: return a QTemporaryDir (which implies passing in by output parameter) Or simply return QSharedPointerQTemporaryDir... smart pointers in the api are not liked by binding authors ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote: On 08-Jun-15 15:38, Marc Mutz wrote: QListQSize should be QVectorQSize Speaking of that, should we adjust the following recommendation in the docs? For most purposes, QList is the right class to use. Its index-based API is more convenient than QLinkedList's iterator-based API, and it is usually faster than QVector because of the way it stores its items in memory. It also expands to less code in your executable. No. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Monday 08 June 2015 09:32:42 Thiago Macieira wrote: On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote: On 08-Jun-15 15:38, Marc Mutz wrote: QListQSize should be QVectorQSize Speaking of that, should we adjust the following recommendation in the docs? For most purposes, QList is the right class to use. Its index-based API is more convenient than QLinkedList's iterator-based API, and it is usually faster than QVector because of the way it stores its items in memory. It also expands to less code in your executable. No. Why not? It's simply a bad recommendation. -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtCore.diff
On Monday 08 June 2015 11:28:48 Olivier Goffart wrote: On Saturday 6. June 2015 11:17:30 Thiago Macieira wrote: On Friday 05 June 2015 10:11:28 Frederik Gladhorn wrote: I can't tell if the qmetatype.h template magic is binary compatible or not. As evidenced by a recent push [1] about the IsGadget flag, it isn't. I'm going to put a stop to this. qmetatype.h template magic is now frozen as of Qt 5.5 and until Qt 6.0, aside from bugfixes or pure additions that do not modify existing template classes. [1] https://codereview.qt-project.org/113652 The problem here is the qFail. We can just remove the qFail in this case (what the patch does) and we will be fine. There is no reason to stop improving qmetatype. The qFatal was there for a good reason. The freeze stays: no new flags in QMetaType until Qt 6, no more messing with the template black magic. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Thursday 04 June 2015 15:29:10 Frederik Gladhorn wrote: It's time for the header diffs, please help review the changes (Qt 5.4.2 to 5.5.0) to make sure nothing that was added to the public headers slipped through when it shouldn't be there. We seem to be doing API reviews and finding mistakes in the code. Please note that the header diff does not include new files, so we're not doing API reviews on any new classes. API reviews should have been done twice already, before RC stage. It needs to be done once before the API is merged and once again between the alpha and beta releases. Are we skimping on our processes? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On 08 Jun 2015, at 15:38, Marc Mutz marc.m...@kdab.com wrote: On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote: +typedef QPairqreal, qreal FrameRateRange; Should be a struct, not a QPair: FrameRateChange chg = ...; chg.first... // what's first??? chg.second... // what's second??? It’s …Range, not “…Change ;) I think having ‘first’ and ‘second’ for a range is pretty self-explanatory. — Yoann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtQuickWidgets.diff
On 06/06/15 10:04, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Friday 05 June 2015 10:10:46 Frederik Gladhorn wrote: +#ifndef QT_NO_DRAGANDDROP +virtual void dragEnterEvent(QDragEnterEvent *); +virtual void dragMoveEvent(QDragMoveEvent *); +virtual void dragLeaveEvent(QDragLeaveEvent *); +virtual void dropEvent(QDropEvent *); +#endif + Is this a public libary? Yes. Are the above overrides or not? If they are overrides, add Q_DECL_OVERRIDE. The methods are overrides. The change looks good except for the missing Q_DECL_OVERRIDE. So far the drag events have been catched in the generic ::event() reimplementation, so nobody could have subclassed these methods in any meaningful way anyway. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtSvg.diff
On Saturday 6. June 2015 10:04:09 Thiago Macieira wrote: On Friday 05 June 2015 10:10:44 Frederik Gladhorn wrote: No changes, good. We ought to stop revving the version number for libraries that did not update at all... Maybe there was no API, But if you look a git loog, you will see several commits that adds feature, fix bugs, or optimize QtSvg. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtNetwork.diff
On 06/06/15 15:26, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Saturday 06 June 2015 14:22:20 Giuseppe D'Angelo wrote: Il 06/06/2015 13:27, Thiago Macieira ha scritto: Then why do we need them in QSslSocket? Technically they are be needed there, indeed, but I didn't want to cause an API asymmetry with the other functions for ciphers, certificates and so on, that's all. The symmetry only existed because we added them to QSslSocket before QSslCertificate existed. I'd rather new API existed only in QSslConfiguration. That way, we don't need to duplicate in QSslSocket. In that case you should probably also deprecate the methods in QSslSocket. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtTest.diff
On Friday 05 June 2015 10:10:47 Frederik Gladhorn wrote: +Q_TESTLIB_EXPORT QString qExtractTestData(const QString dirName); This API isn't finished. The function needs to return a QTemporaryDir (which implies passing in by output parameter) so that the caller properly cleans up the extracted test data. The rest looks good. I'd have put the qgpu_features function inside the QTest namespace, like everything else, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtDeclarative.diff
On Friday 05 June 2015 10:10:49 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtScript.diff
On Friday 05 June 2015 10:10:51 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtPositioning.diff
On Friday 05 June 2015 10:10:50 Frederik Gladhorn wrote: -qreal distanceTo(const QGeoCoordinate other) const; -qreal azimuthTo(const QGeoCoordinate other) const; +Q_INVOKABLE qreal distanceTo(const QGeoCoordinate other) const; +Q_INVOKABLE qreal azimuthTo(const QGeoCoordinate other) const; From C++, the module looks good. From QML, should there be some Q_REVISION above? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimedia.diff
On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtDeclarative.diff
On Friday 05 June 2015, Frederik Gladhorn wrote: Would there be any way to generate diffs or changes for QML APIs? `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtX11Extras.diff
On Friday 05 June 2015 10:10:54 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtScriptTools.diff
On Friday 05 June 2015 10:11:22 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtWebSockets.diff
On Friday 05 June 2015 10:11:19 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimediaWidgets.diff
On Friday 05 June 2015 10:10:53 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtPrintSupport.diff
On Friday 05 June 2015 10:11:21 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtQuick.diff
On Friday 05 June 2015 10:11:20 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtQuickTest.diff
On Friday 05 June 2015 10:10:37 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtLocation.diff
On Friday 05 June 2015 10:10:37 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtSensors.diff
On Friday 05 June 2015 10:10:34 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtWebChannel.diff
On Friday 05 June 2015 10:10:43 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtSvg.diff
On Friday 05 June 2015 10:10:44 Frederik Gladhorn wrote: No changes, good. We ought to stop revving the version number for libraries that did not update at all... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtSerialPort.diff
On Friday 05 June 2015 10:10:47 Frederik Gladhorn wrote: +#if QT_DEPRECATED_SINCE(5, 2) +QT_DEPRECATED void dataErrorPolicyChanged(QSerialPort::DataErrorPolicy policy); +#endif void dataTerminalReadyChanged(bool set); void requestToSendChanged(bool set); void error(QSerialPort::SerialPortError serialPortError); -void settingsRestoredOnCloseChanged(bool restore); +#if QT_DEPRECATED_SINCE(5, 3) +QT_DEPRECATED void settingsRestoredOnCloseChanged(bool restore); +#endif Retroactive deprecations are not allowed. Please change the macros to (5,5), even if the functions had been marked as deprecated in the documentation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtXmlPatterns.diff
On Friday 05 June 2015 10:10:45 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtQuickWidgets.diff
On Friday 05 June 2015 10:10:46 Frederik Gladhorn wrote: +#ifndef QT_NO_DRAGANDDROP +virtual void dragEnterEvent(QDragEnterEvent *); +virtual void dragMoveEvent(QDragMoveEvent *); +virtual void dragLeaveEvent(QDragLeaveEvent *); +virtual void dropEvent(QDropEvent *); +#endif + Is this a public libary? Are the above overrides or not? If they are overrides, add Q_DECL_OVERRIDE. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtSql.diff
On Friday 05 June 2015 10:11:26 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtOpenGL.diff
On Friday 05 June 2015 10:11:23 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtBluetooth.diff
On Friday 05 June 2015 10:11:25 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtGui.diff
On Friday 05 June 2015, Frederik Gladhorn wrote: Something is wrong with the diff. The qpen.h diff is listed as src/gui/painting/qpdfwriter.h. On the topic of qpen.h, I am a little concerned about the addition of Q_DECL_NOTHROW to the two non-inlined methods QPen(const QPen pen) and QPen operator=(const QPen pen). Q_DECL_NOEXCEPT should be fine I think, but throw() is represented in the C++ mangled name with MSVC. `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtOpenGLExtensions.diff
On Friday 05 June 2015 10:10:35 Frederik Gladhorn wrote: No changes, good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtMultimediaQuick_p.diff
On Friday 05 June 2015 10:10:42 Frederik Gladhorn wrote: Private library. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtGui.diff
On Friday 05 June 2015 10:10:38 Frederik Gladhorn wrote: +++ b/src/gui/accessible/qaccessible.h @@ -60,7 +60,6 @@ class QTextCursor; class Q_GUI_EXPORT QAccessible @@ -635,6 +636,12 @@ public: static const QString showMenuAction(); static const QString setFocusAction(); static const QString toggleAction(); +static const QString scrollLeftAction(); +static const QString scrollRightAction(); +static const QString scrollUpAction(); +static const QString scrollDownAction(); +static const QString nextPageAction(); +static const QString previousPageAction(); }; This is not Qt-like API. The strings are initialised on first use (all of them) but they are translated, which means they will not obey a change in translation settings. The old ones can't be fixed now, but we should fix the new ones not to return a const reference. Reviewed up to math3d and it was good up to that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtConcurrent.diff
On Friday 05 June 2015 10:10:39 Frederik Gladhorn wrote: Looks good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtNfc.diff
On Friday 05 June 2015 10:10:41 Frederik Gladhorn wrote: +//TODO Qt 6 the mimetype should be QString as it is UTF-8 Looks good, except the comment. We usually use ### Qt6 as a marker, not TODO. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtCore.diff
On Friday 05 June 2015 10:11:28 Frederik Gladhorn wrote: I can't tell if the qmetatype.h template magic is binary compatible or not. As evidenced by a recent push [1] about the IsGadget flag, it isn't. I'm going to put a stop to this. qmetatype.h template magic is now frozen as of Qt 5.5 and until Qt 6.0, aside from bugfixes or pure additions that do not modify existing template classes. [1] https://codereview.qt-project.org/113652 +++ b/src/corelib/plugin/qfactoryinterface.h Q_DECLARE_FLAGS(LoadHints, LoadHint) +Q_FLAG(LoadHint) +Q_FLAG(LoadHints) Do we need both Q_FLAG? That looks like a mistake. +// ### Qt6: check if there's a better way +class QStringList : public QListQString [...] -inline void sort(Qt::CaseSensitivity cs = Qt::CaseSensitive); -inline int removeDuplicates(); The above works only because: 1) QStringList is not exported 2) the functions in question are inlines However, if someone derives from QStringList and exports a class, using MSVC, then this may be binary incompatible. See qvector_msvc.h. I have not and will not investigate this further, so I don't know if this is real or not. If there's a bug reported on this, I will probably close it with you're committing too many mistakes (using MSVC and deriving from QStirngList). The rest looks good, but I hope I didn't miss anything in the Q_DECL_NOTHROW, Q_DECL_OVERRIDE and Q_DECL_CONSTEXPR noise. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtQml.diff
On Friday 05 June 2015 12:24:36 Simon Hausmann wrote: Those changes were not on qqmlerror.h but on qqmlfile.h. However the class in question - while exported - is marked as \internal in the docs. If it's ok with everyone, then I'll rename qqmfile.h into qqmlfile_p.h. If it is not used, sure. There's a bug in the script that it reports the wrong header sometimes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtDeclarative.diff
On 6 June 2015 at 10:52, Allan Sandfeld Jensen k...@carewolf.com wrote: On Friday 05 June 2015, Frederik Gladhorn wrote: Would there be any way to generate diffs or changes for QML APIs? Perhaps a diff for all plugins.qmltypes files? But I guess that not all were updated yet. -- http://www.qiliang.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtNetwork.diff
On Saturday 06 June 2015 14:22:20 Giuseppe D'Angelo wrote: Il 06/06/2015 13:27, Thiago Macieira ha scritto: Then why do we need them in QSslSocket? Technically they are be needed there, indeed, but I didn't want to cause an API asymmetry with the other functions for ciphers, certificates and so on, that's all. The symmetry only existed because we added them to QSslSocket before QSslCertificate existed. I'd rather new API existed only in QSslConfiguration. That way, we don't need to duplicate in QSslSocket. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtNetwork.diff
Il 06/06/2015 11:20, Thiago Macieira ha scritto: These should be in QSslConfiguration, not QSslSocket. They're in both, just like ciphers, certificates etc. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtXml.diff
Looks good. Cheers, Lars On 05/06/15 10:11, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Frederik Gladhorn development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of frederik.gladh...@theqtcompany.com wrote: ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtNetwork.diff
Il 06/06/2015 13:27, Thiago Macieira ha scritto: Then why do we need them in QSslSocket? Technically they are be needed there, indeed, but I didn't want to cause an API asymmetry with the other functions for ciphers, certificates and so on, that's all. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtGui.diff
On Saturday 06 June 2015 11:03:43 Allan Sandfeld Jensen wrote: On the topic of qpen.h, I am a little concerned about the addition of Q_DECL_NOTHROW to the two non-inlined methods QPen(const QPen pen) and QPen operator=(const QPen pen). Q_DECL_NOEXCEPT should be fine I think, but throw() is represented in the C++ mangled name with MSVC. The mangling scheme supports throw(), but I don't think that MSVC adds it to the functions. Unless you've actually seen it used in the wild. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtNetwork.diff
On Saturday 06 June 2015 11:30:39 Giuseppe D'Angelo wrote: Il 06/06/2015 11:20, Thiago Macieira ha scritto: These should be in QSslConfiguration, not QSslSocket. They're in both, just like ciphers, certificates etc. Then why do we need them in QSslSocket? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtNetwork.diff
On Friday 05 June 2015 10:11:29 Frederik Gladhorn wrote: +// EC settings. +QVectorQSslEllipticCurve ellipticCurves() const; +void setEllipticCurves(const QVectorQSslEllipticCurve curves); +static void setDefaultEllipticCurves(const QVectorQSslEllipticCurve curves); +static QVectorQSslEllipticCurve defaultEllipticCurves(); +static QVectorQSslEllipticCurve supportedEllipticCurves(); + These should be in QSslConfiguration, not QSslSocket. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
On Thursday, June 04, 2015 03:29:10 PM Frederik Gladhorn wrote: [...] Modules for which Git failed to retrieve changes: [...] QtWebEngine QtWebEngineWidgets Oops, I suppose we do need to look at the diffs for those though? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff
Il 04/06/2015 15:29, Frederik Gladhorn ha scritto: I'll send mails in reply to this one with the diffs attached (that will take a while). I see that a ton of changes are simply style refactorings -- adding Q_DECL_OVERRIDE, dropping Q_NO_USING, moving Q_ENUMS to Q_ENUM. Any chance of getting a diff without the noise from those? :\ Anyhow, thank you for taking charge of this. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
