Re: [Development] Suggestion to add labels when changing API

I really don’t think switch back to a monolithic repo is a good idea… But if I understand atomic commits across submodules as successful integrations in qt5, I think it has some meaning to me. Here are a few tasks which I think perhaps related with this topic. https://bugreports.qt.io/browse/QT

Re: [Development] QTimer::setInterval() and

On Thursday, 7 December 2017 09:22:12 PST Christian Ehrlicher wrote: > Am 07.12.2017 um 17:01 schrieb Thiago Macieira: > > So you upgrade your compiler. > > No problem from my side :) > > > See also how no version of Visual Studio has __has_include, so the > > functionality is disabled with Micro

Re: [Development] QTimer::setInterval() and

Il 07/12/2017 17:01, Thiago Macieira ha scritto: See also how no version of Visual Studio has __has_include, so the functionality is disabled with Microsoft's compiler until they implement the macro. Actually VS 2017 should have __has_include: https://docs.microsoft.com/en-us/cpp/visual-cpp-la

Re: [Development] QTimer::setInterval() and

Am 07.12.2017 um 17:01 schrieb Thiago Macieira: So you upgrade your compiler. No problem from my side :) See also how no version of Visual Studio has __has_include, so the functionality is disabled with Microsoft's compiler until they implement the macro. This is a conscious decision. Then it

Re: [Development] Suggestion to add labels when changing API

Hi, I think it is high time that we fix the underlying problem: supporting atomic commits across submodules. Once this is done we should revert our CI to test changes against latest version of all modules. As for how this could be done: * Adopt something like Google's repo tool: https://co

Re: [Development] QML and Qt Quick versioning of our modules

On 07/12/17 16:06, Jason H wrote: > Let me ask this, are the versions maintained separately from Qt? If they are, > then they should bump, but if they aren't you're just wasting effort. It may > be that modules can be maintained separately, but how often is that done? It > seems like even Qt 3D

[Development] Suggestion to add labels when changing API

Since http://lists.qt-project.org/pipermail/development/2016-October/027542.html , Coin tests all changes against Qt5 instead of the latest version of all modules. The situation is sth like, some new APIs were added to qtbase in 5.10, and other modules were adapted. But around beta or sometime(

Re: [Development] QML and Qt Quick versioning of our modules

> >1) sync minor versions to Qt release version: > >For Qt 5.11, we would provide QtQuick.Controls 2.11 > >This way, the challenge for the user is only to find out if it's version 1, 2 > >or 5. > > The "match the Qt version" pattern is used by QtPositioning, QtLocation, > Sensors, QtBluetooth and

Re: [Development] QTimer::setInterval() and

On Thursday, 7 December 2017 00:19:14 PST Christian Ehrlicher wrote: > Hi, > > According to QTimer documentation, > QTimer::setInterval(std::chrono::milliseconds) is available unconditionally > in Qt 5.9. But in qtimer.h the std::chrono - functions are guarded with > QT_HAS_INCLUDE(chrono) which

Re: [Development] QML and Qt Quick versioning of our modules

On Thu, Dec 7, 2017, at 02:53 PM, Frederik Gladhorn wrote: > I've lately been discussing with a few people in The Qt Company about our > versioning. Thanks for taking the initiative Frederik! > And a general confusion around which version does what. > Since we so far don't keep copies of old fun

Re: [Development] QML and Qt Quick versioning of our modules

>1) sync minor versions to Qt release version: >For Qt 5.11, we would provide QtQuick.Controls 2.11 >This way, the challenge for the user is only to find out if it's version 1, 2 >or 5. The "match the Qt version" pattern is used by QtPositioning, QtLocation, Sensors, QtBluetooth and QtNfc too.

Re: [Development] QML and Qt Quick versioning of our modules

> I've lately been discussing with a few people in The Qt Company about our > versioning. > Historically it was a good idea to not couple Qt Quick too tightly to general > Qt releases. There were quite some constraints and added flexibility was nice. > Qt Quick has matured a lot though, so I thi

Re: [Development] QT printing via CUPS (advanced printing dalog box missing)

Thanks for picking this up and working on it :) Frederik On onsdag 6. desember 2017 15.35.44 CET Albert Astals Cid wrote: > El dilluns, 4 de desembre de 2017, a les 15:16:16 CET, Albert Astals Cid va > > escriure: > > El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va > >

Re: [Development] QML and Qt Quick versioning of our modules

On 07.12.2017 15:53, Frederik Gladhorn wrote: 1) sync minor versions to Qt release version: For Qt 5.11, we would provide QtQuick.Controls 2.11 This way, the challenge for the user is only to find out if it's version 1, 2 or 5. This sounds troublesome if Qt 6.0 comes when Qt Quick Controls wo

[Development] QML and Qt Quick versioning of our modules

Hi all, I've lately been discussing with a few people in The Qt Company about our versioning. Historically it was a good idea to not couple Qt Quick too tightly to general Qt releases. There were quite some constraints and added flexibility was nice. Qt Quick has matured a lot though, so I think

Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution

Hmm.. but what to do with QtQuickCompiler then? Which sources are not available… Yuri Sent from Mail for Windows 10 From: Konstantin Tokarev Sent: Saturday, December 2, 2017 1:59:31 AM To: Yuri Alexandrov Cc:

[Development] Qt 5.10.0 and Qt Creator 4.5.0 released

Hi everyone! I am happy to announce that Qt 5.10.0 and Qt Creator 4.5.0 are released today. More information about releases can be found from blog posts: Qt 5.10.0: http://blog.qt.io/blog/2017/12/07/qt-5-10-released/ Qt Creator 4.5.0: http://blog.qt.io/blog/2017/12/07/qt-creator-4-5-0-released/

Re: [Development] QTimer::setInterval() and

Il 07/12/2017 10:55, Christian Ehrlicher ha scritto: And shouldn't the documentation state that some functions are not available, even the used compiler supports it, just because the check is using some other feature which prevents the usage... Yes, it should. Please file a bug report. Cheers

Re: [Development] QTimer::setInterval() and

Gesendet: Donnerstag, 07. Dezember 2017 um 10:37 Uhr Von: "Giuseppe D'Angelo" An: development@qt-project.org Betreff: Re: [Development] QTimer::setInterval() and Support for from the Standard Library is one of the things that Qt includes conditionally. I'm not sure which platform we want to

Re: [Development] QTimer::setInterval() and

Il 07/12/2017 09:19, Christian Ehrlicher ha scritto: From my pov is a c++11 feature and since Qt5.9 needs c++11 the include gueard is superfluous. But I don't know if there is a supported platform which is still supported and chrono is not available... If the include guard is superflouos, I c

[Development] QTimer::setInterval() and

Hi,   According to QTimer documentation, QTimer::setInterval(std::chrono::milliseconds) is available unconditionally in Qt 5.9. But in qtimer.h the std::chrono - functions are guarded with QT_HAS_INCLUDE(chrono) which expands to __has_include(chrono) or 0. The problem is that gcc 4.8 doesn't kno