From samuel.gaist at edeltech.ch Sun May 1 01:09:29 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 1 May 2016 01:09:29 +0200 Subject: [Development] Qt QuickLook plugin Message-ID: Hi, I wrote a small QuickLook plugin for OS X that allows to get a preview of Qt's .pro, .pri and .qrc files without opening any editor. Would there be any interest in making it part of the standard OS X installation ? If so, what would be the process to include it ? Cheers Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Jake.Petroules at qt.io Sun May 1 01:47:57 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sat, 30 Apr 2016 23:47:57 +0000 Subject: [Development] Qt QuickLook plugin In-Reply-To: References: Message-ID: That would be pretty awesome. It's possible we could ship it inside of Qt Creator? You can put them in either ~/Library/QuickLook or in $BUNDLE_CONTENTS/Library/QuickLook On Apr 30, 2016, at 4:09 PM, Samuel Gaist > wrote: Hi, I wrote a small QuickLook plugin for OS X that allows to get a preview of Qt's .pro, .pri and .qrc files without opening any editor. Would there be any interest in making it part of the standard OS X installation ? If so, what would be the process to include it ? Cheers Samuel _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Mon May 2 07:05:07 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 2 May 2016 05:05:07 +0000 Subject: [Development] Qt CI reliability In-Reply-To: <4166383.CnvrWBLNsi@titan> References: <4166383.CnvrWBLNsi@titan> Message-ID: Hi Sean, Firstofall, I do apologize for the inconvenience caused by the CI system. We are fully aware of the situation, and the effect is has for productivity. All the developers of The Qt Company are using exactly the same CI system. To address the problems, we had with Jenkins based CI we started to develop new CI system built from the ground up to serve the needs of Qt. Unfortunately, it has taken us longer than we anticipated to get the new CI system stabile, and there are still a lot of failures caused by the CI itself. We are also continuously improving the test asset to make it less prone for errors, including identification of flaky cases and fixing and/or temporarily blacklisting these. While we unfortunately do not have 24x7 sysadmins, we do have persons dedicated to operate the CI system, as well as support from IT as needed for the infrastructure. In addition, we are still putting a significant effort into developing the CI further and stabilizing it. And, yes, we are also continuously monitoring the infrastructure of the CI systems as well as planning how to improve it further in the future. Yours, Tuukka > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Sean Harmer > Sent: lauantaina 30. huhtikuuta 2016 22.26 > To: development at qt-project.org > Subject: [Development] Qt CI reliability > > Hi, > > after yet another 5 hour wait just to be greeted with yet another random > failure with no build logs I'm getting really tired of the poor reliability of the > Qt CI system. > > https://codereview.qt-project.org/#/c/157590/ > > has been greeted with genuine failures, failures in qtdeclarative, > qtxmlpatterns, multiple random failures in qt3d despite being a simple > change which I suspect are due to issues on one or more CI nodes. > > I appreciate the new CI is more efficient than the previous implementation > but it still has a very high rate of failed integration attempts. For a piece of > infrastructure that is critical to the Qt Project the CI system should have > 24x7 sysadmin support. I'm not expecting devs to be doing this. The Qt > Company has sys admins supported by license fees yet we see example after > example of the support being substandard. Certificates expiring, disks filling > up, upgrades being performed to coincide with feature freezes, upgrades > performed then going home for the weekend leaving systems in an unfit > state. > > Such long waits resulting in random failures is killing both productivity and > motivation. This whole week seems to have been nothing other than an > endless cycle of staging and re-staging. We're doing our best to get Qt 3D into > shape for Qt 5.7 but this is being hamstrung by the infrastructure. > > I don't understand how sysadmins can be caught out by disks filling up > without them being notified. Why is there no server monitoring in place? > Likewise for the numerous SSL certificate expirations over the last couple of > years. > > Now being in the same situation of seemingly endless failures over a holiday > weekend, it seems my backlog will continue to get longer whilst my will > power to dedicate my personal time to meeting the release deadline so that > TQC sysadmins can go on their summer vacations wanes. > > I would be very grateful if anybody happens to read this and is available to > look at the current CI issues. Please can TQC management dedicate > resources to sorting out the underlying resource shortages for administering > the CI, putting on place some reliable server monitoring that actually gets > acted upon and giving the project the system it should have. > > Thank you and enjoy what is left of the holiday weekend. > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 > 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform- > independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Eike.Ziller at qt.io Mon May 2 09:07:19 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 2 May 2016 07:07:19 +0000 Subject: [Development] Qt QuickLook plugin In-Reply-To: References: Message-ID: <8B275AEE-E22C-498D-AAF7-5A15432E768D@qt.io> > On May 1, 2016, at 01:47, Jake Petroules wrote: > > That would be pretty awesome. It's possible we could ship it inside of Qt Creator? You can put them in either ~/Library/QuickLook or in $BUNDLE_CONTENTS/Library/QuickLook That made me start wondering why I do see a text preview for .qml files. We do declare these as OSType text in Qt Creator’s Info.plist. So I tried https://codereview.qt-project.org/157721 for .pro, .pri, .qbs and .qrc as well, so far without any effect, but maybe that is because of some fancy OS caching of these values? Br, Eike >> On Apr 30, 2016, at 4:09 PM, Samuel Gaist wrote: >> >> Hi, >> >> I wrote a small QuickLook plugin for OS X that allows to get a preview of Qt's .pro, .pri and .qrc files without opening any editor. >> >> Would there be any interest in making it part of the standard OS X installation ? >> >> If so, what would be the process to include it ? >> >> Cheers >> Samuel >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at theqtcompany.com > Consulting Services Engineer - The Qt Company > Qbs build system evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon May 2 04:35:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 01 May 2016 19:35:19 -0700 Subject: [Development] Short QDateTime optimisation Message-ID: <5784738.OpFL0vJWxE@tjmaciei-mobl4> Hello https://codereview.qt-project.org/157714 I've just pushed one large commit that changes QDateTime to support a "short QDateTime Optimisation". Inspired by the SSO mechanism used in libc++ and similar to what we've done to QVersionNumber, I've made QDateTime not allocate memory for most uses (local time or UTC, within 2 million years of 1970). The optimisation is only for 64-bit systems, since QDateTime simply wasn't wide enough to accommodate the data. 32 bits isn't enough for storing seconds since 1970, much less milliseconds and the extra information we needed. But on 64-bit systems, the pointer is split in two: 8 bits for status flags (including the LSB indicating it's a short QDateTime) and 56 bits for the millisecond count. The commit is quite large. I will spend some time during the next week seeing if I can split it up into bite-sized chunks. Meanwhile, I'd like to ask for help testing this. Since I've dropped the use of QSharedDataPointer, I might have introduced sharing issues. And I'd really like someone to run the unit tests on a big-endian system. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Mon May 2 10:26:26 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 2 May 2016 08:26:26 +0000 Subject: [Development] Short QDateTime optimisation In-Reply-To: <5784738.OpFL0vJWxE@tjmaciei-mobl4> References: <5784738.OpFL0vJWxE@tjmaciei-mobl4> Message-ID: <26B2B556-9E83-45F5-A748-FB3EC8C18D1F@qt.io> On May 1, 2016, at 7:35 PM, Thiago Macieira > wrote: Hello https://codereview.qt-project.org/157714 I've just pushed one large commit that changes QDateTime to support a "short QDateTime Optimisation". Inspired by the SSO mechanism used in libc++ and similar to what we've done to QVersionNumber, I've made QDateTime not allocate memory for most uses (local time or UTC, within 2 million years of 1970). The optimisation is only for 64-bit systems, since QDateTime simply wasn't wide enough to accommodate the data. 32 bits isn't enough for storing seconds since 1970, much less milliseconds and the extra information we needed. But on 64-bit systems, the pointer is split in two: 8 bits for status flags (including the LSB indicating it's a short QDateTime) and 56 bits for the millisecond count. The commit is quite large. I will spend some time during the next week seeing if I can split it up into bite-sized chunks. Meanwhile, I'd like to ask for help testing this. Since I've dropped the use of QSharedDataPointer, I might have introduced sharing issues. And I'd really like someone to run the unit tests on a big-endian system. Too bad, I thought I could have helped you here but the MIPS board I just bought is LE. :( You could always try Debian mips or ppc in qemu. They have prebuilt images. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at qt.io Mon May 2 11:14:24 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 2 May 2016 11:14:24 +0200 Subject: [Development] Qt CI reliability In-Reply-To: <4166383.CnvrWBLNsi@titan> References: <4166383.CnvrWBLNsi@titan> Message-ID: <2683884.qFcU6NViYl@42> On Saturday 30 of April 2016 20:26:20 Sean Harmer wrote: > Hi, Hi, > after yet another 5 hour wait just to be greeted with yet another random > failure with no build logs I'm getting really tired of the poor reliability > of the Qt CI system. I'm sorry about that. > https://codereview.qt-project.org/#/c/157590/ > > has been greeted with genuine failures, failures in qtdeclarative, > qtxmlpatterns, multiple random failures in qt3d despite being a simple > change which I suspect are due to issues on one or more CI nodes. I scanned through the failures and it seems that you had a very bad luck. I know CI should not be about luck and therefore I'm really sorry about that. You tried to stage the change 7 times 1. Failed to compile qt3d (broken change https://codereview.qt-project.org/#/c/157593/) 2. Looks like a network connectivity failure, logs were not flushed as they should, so you can blame CI 3. Blame CI, we failed to acquire a free machine for 5h, I will look at that later 4. Failed to compile qt3d (broken change https://codereview.qt-project.org/#/c/157590/) 5. Failed to compile qt3d (broken change https://codereview.qt-project.org/#/c/157590/), same as 4 6. Looks like a network connectivity failure, logs were not flushed as they should, so you can blame CI, same as 2 7. Passed I will ask IT about network, it seems that network interface was re-configured during CI run and DHCP assigned a different IP. It should not happen (TM) Rule of thumb is: if logs show broken compilation it means: real problem, don't blame CI. There are three main reasons, that I'm aware of, that can cause the problem (sorted according to the probability): 1. One of changes being integrated broke the compilation 2. One of module dependencies broke source compatibility 3. There was a untested template update (this reason will almost disappear soon) *. There was huge radiation in Finland, but that you would know from the news ;-) Cheers, Jędrek From Lars.Knoll at qt.io Mon May 2 12:46:53 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Mon, 2 May 2016 10:46:53 +0000 Subject: [Development] Retiring libtiff too In-Reply-To: References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <201604292114.17468.kde@carewolf.com> Message-ID: <1A23B671-B115-4D34-A415-38B01A7CE4D0@qt.io> On 30/04/16 12:22, "Development on behalf of Richard Moore" on behalf of rich at kde.org> wrote: On 29 April 2016 at 20:14, Allan Sandfeld Jensen > wrote: On Friday 29 April 2016, Thiago Macieira wrote: > See https://lists.clearlinux.org/pipermail/dev/2016-April/000290.html > > This is yet another reason we have to stop bundling third party components, > especially the image and movie formats. > > So I recommend dropping the libtiff 3rdparty component and keep the plugin > for when the system library is found. Our binaries should not include > libqtiff. Well, on Linux these libraries are nicely available on the system. But it does not help us on Windows, where we do have to ship these libraries if we want to provide something that's easy to use for our users/customers. So while I don't like us having copies of these libraries in our repositories, not shipping any support for these image formats in our packages is not a good option neither. Do you have any citations for these issues? TIFF is a pretty important format being the raw format of many if not most digital cameras. It also isn't a web format so the vectors of potential attacks are limited ​Isn't commonly used on the web, and can't be used on the web are different. Do we have code that prevents such usage? I'm not aware we even have an API to limit the set of image format plugins that would get loaded. No, there's currently no option to limit the image formats that are being loaded apart from not shipping the plugin. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From szehowe.koh at gmail.com Mon May 2 14:37:47 2016 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Mon, 2 May 2016 20:37:47 +0800 Subject: [Development] Scope of source code license files Message-ID: Hello, The LICENSE.GPLvX and LICENSE.LGPLvX files from http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say "You may use, distribute and copy the Qt GUI Toolkit under the terms of..." Is this correct? What about non-GUI parts of the toolkit? Regards, Sze-Howe From thiago.macieira at intel.com Mon May 2 17:45:42 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 02 May 2016 08:45:42 -0700 Subject: [Development] Short QDateTime optimisation In-Reply-To: <26B2B556-9E83-45F5-A748-FB3EC8C18D1F@qt.io> References: <5784738.OpFL0vJWxE@tjmaciei-mobl4> <26B2B556-9E83-45F5-A748-FB3EC8C18D1F@qt.io> Message-ID: <11190079.xsdICuNDTv@tjmaciei-mobl4> On segunda-feira, 2 de maio de 2016 08:26:26 PDT Jake Petroules wrote: > Too bad, I thought I could have helped you here but the MIPS board I just > bought is LE. > > You could always try Debian mips or ppc in qemu. They have prebuilt images. Don't have time for that. I'll do a review of the MIPS assembly output. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon May 2 17:52:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 02 May 2016 08:52:00 -0700 Subject: [Development] Retiring libtiff too In-Reply-To: <1A23B671-B115-4D34-A415-38B01A7CE4D0@qt.io> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <1A23B671-B115-4D34-A415-38B01A7CE4D0@qt.io> Message-ID: <4089895.NeDWYvBEcS@tjmaciei-mobl4> On segunda-feira, 2 de maio de 2016 10:46:53 PDT Lars Knoll wrote: > Well, on Linux these libraries are nicely available on the system. But it > does not help us on Windows, where we do have to ship these libraries if we > want to provide something that's easy to use for our users/customers. Let me question that: do we want to provide something easy which is a potential security hole? Even if we upgrade libtiff to the latest that fixes all issues, there will be more. How are we dealing with CVEs from our bundled third party, especially those that end up in our binaries? How are our users and your customers? > So while I don't like us having copies of these libraries in our > repositories, not shipping any support for these image formats in our > packages is not a good option neither. I kinda disagree. I would prefer an opt-in for those poeple. > No, there's currently no option to limit the image formats that are being > loaded apart from not shipping the plugin. Aside from not including it. How are the qtimageformats packaged in our binaries? Are they installed automatically? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon May 2 18:07:24 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 02 May 2016 19:07:24 +0300 Subject: [Development] Short QDateTime optimisation In-Reply-To: <5784738.OpFL0vJWxE@tjmaciei-mobl4> References: <5784738.OpFL0vJWxE@tjmaciei-mobl4> Message-ID: <3694691462205244@web6j.yandex.ru> 02.05.2016, 10:44, "Thiago Macieira" : > Hello > > https://codereview.qt-project.org/157714 > > I've just pushed one large commit that changes QDateTime to support a "short > QDateTime Optimisation". Inspired by the SSO mechanism used in libc++ and > similar to what we've done to QVersionNumber, I've made QDateTime not allocate > memory for most uses (local time or UTC, within 2 million years of 1970). > > The optimisation is only for 64-bit systems, since QDateTime simply wasn't > wide enough to accommodate the data. 32 bits isn't enough for storing seconds > since 1970, much less milliseconds and the extra information we needed. But on > 64-bit systems, the pointer is split in two: 8 bits for status flags (including > the LSB indicating it's a short QDateTime) and 56 bits for the millisecond > count. > > The commit is quite large. I will spend some time during the next week seeing > if I can split it up into bite-sized chunks. > > Meanwhile, I'd like to ask for help testing this. Since I've dropped the use > of QSharedDataPointer, I might have introduced sharing issues. And I'd really > like someone to run the unit tests on a big-endian system. Do you mean 64-bit big-endian system, or both 32-bit and 64-bit? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Mon May 2 18:15:23 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 02 May 2016 09:15:23 -0700 Subject: [Development] Short QDateTime optimisation In-Reply-To: <3694691462205244@web6j.yandex.ru> References: <5784738.OpFL0vJWxE@tjmaciei-mobl4> <3694691462205244@web6j.yandex.ru> Message-ID: <1771012.YKzuU8xfv4@tjmaciei-mobl4> On segunda-feira, 2 de maio de 2016 19:07:24 PDT Konstantin Tokarev wrote: > Do you mean 64-bit big-endian system, or both 32-bit and 64-bit? 64-bit big endian. On 32-bit it should not enable the optimisation because 32 bits aren't enough bits. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at qt.io Mon May 2 20:07:29 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Mon, 2 May 2016 18:07:29 +0000 Subject: [Development] Retiring libtiff too In-Reply-To: <4089895.NeDWYvBEcS@tjmaciei-mobl4> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <1A23B671-B115-4D34-A415-38B01A7CE4D0@qt.io> <4089895.NeDWYvBEcS@tjmaciei-mobl4> Message-ID: <366F1A65-34F8-4A10-A431-E52CF268AE51@qt.io> On 02/05/16 17:52, "Development on behalf of Thiago Macieira" wrote: >On segunda-feira, 2 de maio de 2016 10:46:53 PDT Lars Knoll wrote: >> Well, on Linux these libraries are nicely available on the system. But it >> does not help us on Windows, where we do have to ship these libraries if we >> want to provide something that's easy to use for our users/customers. > >Let me question that: do we want to provide something easy which is a >potential security hole? Even if we upgrade libtiff to the latest that fixes >all issues, there will be more. How are we dealing with CVEs from our bundled >third party, especially those that end up in our binaries? How are our users >and your customers? I agree that we need to figure out how to handle this. I'm just pointing out that simply removing lots of functionality might not the right answer neither. > >> So while I don't like us having copies of these libraries in our >> repositories, not shipping any support for these image formats in our >> packages is not a good option neither. > >I kinda disagree. I would prefer an opt-in for those poeple. That's of course an option, but if the opt-in means 'download libtiff yourself, figure out how to compile it, then recompile qtimageformats', we have a very user-unfriendly way of solving the problem. > >> No, there's currently no option to limit the image formats that are being >> loaded apart from not shipping the plugin. > >Aside from not including it. How are the qtimageformats packaged in our >binaries? Are they installed automatically? Currently they are automatically installed. Cheers, Lars From thiago.macieira at intel.com Mon May 2 20:20:31 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 02 May 2016 11:20:31 -0700 Subject: [Development] Retiring libtiff too In-Reply-To: <366F1A65-34F8-4A10-A431-E52CF268AE51@qt.io> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <4089895.NeDWYvBEcS@tjmaciei-mobl4> <366F1A65-34F8-4A10-A431-E52CF268AE51@qt.io> Message-ID: <14505575.sqUJnTsOxB@tjmaciei-mobl4> On segunda-feira, 2 de maio de 2016 18:07:29 PDT Lars Knoll wrote: > >> So while I don't like us having copies of these libraries in our > >> repositories, not shipping any support for these image formats in our > >> packages is not a good option neither. > > > >I kinda disagree. I would prefer an opt-in for those poeple. > > That's of course an option, but if the opt-in means 'download libtiff > yourself, figure out how to compile it, then recompile qtimageformats', we > have a very user-unfriendly way of solving the problem. > >Aside from not including it. How are the qtimageformats packaged in our > >binaries? Are they installed automatically? > > Currently they are automatically installed. At the very least we should not automatically install it. We can provide the binaries for opt-in installation for those who want/need it, with the appropriate warning that they need to follow the security bulletins. In fact, we should have an installer page showing all the bundled third-party libraries and let people know that they're there for convenience only and it's their responsibility to follow security bulletins for those pieces of software. We will upgrade only on our own releases and we will not provide security updates in-between. But we should provide security updates on EVERY release. That means we need to follow the CVEs for every piece of bundled third-party software, be it source or binary form, and apply patches that may be necessary. In time, the following CVEs are outstanding for libtiff as of version 4.0.6. CVE-2014-9655 CVE-2015-1547 CVE-2015-8665 CVE-2015-8683 CVE-2015-7554 CVE-2015-8668 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon May 2 20:20:46 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 02 May 2016 11:20:46 -0700 Subject: [Development] Retiring libtiff too In-Reply-To: <201604292114.17468.kde@carewolf.com> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <201604292114.17468.kde@carewolf.com> Message-ID: <2312925.azTe1mbpsF@tjmaciei-mobl4> On sexta-feira, 29 de abril de 2016 21:14:17 PDT Allan Sandfeld Jensen wrote: > Do you have any citations for these issues? CVE-2014-9655 CVE-2015-1547 CVE-2015-8665 CVE-2015-8683 CVE-2015-7554 CVE-2015-8668 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at qt.io Tue May 3 08:39:42 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Tue, 3 May 2016 06:39:42 +0000 Subject: [Development] Retiring libtiff too In-Reply-To: <14505575.sqUJnTsOxB@tjmaciei-mobl4> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <4089895.NeDWYvBEcS@tjmaciei-mobl4> <366F1A65-34F8-4A10-A431-E52CF268AE51@qt.io> <14505575.sqUJnTsOxB@tjmaciei-mobl4> Message-ID: <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> On 02/05/16 20:20, "Development on behalf of Thiago Macieira" wrote: >On segunda-feira, 2 de maio de 2016 18:07:29 PDT Lars Knoll wrote: >> >> So while I don't like us having copies of these libraries in our >> >> repositories, not shipping any support for these image formats in our >> >> packages is not a good option neither. >> > >> >I kinda disagree. I would prefer an opt-in for those poeple. >> >> That's of course an option, but if the opt-in means 'download libtiff >> yourself, figure out how to compile it, then recompile qtimageformats', we >> have a very user-unfriendly way of solving the problem. > >> >Aside from not including it. How are the qtimageformats packaged in our >> >binaries? Are they installed automatically? >> >> Currently they are automatically installed. > >At the very least we should not automatically install it. We can provide the >binaries for opt-in installation for those who want/need it, with the >appropriate warning that they need to follow the security bulletins. > >In fact, we should have an installer page showing all the bundled third-party >libraries and let people know that they're there for convenience only and it's >their responsibility to follow security bulletins for those pieces of >software. We will upgrade only on our own releases and we will not provide >security updates in-between. > >But we should provide security updates on EVERY release. That means we need to >follow the CVEs for every piece of bundled third-party software, be it source >or binary form, and apply patches that may be necessary. Agree with this. Ideally, I would like to get rid of these libraries in src/3rdparty. Instead, we should build up to date versions of these libs in Coin, and simply ship those together with our Qt libraries. With the online installers it should in the longer term even be possible to ship updates for these libraries independent of a new Qt release. Cheers, Lars > >In time, the following CVEs are outstanding for libtiff as of version 4.0.6. > >CVE-2014-9655 CVE-2015-1547 CVE-2015-8665 CVE-2015-8683 >CVE-2015-7554 CVE-2015-8668 > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue May 3 08:58:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 02 May 2016 23:58:35 -0700 Subject: [Development] Retiring libtiff too In-Reply-To: <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <14505575.sqUJnTsOxB@tjmaciei-mobl4> <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> Message-ID: <1511135.HZSFv1EV2A@tjmaciei-mobl4> Em terça-feira, 3 de maio de 2016, às 06:39:42 PDT, Lars Knoll escreveu: > Ideally, I would like to get rid of these libraries in src/3rdparty. > Instead, we should build up to date versions of these libs in Coin, and > simply ship those together with our Qt libraries. With the online > installers it should in the longer term even be possible to ship updates > for these libraries independent of a new Qt release. How about Windows users who build from source? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at qt.io Tue May 3 09:06:41 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Tue, 3 May 2016 07:06:41 +0000 Subject: [Development] Retiring libtiff too In-Reply-To: <1511135.HZSFv1EV2A@tjmaciei-mobl4> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <14505575.sqUJnTsOxB@tjmaciei-mobl4> <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> <1511135.HZSFv1EV2A@tjmaciei-mobl4> Message-ID: <61D6342D-0487-490E-81F1-C9B015B7F11C@qt.io> On 03/05/16 08:58, "Development on behalf of Thiago Macieira" wrote: >Em terça-feira, 3 de maio de 2016, às 06:39:42 PDT, Lars Knoll escreveu: >> Ideally, I would like to get rid of these libraries in src/3rdparty. >> Instead, we should build up to date versions of these libs in Coin, and >> simply ship those together with our Qt libraries. With the online >> installers it should in the longer term even be possible to ship updates >> for these libraries independent of a new Qt release. > >How about Windows users who build from source? I don't see an issue here. If we have them in Coin, we should get both source and binary packages. Cheers, Lars From thiago.macieira at intel.com Tue May 3 09:20:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 03 May 2016 00:20:18 -0700 Subject: [Development] Retiring libtiff too In-Reply-To: <61D6342D-0487-490E-81F1-C9B015B7F11C@qt.io> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <1511135.HZSFv1EV2A@tjmaciei-mobl4> <61D6342D-0487-490E-81F1-C9B015B7F11C@qt.io> Message-ID: <2191109.KNnaj5tvjO@tjmaciei-mobl4> Em terça-feira, 3 de maio de 2016, às 07:06:41 PDT, Lars Knoll escreveu: > On 03/05/16 08:58, "Development on behalf of Thiago Macieira" > thiago.macieira at intel.com> wrote: > > >Em terça-feira, 3 de maio de 2016, às 06:39:42 PDT, Lars Knoll escreveu: > > > >> Ideally, I would like to get rid of these libraries in src/3rdparty. > >> Instead, we should build up to date versions of these libs in Coin, and > >> simply ship those together with our Qt libraries. With the online > >> installers it should in the longer term even be possible to ship updates > >> for these libraries independent of a new Qt release. > > > > > >How about Windows users who build from source? > > I don't see an issue here. If we have them in Coin, we should get both > source and binary packages. I meant that those users are used to the Qt build (especially qtbase) including just about everything they need for a complete Qt. It's not what I advise, but it's a convenience those users will miss. So I am asking: are we ok with dropping that convenience? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Shawn.Rutledge at qt.io Tue May 3 09:24:31 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 3 May 2016 07:24:31 +0000 Subject: [Development] Retiring libtiff too In-Reply-To: <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <4089895.NeDWYvBEcS@tjmaciei-mobl4> <366F1A65-34F8-4A10-A431-E52CF268AE51@qt.io> <14505575.sqUJnTsOxB@tjmaciei-mobl4> <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> Message-ID: > On 3 May 2016, at 08:39, Lars Knoll wrote: > Ideally, I would like to get rid of these libraries in src/3rdparty. Instead, we should build up to date versions of these libs in Coin, and simply ship those together with our Qt libraries. With the online installers it should in the longer term even be possible to ship updates for these libraries independent of a new Qt release. Sounds good to keep them up-to-date. But if a library makes a source-incompatible change or introduces a bug, it could cause some scrambling on our end to catch up with API changes, or falling back to the last-known-good version. So, use their HEADs most of the time but also have the ability to freeze for short periods at a specific SHA1? or use actual tagged releases most of the time but also have some way of falling back? From Shawn.Rutledge at qt.io Tue May 3 09:24:45 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 3 May 2016 07:24:45 +0000 Subject: [Development] Retiring libtiff too In-Reply-To: <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4> <4089895.NeDWYvBEcS@tjmaciei-mobl4> <366F1A65-34F8-4A10-A431-E52CF268AE51@qt.io> <14505575.sqUJnTsOxB@tjmaciei-mobl4> <659C78D4-800C-49C0-B541-D93B81E47426@qt.io> Message-ID: <7CB812CA-FBAB-4FAE-AEEF-CFFF87512C8A@qt.io> > On 3 May 2016, at 08:39, Lars Knoll wrote: > Ideally, I would like to get rid of these libraries in src/3rdparty. Instead, we should build up to date versions of these libs in Coin, and simply ship those together with our Qt libraries. With the online installers it should in the longer term even be possible to ship updates for these libraries independent of a new Qt release. Sounds good to keep them up-to-date. But if a library makes a source-incompatible change or introduces a bug, it could cause some scrambling on our end to catch up with API changes, or falling back to the last-known-good version. So, use their HEADs most of the time but also have the ability to freeze for short periods at a specific SHA1? or use actual tagged releases most of the time but also have some way of falling back? From olivier at woboq.com Tue May 3 10:21:03 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 03 May 2016 10:21:03 +0200 Subject: [Development] User script for Qt's gerrit to have code.woboq.org integration Message-ID: <292478137.hyj98CmglX@finn> Hi, Some time ago, I made an user script that tries to integrate with https:// code.woboq.org/qt5 with gerrit. (i posted it once but it was in a deep thread so you might not have noticed it) With that script, you can just click on a function in the code on gerrit and it will lookup in the code.woboq.org database and show the signature in a tooltip and links to code.woboq.org. (screenshot: http://i.imgur.com/Q3a2ixz.png ). It shows a disambiguation popup if there are several possibilities. It also makes the filename in the header of the diff clickable to the corresponding file on code.woboq.org The user script is there: https://code.woboq.org/qt-gerrit.user.js You can use it with the Greasmonkey extension on Firefox or the Tampermonkey extension on Chrome, or whatever equivalent extension for your browser. Feedback welcome. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Shawn.Rutledge at qt.io Tue May 3 13:14:05 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 3 May 2016 11:14:05 +0000 Subject: [Development] unique_ptr vs. QSharedPointer Message-ID: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> In what ways are they different? Is it OK to use unique_ptr in public API starting in 5.7? How about in internal implementation? From philwave at gmail.com Tue May 3 13:27:47 2016 From: philwave at gmail.com (Philippe) Date: Tue, 03 May 2016 13:27:47 +0200 Subject: [Development] unique_ptr vs. QSharedPointer In-Reply-To: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> References: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> Message-ID: <20160503132746.4AEA.6F0322A@gmail.com> These are completely different. Maybe you mean shared_ptr vs. QSharedPointer ? Philippe On Tue, 3 May 2016 11:14:05 +0000 Shawn Rutledge wrote: > In what ways are they different? > > Is it OK to use unique_ptr in public API starting in 5.7? > > How about in internal implementation? > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Tue May 3 13:31:21 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 3 May 2016 13:31:21 +0200 Subject: [Development] unique_ptr vs. QSharedPointer In-Reply-To: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> References: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> Message-ID: <201605031331.23150.marc.mutz@kdab.com> On Tuesday 03 May 2016 13:14:05 Shawn Rutledge wrote: > In what ways are they different? One implements unique ownership, isn't copyable, only movable, has almost zero overhead (with a stateless deleter), and is standardised from C++11 on, the other implements shared ownership, is copyable and movable, has the overhead of a separate control block, and is Qt-specific. > Is it OK to use unique_ptr in public API starting in 5.7? No. > How about in internal implementation? We have no experience, except in platform-specific code. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From Andre.Poenitz at qt.io Tue May 3 13:37:47 2016 From: Andre.Poenitz at qt.io (Andre Poenitz) Date: Tue, 3 May 2016 11:37:47 +0000 Subject: [Development] Qt API consistency (was: Re: unique_ptr vs. QSharedPointer) In-Reply-To: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> References: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> Message-ID: I'd like another question be answered before the discussion on yet another unsystematic use of yet another language or library feature starts: How important is API consistency for Qt today? Andre' From sean.harmer at kdab.com Tue May 3 15:45:03 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 03 May 2016 14:45:03 +0100 Subject: [Development] Qt CI reliability In-Reply-To: References: <4166383.CnvrWBLNsi@titan> Message-ID: <1866299.C2IvjzggEe@cartman> On Monday 02 May 2016 05:05:07 Tuukka Turunen wrote: > Hi Sean, > > Firstofall, I do apologize for the inconvenience caused by the CI system. We > are fully aware of the situation, and the effect is has for productivity. > All the developers of The Qt Company are using exactly the same CI system. Yes, that is a lot of people to be held up by an oft-times unreliable piece of infrastructure. > To address the problems, we had with Jenkins based CI we started to develop > new CI system built from the ground up to serve the needs of Qt. > Unfortunately, it has taken us longer than we anticipated to get the new CI > system stabile, and there are still a lot of failures caused by the CI > itself. We are also continuously improving the test asset to make it less > prone for errors, including identification of flaky cases and fixing and/or > temporarily blacklisting these. The flaky test related failure rate has indeed improved a great deal over the last 12 months. Thanks to all who have helped with this. The problems we're suffering now seem to be more related to infrastructure issues as Jędrek has pointed out. I think part of the problem is also perception. From outside of TQC, contributors have no visibility of the status of an integration beyond the gerrit "INTEGRATING" status. This turns it into a black box that can take most of a working day to result in a frustating failure. Would it be possible for you to expose the view of the currently running integrations and their status on each node/configuration so that we can see if something looks like it might be broken and can approach a sysadmin? > While we unfortunately do not have 24x7 sysadmins, And this is a problem imho. The CI is a critical system that needs to be running 24x7 to support people in different timezones and during out of hours work in Europe. If I'm busy with paying project work during office hours, then I try to do what I can on Qt 3D out of normal hours but several times I've had to waste hours at weekends and evenings trying to shepherd changes through. This in turn then just adds to the load on the CI system during office hours when the system is able to integrate once again. So in summary, I appreciate the CI is a big complex beast but it's also the gateway to getting contributions in and is therefore critical that it runs all of the time, or at least as much of the time as possible. Can you investigate the feasibility of putting 24x7 support in place please? > we do have persons > dedicated to operate the CI system, as well as support from IT as needed > for the infrastructure. In addition, we are still putting a significant > effort into developing the CI further and stabilizing it. And, yes, we are > also continuously monitoring the infrastructure of the CI systems as well > as planning how to improve it further in the future. Well, disks filling up over a weekend shows that it isn't monitored continuously, or rather, not acted upon. If there isn't 24x7 support then this is a valid outcome of course. My argument is that such support is warranted. Kind regards, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From sean.harmer at kdab.com Tue May 3 15:54:50 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 03 May 2016 14:54:50 +0100 Subject: [Development] Qt CI reliability In-Reply-To: <2683884.qFcU6NViYl@42> References: <4166383.CnvrWBLNsi@titan> <2683884.qFcU6NViYl@42> Message-ID: <1608400.q9XRjdceyM@cartman> On Monday 02 May 2016 11:14:24 Jędrzej Nowacki wrote: > On Saturday 30 of April 2016 20:26:20 Sean Harmer wrote: > > Hi, > > Hi, > > > after yet another 5 hour wait just to be greeted with yet another random > > failure with no build logs I'm getting really tired of the poor > > reliability > > of the Qt CI system. > > I'm sorry about that. > > > https://codereview.qt-project.org/#/c/157590/ > > > > has been greeted with genuine failures, failures in qtdeclarative, > > qtxmlpatterns, multiple random failures in qt3d despite being a simple > > change which I suspect are due to issues on one or more CI nodes. > > I scanned through the failures and it seems that you had a very bad luck. I > know CI should not be about luck and therefore I'm really sorry about that. No need for you to apologize personally, I'm complaining about the policy to not have 24x7 support. I don't blame any individual and I know it's still improving on the technical front. > > You tried to stage the change 7 times > 1. Failed to compile qt3d (broken change > https://codereview.qt-project.org/#/c/157593/) Yup, such changes are part of normal development, and are expected. These are not an issue as long as the CI fails in a timely manner. What would be a *very* useful feature would be if we can trigger a test build of a change on a particular configuration for such cases where we don't have ready access to a configuration locally. > 2. Looks like a network > connectivity failure, logs were not flushed as they should, so you can > blame CI > 3. Blame CI, we failed to acquire a free machine for 5h, I will look at that > later > 4. Failed to compile qt3d (broken change > https://codereview.qt-project.org/#/c/157590/) 5. Failed to compile qt3d > (broken change https://codereview.qt-project.org/#/c/157590/), same as 4 6. > Looks like a network connectivity failure, logs were not flushed as they > should, so you can blame CI, same as 2 Right, any time I find a link that points to nothing for the build logs I'm suspicious of the CI. > 7. Passed > > I will ask IT about network, it seems that network interface was > re-configured during CI run and DHCP assigned a different IP. It should not > happen (TM) Yes that sort of thing should be done in a specified window out of hours after disabling the CI master to be able to disseminate jobs to the nodes. > > Rule of thumb is: if logs show broken compilation it means: real problem, > don't blame CI. There are three main reasons, that I'm aware of, that can > cause the problem (sorted according to the probability): > 1. One of changes being integrated broke the compilation Fine and expected and, with timely failures, not an issue. > 2. One of module dependencies broke source compatibility This is very rarely an issue, at least for Qt 3D. > 3. There was a untested template update (this reason will almost disappear > soon) Do you mean VM template? If so then yes that's again something that should ideally be verified before deployment. The other factor that contributes is infrastructure: full disks, network outages, reconfigurations etc. These should be monitored for and acted upon and where possible, processes changed to avoid these situations. > *. There was huge radiation in Finland, but that you would know from the > news ;-) :) Anyway, thank you for looking into the issues here. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From Shawn.Rutledge at qt.io Tue May 3 16:19:00 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 3 May 2016 14:19:00 +0000 Subject: [Development] unique_ptr vs. QSharedPointer In-Reply-To: <201605031331.23150.marc.mutz@kdab.com> References: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> <201605031331.23150.marc.mutz@kdab.com> Message-ID: > On 3 May 2016, at 13:31, Marc Mutz wrote: > > On Tuesday 03 May 2016 13:14:05 Shawn Rutledge wrote: >> In what ways are they different? > > One implements unique ownership, isn't copyable, only movable, has almost zero > overhead (with a stateless deleter), and is standardised from C++11 on, the > other implements shared ownership, is copyable and movable, has the overhead > of a separate control block, and is Qt-specific. OK. But a function could return a unique_ptr, right? the caller of that function would then be restricted from doing anything that results in a copy? >> Is it OK to use unique_ptr in public API starting in 5.7? > > No. Because of the convention that we return only Qt data structures, never STL ones? or because we’re not sure if all compilers support unique_ptr? Or something else? From tim at klingt.org Tue May 3 16:33:46 2016 From: tim at klingt.org (Tim Blechmann) Date: Tue, 3 May 2016 16:33:46 +0200 Subject: [Development] [5.7-beta] compile error with xcode-6.4 Message-ID: compiling the 5.7-beta tarball with xcode-6.4 fails with: > In file included from /Users/tim/dev/qt3rd/qtbase/src/gui/image/qicon.cpp:1: > In file included from /Users/tim/dev/qt3rd/qtbase/src/gui/kernel/qt_gui_pch.h:69: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtGui/qbitmap.h:1: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtGui/../../src/gui/image/qbitmap.h:43: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtGui/qpixmap.h:1: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtGui/../../src/gui/image/qpixmap.h:47: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/qsharedpointer.h:1: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qsharedpointer.h:48: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/qsharedpointer_impl.h:1: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qsharedpointer_impl.h:65: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/qdebug.h:1: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/io/qdebug.h:51: > In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/qvector.h:1: > /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qvector.h:759:21: error: destination for this 'memmove' call is a pointer to class containing a dynamic class > 'QPixmap'; vtable pointer will be overwritten [-Werror,-Wdynamic-class-memaccess] > memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * sizeof(T)); > ~~~~~~~ ^ > /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qvector.h:450:3: note: in instantiation of member function 'QVector::erase' requested > here > erase(d->begin() + i, d->begin() + i + 1); } > ^ > /Users/tim/dev/qt3rd/qtbase/src/gui/image/qicon.cpp:288:25: note: in instantiation of member function 'QVector::remove' requested here > pixmaps.remove(idx); > ^ > /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qvector.h:759:21: note: explicitly cast the pointer to silence this warning > memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * sizeof(T)); > ^ > (void*) > 1 error generated. has support for xcode-6.4 been dropped? https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with xcode-6.1.1 thanks a lot, tim From olivier at woboq.com Tue May 3 17:00:15 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 03 May 2016 17:00:15 +0200 Subject: [Development] unique_ptr vs. QSharedPointer In-Reply-To: References: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> <201605031331.23150.marc.mutz@kdab.com> Message-ID: <3746238.WdN4Kr53IG@finn> Am Dienstag, 3. Mai 2016, 14:19:00 CEST schrieb Shawn Rutledge: > > On 3 May 2016, at 13:31, Marc Mutz wrote: > > > > On Tuesday 03 May 2016 13:14:05 Shawn Rutledge wrote: > > > >> In what ways are they different? > > > > > > One implements unique ownership, isn't copyable, only movable, has almost > > zero overhead (with a stateless deleter), and is standardised from > > C++11 on, the other implements shared ownership, is copyable and movable, > > has the overhead of a separate control block, and is Qt-specific. > > > OK. > > But a function could return a unique_ptr, right? the caller of that function > would thn be restricted from doing anything that results in a copy? Yes, because unique_ptr is movable. > >> Is it OK to use unique_ptr in public API starting in 5.7? > > > > > > No. > > > Because of the convention that we return only Qt data structures, never STL > ones? or because we’re not sure if all compilers support unique_ptr? Or > something else? Because of the convention that we do not want our ABI to depends on the STL's ABI. So we can't use standard container in the signature of exported functions. The closest we have to unique_ptr in Qt is QScopedPointer. With the difference that QScopedPointer is not movable. Personally, i think we should add a move constructor to QScopedPointer, but this has already been discussed there and the concensus was against it: http://lists.qt-project.org/pipermail/development/2013-September/012882.html Either we should reopen the discussion or create a QUniquePointer. (Or we should allow std types in our ABI) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From jedrzej.nowacki at qt.io Tue May 3 17:36:49 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 3 May 2016 17:36:49 +0200 Subject: [Development] Qt CI reliability In-Reply-To: <1608400.q9XRjdceyM@cartman> References: <4166383.CnvrWBLNsi@titan> <2683884.qFcU6NViYl@42> <1608400.q9XRjdceyM@cartman> Message-ID: <6885742.Lm1y6c2V3b@42> On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote: > On Monday 02 May 2016 11:14:24 Jędrzej Nowacki wrote: > > On Saturday 30 of April 2016 20:26:20 Sean Harmer wrote: > (...) > What would be a *very* useful feature would be if we can trigger a test > build of a change on a particular configuration for such cases where we > don't have ready access to a configuration locally. We have this feature, but it is not exposed. Qt account integration is missing as well as some kind of limitation to protect CI resources. If you have a really urgent thing to test ping me on IRC. I can run a test run for you. > > I will ask IT about network, it seems that network interface was > > re-configured during CI run and DHCP assigned a different IP. It should > > not > > happen (TM) > > Yes that sort of thing should be done in a specified window out of hours > after disabling the CI master to be able to disseminate jobs to the nodes. Well it was not about maintenance. A node tried to re-new it's IP lease and it got a new IP instead of an old one. It may be some kind of DHCP miss- configuration or operating system failed to ask in time to re-new the IP lease. I do not know, how on earth this could happen. I need to access logs. > > Rule of thumb is: if logs show broken compilation it means: real problem, > > don't blame CI. There are three main reasons, that I'm aware of, that can > > cause the problem (sorted according to the probability): > > 1. One of changes being integrated broke the compilation > > Fine and expected and, with timely failures, not an issue. > > > 2. One of module dependencies broke source compatibility > > This is very rarely an issue, at least for Qt 3D. > > > 3. There was a untested template update (this reason will almost disappear > > soon) > > Do you mean VM template? If so then yes that's again something that should > ideally be verified before deployment. Eh, wrong phrasing. Templates are tested. The problem is that the current process is a bit racy. Updating template is a work that require time, especially for testing and deployment. Regressions may appear during that time window. Anyway the process is about to be changed soon. Cheers, Jędrek From edward.welbourne at qt.io Tue May 3 18:24:32 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 3 May 2016 16:24:32 +0000 Subject: [Development] Header review for 5.7 (vs 5.6) Message-ID: Hi all, As we approach the release of 5.7.0, we naturally need to review the changes to APIs for all the usual things. This time, however, we decided [0] it would be nice to actually make use of Gerrit's ability to display changes nicely, rather than [1] displaying a diff as if it were an enormous file to be added to a module. While we were at it, we decided [2] to filter out, as well as the copyright header changes our old script discarded, various rather boring changes, such as just adding a Q_ALWAYS_INLINE, Q_DECL_NOTHROW or Q_CONSTEXPR to a declaration. [0] https://bugreports.qt.io/browse/QTQAINFRA-973 [1] https://codereview.qt-project.org/#/c/153346/ [2] https://codereview.qt-project.org/155745 Consequently, to take the example of qtbase, instead of looking at more than 100 k lines with no colouring mark-up to help you see what's really changed, reviewers only need to look at a little under 8 k lines, split up nicely by which file they're in and actually making good use of Gerrit's ability to display diffs nicely. Just be sure you don't do anything silly like telling Gerrit to merge these commits :-) The scripts to do this are still a bit fresh (I was fixing bugs in them on Friday and still testing yesterday) and anyone nervous of whether they might be mistaking meaninful changes for boring is welcome to take a look [3] (and let me know so I can fix that). If you actually want to run this at home, you'll need python's dulwich package installed, for the git magic it does. [3] https://codereview.qt-project.org/157299 Yesterday's header diffs are all listed in [4], but I'll list them here, too, for the convenience of those whose mailers understand links: * https://codereview.qt-project.org/157805 – qtbase * https://codereview.qt-project.org/157789 – qtdeclarative * https://codereview.qt-project.org/157790 – qtactiveqt * https://codereview.qt-project.org/157791 – qtmultimedia * https://codereview.qt-project.org/157792 – qttools * https://codereview.qt-project.org/157793 – qtlocation * https://codereview.qt-project.org/157795 – qtconnectivity * https://codereview.qt-project.org/157796 – qtwayland * https://codereview.qt-project.org/157797 – qt3d * https://codereview.qt-project.org/157798 – qtquickcontrols * https://codereview.qt-project.org/157799 – qtserialport * https://codereview.qt-project.org/157800 – qtx11extras * https://codereview.qt-project.org/157801 – qtandroidextras * https://codereview.qt-project.org/157802 – qtwebsockets * https://codereview.qt-project.org/157803 – qtwebengine * https://codereview.qt-project.org/157804 – qtcanvas3d [4] https://bugreports.qt.io/browse/QTQAINFRA-973#comment-318470 Please take a look at the modules you care about and point out anything that's going to cause problems for the usual compatibility constraints, Eddy. From aclight at gmail.com Tue May 3 18:42:53 2016 From: aclight at gmail.com (Adam Light) Date: Tue, 3 May 2016 09:42:53 -0700 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <201603220030.11770.kde@carewolf.com> References: <1466246.T2YiNlAlqL@portia.local> <201603211720.54287.kde@carewolf.com> <1989174.lC5d7xj5v5@portia.local> <201603220030.11770.kde@carewolf.com> Message-ID: On Mon, Mar 21, 2016 at 4:30 PM, Allan Sandfeld Jensen wrote: > On Monday 21 March 2016, René J. V. Bertin wrote: > > > For further comparison, here's a screenshot showing > > > > > > CoreText vs Cocoa+Freetype vs XCB+Freetype+Fontconfig > > > > > > all on OS X, using a theme & style based on QtCurve. > > > > > > The XCB+Freetype rendering is hands-down the easiest on the eyes for me, > > > though that's of course all in the eye of the beholder. It'd be nice if > > > the same quality could be attained with the Cocoa QPA. > > > > > > I'd be interested in testing different ways to get the text colour right > > > (backported to 5.6 though ;)). > > > > > I would suggest trying to change QCocoaIntegration::styleHint > > and return 1.0 for QPlatformIntegration::FontSmoothingGamma instead of > 2.0. > > > I've found that using the freetype font engine dramatically improves performance in parts of our application that do a lot of text rendering. Is there any way to set this style hint without actually modifying the QCocoaIntegration source code and rebuilding Qt? We'd like to be able to give users of our application the ability to play around with these settings some. Thanks Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue May 3 18:48:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 03 May 2016 09:48:12 -0700 Subject: [Development] [5.7-beta] compile error with xcode-6.4 In-Reply-To: References: Message-ID: <2488991.aBlt9xUcar@tjmaciei-mobl4> Em terça-feira, 3 de maio de 2016, às 16:33:46 PDT, Tim Blechmann escreveu: > compiling the 5.7-beta tarball with xcode-6.4 fails with: > > r.h:759:21: error: destination for this 'memmove' call is a pointer to > > class containing a dynamic class> > > 'QPixmap'; vtable pointer will be overwritten > > [-Werror,-Wdynamic-class-memaccess]> > > memmove(abegin, aend, (d->size - itemsToErase - > > itemsUntouched) * sizeof(T)); ~~~~~~~ ^ > has support for xcode-6.4 been dropped? Not officially. You should always use the latest XCode, no matter what, though. > https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with > xcode-6.1.1 Indeed, but we're changing policies. Users are expected to use the latest and greatest OS X and XCode, since they're now free for upgrading. I'm not sure whether this applies to 5.7 or not. Still, note that this is not an error. It's a warning turned to error because of the -Werror, which means that you used -developer-build. In that case, please send a patch. :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 3 18:57:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 03 May 2016 09:57:16 -0700 Subject: [Development] unique_ptr vs. QSharedPointer In-Reply-To: <3746238.WdN4Kr53IG@finn> References: <5A10D83E-432C-45B0-AD28-E1598CE459F9@qt.io> <3746238.WdN4Kr53IG@finn> Message-ID: <1645124.fhGRlVrE4e@tjmaciei-mobl4> Em terça-feira, 3 de maio de 2016, às 17:00:15 PDT, Olivier Goffart escreveu: > Because of the convention that we do not want our ABI to depends on the > STL's ABI. So we can't use standard container in the signature of > exported functions. Which has saved our hides twice in the past few years already. Once with Apple's switch to libc++ and more recently with GCC/libstdc++'s breaking of the std::string ABI. > The closest we have to unique_ptr in Qt is QScopedPointer. > With the difference that QScopedPointer is not movable. > Personally, i think we should add a move constructor to QScopedPointer, but > this has already been discussed there and the concensus was against it: > http://lists.qt-project.org/pipermail/development/2013-September/012882.htm > l Either we should reopen the discussion or create a QUniquePointer. (Or we > should allow std types in our ABI) The problem with using the C++11 features of the Standard Library is detecting what is supported. There is no monotonically-increasing version number for some of the implementations (read: libstdc++), so we don't know which one we may be compiling against. For example, GCC achieved full C++11 *language* support in version 4.8.1, but the Standard Library support lagged behind and *still* is incomplete in some areas: https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html Compare with: https://gcc.gnu.org/onlinedocs/gcc-4.8.5/libstdc++/manual/manual/ status.html#manual.intro.status.iso And that's not even bringing Android and QNX into the mix, which replace the GPLv3-licensed libstdc++ with a more permissively-licensed implementation (Dinkumware, Apache STLport, libc++). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 3 18:59:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 03 May 2016 09:59:29 -0700 Subject: [Development] Header review for 5.7 (vs 5.6) In-Reply-To: References: Message-ID: <1632302.Gevhgv9Fpo@tjmaciei-mobl4> Em terça-feira, 3 de maio de 2016, às 16:24:32 PDT, Edward Welbourne escreveu: > Consequently, to take the example of qtbase, instead of looking at more > than 100 k lines with no colouring mark-up to help you see what's really > changed, reviewers only need to look at a little under 8 k lines, split > up nicely by which file they're in and actually making good use of > Gerrit's ability to display diffs nicely. Just be sure you don't do > anything silly like telling Gerrit to merge these commits Thanks Eddy and everyone else who took the header diff to the next step! BTW, I just checked and saw that the ABI report by Andrey was updated with 5.7 beta: http://abi-laboratory.pro/tracker/timeline/qt/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From porten at froglogic.com Tue May 3 19:01:30 2016 From: porten at froglogic.com (Harri Porten) Date: Tue, 3 May 2016 19:01:30 +0200 (CEST) Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: <2488991.aBlt9xUcar@tjmaciei-mobl4> References: <2488991.aBlt9xUcar@tjmaciei-mobl4> Message-ID: I got reminded of something: On Tue, 3 May 2016, Thiago Macieira wrote: > Still, note that this is not an error. It's a warning turned to error because > of the -Werror, which means that you used -developer-build. In that case, > please send a patch. :-) I've seen my Qt users use -developer-build because http://wiki.qt.io/Building_Qt_5_from_Git proposes it and the impact not clear to everyone. Qt users naturally consider themselves to be developers :) The negative impact I have seen: the lack of a following "make install" leads to a different layout of the files on disk. Still, companies are sharing such builds within their team and develop their application against it. If noone minds I'll make the wording more precise. Harri. From thiago.macieira at intel.com Tue May 3 19:08:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 03 May 2016 10:08:09 -0700 Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: References: <2488991.aBlt9xUcar@tjmaciei-mobl4> Message-ID: <1577846.z2UKTiSPYj@tjmaciei-mobl4> Em terça-feira, 3 de maio de 2016, às 19:01:30 PDT, Harri Porten escreveu: > I've seen my Qt users use -developer-build because > > http://wiki.qt.io/Building_Qt_5_from_Git > > proposes it and the impact not clear to everyone. Qt users naturally > consider themselves to be developers I've seen people on IRC come with those errors and I've asked them to update the wiki page they found the instructions in to remove the -developer-build option. Either they've never done it or the option came back. > The negative impact I have seen: the lack of a following "make install" > leads to a different layout of the files on disk. Still, companies are > sharing such builds within their team and develop their application > against it. That implies adding a -prefix option to configure. > If noone minds I'll make the wording more precise. Thanks, that would be most welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Tue May 3 22:09:43 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 3 May 2016 20:09:43 +0000 Subject: [Development] Qt CI reliability In-Reply-To: <1866299.C2IvjzggEe@cartman> References: <4166383.CnvrWBLNsi@titan> <1866299.C2IvjzggEe@cartman> Message-ID: > -----Original Message----- > From: sean.harmer On Behalf Of Sean Harmer > Sent: tiistaina 3. toukokuuta 2016 15.45 > To: development at qt-project.org > Cc: Tuukka Turunen > Subject: Re: [Development] Qt CI reliability > > > So in summary, I appreciate the CI is a big complex beast but it's also the > gateway to getting contributions in and is therefore critical that it runs all of > the time, or at least as much of the time as possible. Can you investigate the > feasibility of putting 24x7 support in place please? > Yes, we can investigate this. But it may not be feasible - at least the level of support that can be available outside developer's office hours would most likely be just basic infrastructure support. It should be noted that we have been (and partially still are) in the process of being separated from the Digia group. While the CI part was mainly done months ago, there is overall a lot of issues ongoing that stretch the capabilities of IT personnel. That is of course no excuse as such, but an item to note anyways. > > we do have persons > > dedicated to operate the CI system, as well as support from IT as > > needed for the infrastructure. In addition, we are still putting a > > significant effort into developing the CI further and stabilizing it. > > And, yes, we are also continuously monitoring the infrastructure of > > the CI systems as well as planning how to improve it further in the future. > > Well, disks filling up over a weekend shows that it isn't monitored > continuously, or rather, not acted upon. If there isn't 24x7 support then this > is a valid outcome of course. My argument is that such support is warranted. > Or at least we should make sure disks that are not automatically cleaned, are cleaned in advance during the office hours. I do agree with you that running out of a disk space should not be a reason for CI failure - and mostly it has not been, despite you hitting that over the weekend. Yours, Tuukka From Jake.Petroules at qt.io Wed May 4 05:27:51 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 4 May 2016 03:27:51 +0000 Subject: [Development] [5.7-beta] compile error with xcode-6.4 In-Reply-To: <2488991.aBlt9xUcar@tjmaciei-mobl4> References: <2488991.aBlt9xUcar@tjmaciei-mobl4> Message-ID: On May 3, 2016, at 9:48 AM, Thiago Macieira > wrote: Em terça-feira, 3 de maio de 2016, às 16:33:46 PDT, Tim Blechmann escreveu: compiling the 5.7-beta tarball with xcode-6.4 fails with: r.h:759:21: error: destination for this 'memmove' call is a pointer to class containing a dynamic class> 'QPixmap'; vtable pointer will be overwritten [-Werror,-Wdynamic-class-memaccess]> memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * sizeof(T)); ~~~~~~~ ^ has support for xcode-6.4 been dropped? Not officially. You should always use the latest XCode, no matter what, though. Not yet but it will be at some point. https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with xcode-6.1.1 Indeed, but we're changing policies. Users are expected to use the latest and greatest OS X and XCode, since they're now free for upgrading. I'm not sure whether this applies to 5.7 or not. Not 5.7 yet. We haven't started ripping out any of the SDK conditions, and can't until https://codereview.qt-project.org/#/c/151146/ is merged, which is blocked by CI capability limitations at the moment. /me pokes CI team again :) Still, note that this is not an error. It's a warning turned to error because of the -Werror, which means that you used -developer-build. In that case, please send a patch. :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at klingt.org Wed May 4 07:55:21 2016 From: tim at klingt.org (Tim Blechmann) Date: Wed, 4 May 2016 07:55:21 +0200 Subject: [Development] [5.7-beta] compile error with xcode-6.4 In-Reply-To: <2488991.aBlt9xUcar@tjmaciei-mobl4> References: <2488991.aBlt9xUcar@tjmaciei-mobl4> Message-ID: >>> r.h:759:21: error: destination for this 'memmove' call is a pointer to >>> class containing a dynamic class> >>> 'QPixmap'; vtable pointer will be overwritten >>> [-Werror,-Wdynamic-class-memaccess]> >>> memmove(abegin, aend, (d->size - itemsToErase - >>> itemsUntouched) * sizeof(T)); ~~~~~~~ ^ > >> has support for xcode-6.4 been dropped? > > Not officially. You should always use the latest XCode, no matter what, though. > >> https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with >> xcode-6.1.1 > > Indeed, but we're changing policies. Users are expected to use the latest and > greatest OS X and XCode, since they're now free for upgrading. I'm not sure > whether this applies to 5.7 or not. pricing should not be the only point to consider: requiring latest xcode versions implies requiring the latest sdk. requiring the latest sdk means that: * legacy code using deprecated sdk functions might not compile a certain codebase (depending on the age of your codebase this maybe lead to significant effort) * compiling with a minimum osx version X of sdk version Y is different than compiling against minimum osx version X of sdk version X. there are subtle differences and this should not be the case if the code were bug-free ... but we've experienced (toolchain) bugs in the past were the only workaround was to downgrade the osx sdk, which implies downgrading the compiler. end-users won't care if a crash is caused by a bug in application code or in qt or in the apple toolchain. they will blame the application. ... but we had this discussion already in the past :) cheers, tim From alexander.blasche at qt.io Wed May 4 08:07:31 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 4 May 2016 06:07:31 +0000 Subject: [Development] Header review for 5.7 (vs 5.6) In-Reply-To: <1632302.Gevhgv9Fpo@tjmaciei-mobl4> References: <1632302.Gevhgv9Fpo@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Thiago Macieira > Sent: Tuesday, 3 May 2016 18:59 > To: development at qt-project.org > Subject: Re: [Development] Header review for 5.7 (vs 5.6) > > Em terça-feira, 3 de maio de 2016, às 16:24:32 PDT, Edward Welbourne escreveu: > > Consequently, to take the example of qtbase, instead of looking at more > > than 100 k lines with no colouring mark-up to help you see what's really > > changed, reviewers only need to look at a little under 8 k lines, split > > up nicely by which file they're in and actually making good use of > > Gerrit's ability to display diffs nicely. Just be sure you don't do > > anything silly like telling Gerrit to merge these commits > > Thanks Eddy and everyone else who took the header diff to the next step! > > BTW, I just checked and saw that the ABI report by Andrey was updated with 5.7 > beta: > http://abi-laboratory.pro/tracker/timeline/qt/ Indeed thank you very very much. This is not an urgent request but latest 5.8 please add coverage for the following git repos: qtandroidextra, qtserialbus, qtsensors, Thank you. -- Alex From Shawn.Rutledge at qt.io Wed May 4 08:23:29 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 4 May 2016 06:23:29 +0000 Subject: [Development] Header review for 5.7 (vs 5.6) In-Reply-To: References: Message-ID: Thanks, it does indeed seem to be quite an improvement. From Jake.Petroules at qt.io Wed May 4 08:31:11 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 4 May 2016 06:31:11 +0000 Subject: [Development] [5.7-beta] compile error with xcode-6.4 In-Reply-To: References: <2488991.aBlt9xUcar@tjmaciei-mobl4> Message-ID: <48D8AB01-A3A9-4575-9F9E-B0D810EB6A2D@qt.io> On May 3, 2016, at 10:55 PM, Tim Blechmann > wrote: r.h:759:21: error: destination for this 'memmove' call is a pointer to class containing a dynamic class> 'QPixmap'; vtable pointer will be overwritten [-Werror,-Wdynamic-class-memaccess]> memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * sizeof(T)); ~~~~~~~ ^ has support for xcode-6.4 been dropped? Not officially. You should always use the latest XCode, no matter what, though. https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with xcode-6.1.1 Indeed, but we're changing policies. Users are expected to use the latest and greatest OS X and XCode, since they're now free for upgrading. I'm not sure whether this applies to 5.7 or not. pricing should not be the only point to consider: requiring latest xcode versions implies requiring the latest sdk. requiring the latest sdk means that: Technically you can copy a newer SDK into an older Xcode version (provided the toolchain supports it). * legacy code using deprecated sdk functions might not compile a certain codebase (depending on the age of your codebase this maybe lead to significant effort) As I've said many times before, the SDK we use to build Qt has no bearing on the SDK you use to build your applications. We can build with the 10.11 SDK, you can build with the 10.8 SDK, and that's completely fine. * compiling with a minimum osx version X of sdk version Y is different than compiling against minimum osx version X of sdk version X. there are subtle differences ...which is exactly why we want to support M+N configuration instead of M*N configurations. and this should not be the case if the code were bug-free ... but we've experienced (toolchain) bugs in the past were the only workaround was to downgrade the osx sdk, which implies downgrading the compiler. end-users won't care if a crash is caused by a bug in application code or in qt or in the apple toolchain. they will blame the application. Rightly so, because in those rare cases it'll always be a bug in your application and not in Qt. See above. And before you say it's more difficult to build Qt on one platform and your applications on another, (a) how often do you actually need to build Qt?, and (b) it is not in our interests to spend the significant effort to test and support 16 (vs 4) different configurations that are unnecessary for 99.9% of users in 99.9% of cases. ... but we had this discussion already in the past :) cheers, tim _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed May 4 09:18:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 04 May 2016 00:18:36 -0700 Subject: [Development] [5.7-beta] compile error with xcode-6.4 In-Reply-To: References: <2488991.aBlt9xUcar@tjmaciei-mobl4> Message-ID: <5218066.RO354WEBai@tjmaciei-mobl4> On quarta-feira, 4 de maio de 2016 07:55:21 PDT Tim Blechmann wrote: > * legacy code using deprecated sdk functions might not compile a certain > codebase (depending on the age of your codebase this maybe lead to > significant effort) Is that because of bugs you talked about below, or is there another reason why this would happen? Why would it not compile? > > * compiling with a minimum osx version X of sdk version Y is different > than compiling against minimum osx version X of sdk version X. there are > subtle differences and this should not be the case if the code were > bug-free ... but we've experienced (toolchain) bugs in the past were the > only workaround was to downgrade the osx sdk, which implies downgrading > the compiler. end-users won't care if a crash is caused by a bug in > application code or in qt or in the apple toolchain. they will blame the > application. > > ... but we had this discussion already in the past I don't remember seeing those arguments. They are actually quite important and should change the conclusion. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mark.dewit at iesve.com Wed May 4 09:46:41 2016 From: mark.dewit at iesve.com (Mark De Wit) Date: Wed, 4 May 2016 07:46:41 +0000 Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: <1577846.z2UKTiSPYj@tjmaciei-mobl4> References: <2488991.aBlt9xUcar@tjmaciei-mobl4> <1577846.z2UKTiSPYj@tjmaciei-mobl4> Message-ID: <3709A7D425EE8C45991DB29EC2FACA8827414CCE@GL-EXC-01.iesve.com> Having tried to do this myself last week, I cannot find any "official" documentation on how to build Qt myself for an official release with our software. Doing our own build has proven frustrating enough that we abandoned the current attempt to update our version of Qt. The configure flags are poorly documented, and options like qtlibinfix (which I understood to be a recommended best practice) isn't even mentioned on the configure flag page. Kind regards, Mark -----Original Message----- From: Development [mailto:development-bounces+mark.dewit=iesve.com at qt-project.org] On Behalf Of Thiago Macieira Sent: 03 May 2016 18:09 To: development at qt-project.org Subject: Re: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 Em terça-feira, 3 de maio de 2016, às 19:01:30 PDT, Harri Porten escreveu: > I've seen my Qt users use -developer-build because > > http://wiki.qt.io/Building_Qt_5_from_Git > > proposes it and the impact not clear to everyone. Qt users naturally > consider themselves to be developers I've seen people on IRC come with those errors and I've asked them to update the wiki page they found the instructions in to remove the -developer-build option. Either they've never done it or the option came back. > The negative impact I have seen: the lack of a following "make install" > leads to a different layout of the files on disk. Still, companies are > sharing such builds within their team and develop their application > against it. That implies adding a -prefix option to configure. > If noone minds I'll make the wording more precise. Thanks, that would be most welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at qt.io Wed May 4 11:39:04 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Wed, 4 May 2016 09:39:04 +0000 Subject: [Development] Scope of source code license files In-Reply-To: References: Message-ID: <2292E19B-3536-487A-AC63-FC8C3FE1031B@qt.io> On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" wrote: >Hello, > >The LICENSE.GPLvX and LICENSE.LGPLvX files from >http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with >"The Qt Toolkit is Copyright (C) 2015...", but then they go on to say >"You may use, distribute and copy the Qt GUI Toolkit under the terms >of..." > >Is this correct? What about non-GUI parts of the toolkit? The GUI in here is just a historical thing. It applies to Qt. Cheers, Lars From tim at klingt.org Wed May 4 12:24:05 2016 From: tim at klingt.org (Tim Blechmann) Date: Wed, 4 May 2016 12:24:05 +0200 Subject: [Development] [5.7-beta] compile error with xcode-6.4 In-Reply-To: <5218066.RO354WEBai@tjmaciei-mobl4> References: <2488991.aBlt9xUcar@tjmaciei-mobl4> <5218066.RO354WEBai@tjmaciei-mobl4> Message-ID: >> * legacy code using deprecated sdk functions might not compile a certain >> codebase (depending on the age of your codebase this maybe lead to >> significant effort) > > Is that because of bugs you talked about below, or is there another reason why > this would happen? Why would it not compile? sometimes the declarations are removed from the sdk, but not from the binaries, so old binaries still run, but code won't compile anymore. at one point these methods will be removed from the binaries, but only apple knows, when ... eventually this code has to be ported to a new API, but depending on the effort it will be done sooner or later or never (and the product dies) >> * compiling with a minimum osx version X of sdk version Y is different >> than compiling against minimum osx version X of sdk version X. there are >> subtle differences and this should not be the case if the code were >> bug-free ... but we've experienced (toolchain) bugs in the past were the >> only workaround was to downgrade the osx sdk, which implies downgrading >> the compiler. end-users won't care if a crash is caused by a bug in >> application code or in qt or in the apple toolchain. they will blame the >> application. >> >> ... but we had this discussion already in the past > > I don't remember seeing those arguments. They are actually quite important and > should change the conclusion. http://article.gmane.org/gmane.comp.lib.qt.devel/24824 real-world problem in the past: * host application compiled against 10.8 sdk * loads a plugin compiled against 10.9 or 10.10 sdk, compiled with 10.8 as minimum osx requirement * running on 10.8 if the plugin throws a std::exception the plugin could not catch it (no code of the host is involved). apple acknowledge the bug, but didn't fix it. we had to stick with the 10.8 sdk until dropping support for 10.8. -- i completely agree, that one should try to use the most recent compiler or sdk when possible. but it should not be a hard requirement imposed by a general purpose framework like qt ... cheers, tim From thiago.macieira at intel.com Wed May 4 18:42:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 04 May 2016 09:42:25 -0700 Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827414CCE@GL-EXC-01.iesve.com> References: <1577846.z2UKTiSPYj@tjmaciei-mobl4> <3709A7D425EE8C45991DB29EC2FACA8827414CCE@GL-EXC-01.iesve.com> Message-ID: <16262655.LcZiHKsi4R@tjmaciei-mobl4> On quarta-feira, 4 de maio de 2016 07:46:41 PDT Mark De Wit wrote: > The configure flags are poorly documented, and options like qtlibinfix > (which I understood to be a recommended best practice) isn't even mentioned > on the configure flag page. Because it isn't a recommended best practice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mark.dewit at iesve.com Wed May 4 19:10:30 2016 From: mark.dewit at iesve.com (Mark De Wit) Date: Wed, 4 May 2016 17:10:30 +0000 Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: <16262655.LcZiHKsi4R@tjmaciei-mobl4> References: <1577846.z2UKTiSPYj@tjmaciei-mobl4> <3709A7D425EE8C45991DB29EC2FACA8827414CCE@GL-EXC-01.iesve.com> <16262655.LcZiHKsi4R@tjmaciei-mobl4> Message-ID: <3709A7D425EE8C45991DB29EC2FACA8827414EC3@GL-EXC-01.iesve.com> Hmm, is that proving my point, though? My understanding was that compiling Qt in a namespace and with unique filename was recommended to avoid (minimise) the likelihood of conflicting Qt versions in a single process. Is there documentation that states how one should build Qt for release with their own software? The trial & error approaches I have witnessed in the past have not been a positive experience. Mark -----Original Message----- From: Development [mailto:development-bounces+mark.dewit=iesve.com at qt-project.org] On Behalf Of Thiago Macieira Sent: 04 May 2016 17:43 To: development at qt-project.org Subject: Re: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 On quarta-feira, 4 de maio de 2016 07:46:41 PDT Mark De Wit wrote: > The configure flags are poorly documented, and options like qtlibinfix > (which I understood to be a recommended best practice) isn't even mentioned > on the configure flag page. Because it isn't a recommended best practice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed May 4 20:11:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 04 May 2016 11:11:17 -0700 Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827414EC3@GL-EXC-01.iesve.com> References: <16262655.LcZiHKsi4R@tjmaciei-mobl4> <3709A7D425EE8C45991DB29EC2FACA8827414EC3@GL-EXC-01.iesve.com> Message-ID: <2053576.pZlpzoUYD0@tjmaciei-mobl4> On quarta-feira, 4 de maio de 2016 17:10:30 PDT Mark De Wit wrote: > Hmm, is that proving my point, though? My understanding was that compiling > Qt in a namespace and with unique filename was recommended to avoid > (minimise) the likelihood of conflicting Qt versions in a single process. That is true, but why are you worried about this in the first place? Are you loading random plugins from other sources that may or may not be linked to Qt? If so, that's not a common use-case (hence no BKM for this). The only case that may be relevant is to deal with plugins installed by the system Linux distribution. But Qt should refuse to load plugins linked to newer versions of itself, not to mention that this is now enforced by the dynamic linker itself since Qt 5.6. In any case, the situation is often reversed, as user applications often come with Qt versions newer than the system installation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sschilz at pasco.com Wed May 4 22:09:03 2016 From: sschilz at pasco.com (Steve Schilz) Date: Wed, 4 May 2016 20:09:03 +0000 Subject: [Development] Documentation for QPagedPrintDevice::setPageSize should specify a unit Message-ID: <8F08EDA0-EE09-406D-9EDB-B3E84063871B@pasco.com> Hi, I would like to suggest a small update to the documentation for QPagedPaintDevice::setPageSize(const QPageSize &pageSize) See https://doc-snapshots.qt.io/qt5-5.7/qpagedpaintdevice.html#setPageSize i The doc is confusing because it does not specify a unit for the input parameter “pageSize" According to http://www.qtcentre.org/threads/24684-what-unit-is-used-in-QTextDocument-setPageSize()-method the page size is given in QPageSize::Point. This agrees with my testing. Thanks Steve Schilz -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangelog at gmail.com Wed May 4 23:17:09 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 4 May 2016 23:17:09 +0200 Subject: [Development] Documentation for QPagedPrintDevice::setPageSize should specify a unit In-Reply-To: <8F08EDA0-EE09-406D-9EDB-B3E84063871B@pasco.com> References: <8F08EDA0-EE09-406D-9EDB-B3E84063871B@pasco.com> Message-ID: Hi, On Wed, May 4, 2016 at 10:09 PM, Steve Schilz wrote: > The doc is confusing because it does not specify a unit for the input > parameter “pageSize" The parameter is of type QPageSize, which has multiple setters and constructors. Which one(s) is missing the unit specification? Thanks, -- Giuseppe D'Angelo From sschilz at pasco.com Thu May 5 01:25:11 2016 From: sschilz at pasco.com (Steve Schilz) Date: Wed, 4 May 2016 23:25:11 +0000 Subject: [Development] Documentation for QPagedPrintDevice::setPageSize should specify a unit` Message-ID: <57B43E05-46FB-40A3-8B58-E5D1EF5CA050@pasco.com> Oops, I ment QTextDocument::setPageSize (http://doc.qt.io/qt-5/qtextdocument.html#pageSize-prop) Does that make more sense? Steve Schilz PASCO scientific - think science On 5/4/16, 2:17 PM, "Giuseppe D'Angelo" wrote: >Hi, > >On Wed, May 4, 2016 at 10:09 PM, Steve Schilz wrote: >> The doc is confusing because it does not specify a unit for the input >> parameter “pageSize" > >The parameter is of type QPageSize, which has multiple setters and >constructors. Which one(s) is missing the unit specification? > >Thanks, >-- >Giuseppe D'Angelo From matnares at gmail.com Thu May 5 08:34:46 2016 From: matnares at gmail.com (=?UTF-8?B?TWF0w61hcyBOw6lzdG9yIEFyZXM=?=) Date: Thu, 5 May 2016 03:34:46 -0300 Subject: [Development] Bluetooth Services problem Message-ID: Hi Everybody!! I'm having an issue with bluetooth on QML on android Qt 5.6.0 I can't even fully test the example: http://doc.qt.io/qt-5/qtbluetooth-scanner-example.html trying to access service inside onServiceDiscovered: it gets undefined. as documentation says : *serviceDiscovered(BluetoothService service) * serviceDiscovered parameter is "service" but it is undefined... is it a bug? is there some workaround? Thanks in advance. Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Thu May 5 12:15:38 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 05 May 2016 11:15:38 +0100 Subject: [Development] Qt CI reliability In-Reply-To: <6885742.Lm1y6c2V3b@42> References: <4166383.CnvrWBLNsi@titan> <1608400.q9XRjdceyM@cartman> <6885742.Lm1y6c2V3b@42> Message-ID: <2760300.rZfUxo7XgH@cartman> On Tuesday 03 May 2016 17:36:49 Jędrzej Nowacki wrote: > On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote: > > Do you mean VM template? If so then yes that's again something that should > > ideally be verified before deployment. > > Eh, wrong phrasing. Templates are tested. The problem is that the current > process is a bit racy. Updating template is a work that require time, > especially for testing and deployment. Regressions may appear during that > time window. Anyway the process is about to be changed soon. Here's another new failure mode: http://testresults.qt.io/logs/qt/qtbase/3356adaae5186a77c2aec458e2a1ebd3e40db8ab/LinuxUbuntu_14_04x86_64LinuxUbuntu_14_04x86_64GCCDeveloperBuild_OutOfSourceBuild_QtLibInfix_QtNamespace/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz Failing with: Determining architecture... () make: Warning: File `../../../qt/qtbase/config.tests/arch/arch.pro' has modification time 1.3e+03 s in the future /home/qt/work/build/bin/qmake -qtconf /home/qt/work/build/bin/qt.conf -nocache -spec /home/qt/work/qt/qtbase/mkspecs/linux-g++ LIBS+= QMAKE_CXXFLAGS+= INCLUDEPATH+= CONFIG-=app_bundle -o Makefile ../../../qt/qtbase/config.tests/arch/arch.pro ... agent:2016/05/05 13:07:20 build.go:221: Killed process after timeout (total time) agent:2016/05/05 13:07:20 agent.go:170: Build failed agent:2016/05/05 13:07:20 agent.go:127: ERROR building: Timeout after 5m0s: Maximum duration reached agent:2016/05/05 13:07:20 build.go:158: Error reading from stdout/err: Timeout after 5m0s: Maximum duration reached Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From apoenitz at t-online.de Thu May 5 12:40:20 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 5 May 2016 12:40:20 +0200 Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827414CCE@GL-EXC-01.iesve.com> References: <2488991.aBlt9xUcar@tjmaciei-mobl4> <1577846.z2UKTiSPYj@tjmaciei-mobl4> <3709A7D425EE8C45991DB29EC2FACA8827414CCE@GL-EXC-01.iesve.com> Message-ID: <20160505104020.GA11601@klara.mpi.htwm.de> On Wed, May 04, 2016 at 07:46:41AM +0000, Mark De Wit wrote: > Having tried to do this myself last week, I cannot find any "official" documentation > on how to build Qt myself for an official release with our software. Doing our own > build has proven frustrating enough that we abandoned the current attempt to update > our version of Qt. > > The configure flags are poorly documented, and options like qtlibinfix (which I > understood to be a recommended best practice) isn't even mentioned on the configure > flag page. .../qt-5/qtbase$ ./configure --help | grep libinfix -qtlibinfix Renames all libQt*.so to libQt*.so. Andre' From tim at klingt.org Thu May 5 13:39:59 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 5 May 2016 13:39:59 +0200 Subject: [Development] [5.7-beta] qtgamepad compile failure Message-ID: compiling the qt-5.7-beta tarball with msvc2013/64bit/static libraries, out-of-tree build gives me: --- cl -c -FIQtGamepadDepends -YuQtGamepadDepends -Fp.pch\debug\Qt5Gamepadd_pch.pch -nologo -Zc:wchar_t -FS -Zi -MDd -D_HAS_EXCEPTIONS=0 -GR -W3 -w34100 -w34189 -w44996 /Fd..\..\lib\Qt5Gamepadd.pdb -DUNICODE -DWIN32 -DWIN64 -DQT_BUILD_GAMEPAD_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_BUILD_GAMEPAD_LIB -DQT_NO_EXCEPTIONS -DQT_GUI_LIB -DQT_CORE_LIB -IH:\qt3rd\qtgamepad\src\gamepad -I. -IH:\qt3rd\3rdparty-builds\libpng -IH:\qt3rd\3rdparty-builds\zlib -IH:\qt3rd\3rdparty-builds\libjpeg -IH:/qt3rd/qtgamepad/include -IH:/qt3rd/qtgamepad/include/QtGamepad -I..\..\include -I..\..\include\QtGamepad -IH:/qt3rd/qtgamepad/include/QtGamepad/5.7.0 -IH:/qt3rd/qtgamepad/include/QtGamepad/5.7.0/QtGamepad -Itmp -IH:\qt3rd\qtbase\include\QtCore\5.7.0 -IH:\qt3rd\qtbase\include\QtCore\5.7.0\QtCore -IH:\qt3rd\qtbase\include -IH:\qt3rd\qtbase\include\QtGui -IH:\qt3rd\qtbase\include\QtANGLE -IH:\qt3rd\build-Qt-5.7.0-beta-msvc2013-x64-static\qtbase\include -IH:\qt3rd\build-Qt-5.7.0-beta-msvc2013-x64-static\qtbase\include\QtGui -IH:\qt3rd\qtbase\include\QtCore -IH:\qt3rd\build-Qt-5.7.0-beta-msvc2013-x64-static\qtbase\include\QtCore -I.moc\debug -IH:\qt3rd\qtbase\mkspecs\win32-msvc2013 -Fo.obj\debug\ @C:\Users\Tim\AppData\Local\Temp\qgamepadmanager.obj.84524.8750.jom qgamepadmanager.cpp H:\qt3rd\jom.exe -f Makefile.Debug all h:\qt3rd\qtgamepad\src\gamepad\qgamepadmanager.h(42) : fatal error C1083: Cannot open include file: 'QtGamepad/qtgamepadglobal.h': No such file or directory qgamepad.cpp --- i know ci builds with dozens of configurations are impractical and require a significant amount of buildserver resources. but it would be great if tarballs could be tested with non-standard configurations ... namespaced qt, static libs, out-of-tree builds, slightly older compilers ... all these configurations are often broken in released tarballs. i suppose both qt devs and users would save quite some time and frustrations, if these configurations could be tested as part of the process of releasing a tarball. cheers, tim From sean.harmer at kdab.com Thu May 5 14:01:24 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 05 May 2016 13:01:24 +0100 Subject: [Development] Qt CI reliability In-Reply-To: <2760300.rZfUxo7XgH@cartman> References: <4166383.CnvrWBLNsi@titan> <6885742.Lm1y6c2V3b@42> <2760300.rZfUxo7XgH@cartman> Message-ID: <8041607.v8A9SkorOj@cartman> And more problems today: http://testresults.qt.io/logs/qt/qt3d/83275e6eb72baa5f80d4fbaaf84bc0ffd1b59762/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCDisableTests_OpenGLES2/f09f2056189e7df3613966a77c6b671ff3d5ea88/buildlog.txt.gz results in a 404. I hope this doesn't last all of the holiday weekend... Sean On Thursday 05 May 2016 11:15:38 Sean Harmer wrote: > On Tuesday 03 May 2016 17:36:49 Jędrzej Nowacki wrote: > > On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote: > > > Do you mean VM template? If so then yes that's again something that > > > should > > > ideally be verified before deployment. > > > > Eh, wrong phrasing. Templates are tested. The problem is that the current > > process is a bit racy. Updating template is a work that require time, > > especially for testing and deployment. Regressions may appear during that > > time window. Anyway the process is about to be changed soon. > > Here's another new failure mode: > > http://testresults.qt.io/logs/qt/qtbase/3356adaae5186a77c2aec458e2a1ebd3e40d > b8ab/LinuxUbuntu_14_04x86_64LinuxUbuntu_14_04x86_64GCCDeveloperBuild_OutOfSo > urceBuild_QtLibInfix_QtNamespace/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/bu > ildlog.txt.gz > > Failing with: > > Determining architecture... () > make: Warning: File `../../../qt/qtbase/config.tests/arch/arch.pro' has > modification time 1.3e+03 s in the future > /home/qt/work/build/bin/qmake -qtconf /home/qt/work/build/bin/qt.conf > -nocache -spec /home/qt/work/qt/qtbase/mkspecs/linux-g++ LIBS+= > QMAKE_CXXFLAGS+= INCLUDEPATH+= CONFIG-=app_bundle -o Makefile > ../../../qt/qtbase/config.tests/arch/arch.pro > ... > > agent:2016/05/05 13:07:20 build.go:221: Killed process after timeout (total > time) > agent:2016/05/05 13:07:20 agent.go:170: Build failed > agent:2016/05/05 13:07:20 agent.go:127: ERROR building: Timeout after 5m0s: > Maximum duration reached > agent:2016/05/05 13:07:20 build.go:158: Error reading from stdout/err: > Timeout after 5m0s: Maximum duration reached > > Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From sean.harmer at kdab.com Thu May 5 15:18:33 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 05 May 2016 14:18:33 +0100 Subject: [Development] Qt CI reliability In-Reply-To: <8041607.v8A9SkorOj@cartman> References: <4166383.CnvrWBLNsi@titan> <2760300.rZfUxo7XgH@cartman> <8041607.v8A9SkorOj@cartman> Message-ID: <2558446.zJrA4uLhhu@cartman> On Thursday 05 May 2016 13:01:24 Sean Harmer wrote: > And more problems today: > > http://testresults.qt.io/logs/qt/qt3d/83275e6eb72baa5f80d4fbaaf84bc0ffd1b597 > 62/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCDisableTests_OpenGLE > S2/f09f2056189e7df3613966a77c6b671ff3d5ea88/buildlog.txt.gz > > results in a 404. I hope this doesn't last all of the holiday weekend... And now another qt3d integration fails with: Module "qt/qtdeclarative" (9a7cf067a178c7a08a7ed9f2c6253e1feade5569) did not compile: Could not parse build log :( Is anybody able to poke the system please to see what's going wrong? Sean > > Sean > > On Thursday 05 May 2016 11:15:38 Sean Harmer wrote: > > On Tuesday 03 May 2016 17:36:49 Jędrzej Nowacki wrote: > > > On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote: > > > > Do you mean VM template? If so then yes that's again something that > > > > should > > > > ideally be verified before deployment. > > > > > > Eh, wrong phrasing. Templates are tested. The problem is that the > > > current > > > process is a bit racy. Updating template is a work that require time, > > > especially for testing and deployment. Regressions may appear during > > > that > > > time window. Anyway the process is about to be changed soon. > > > > Here's another new failure mode: > > > > http://testresults.qt.io/logs/qt/qtbase/3356adaae5186a77c2aec458e2a1ebd3e4 > > 0d > > b8ab/LinuxUbuntu_14_04x86_64LinuxUbuntu_14_04x86_64GCCDeveloperBuild_OutO > > fSo > > urceBuild_QtLibInfix_QtNamespace/85d6b000f945a84bc84a4f01f53ac65bc05cbe86 > > /bu ildlog.txt.gz > > > > Failing with: > > > > Determining architecture... () > > make: Warning: File `../../../qt/qtbase/config.tests/arch/arch.pro' has > > modification time 1.3e+03 s in the future > > /home/qt/work/build/bin/qmake -qtconf /home/qt/work/build/bin/qt.conf > > -nocache -spec /home/qt/work/qt/qtbase/mkspecs/linux-g++ LIBS+= > > QMAKE_CXXFLAGS+= INCLUDEPATH+= CONFIG-=app_bundle -o Makefile > > ../../../qt/qtbase/config.tests/arch/arch.pro > > ... > > > > agent:2016/05/05 13:07:20 build.go:221: Killed process after timeout > > (total > > time) > > agent:2016/05/05 13:07:20 agent.go:170: Build failed > > agent:2016/05/05 13:07:20 agent.go:127: ERROR building: Timeout after > > 5m0s: > > Maximum duration reached > > agent:2016/05/05 13:07:20 build.go:158: Error reading from stdout/err: > > Timeout after 5m0s: Maximum duration reached > > > > Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From tuukka.turunen at qt.io Thu May 5 15:57:59 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 5 May 2016 13:57:59 +0000 Subject: [Development] Qt CI reliability In-Reply-To: <2558446.zJrA4uLhhu@cartman> References: <4166383.CnvrWBLNsi@titan> <2760300.rZfUxo7XgH@cartman> <8041607.v8A9SkorOj@cartman> <2558446.zJrA4uLhhu@cartman> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Sean Harmer > Sent: torstaina 5. toukokuuta 2016 15.19 > To: development at qt-project.org > Subject: Re: [Development] Qt CI reliability > > On Thursday 05 May 2016 13:01:24 Sean Harmer wrote: > > And more problems today: > > > > http://testresults.qt.io/logs/qt/qt3d/83275e6eb72baa5f80d4fbaaf84bc0ff > > d1b597 > > > 62/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCDisableTe > sts_O > > penGLE S2/f09f2056189e7df3613966a77c6b671ff3d5ea88/buildlog.txt.gz > > > > results in a 404. I hope this doesn't last all of the holiday weekend... > > And now another qt3d integration fails with: > > Module "qt/qtdeclarative" (9a7cf067a178c7a08a7ed9f2c6253e1feade5569) > did not > compile: > Could not parse build log :( > > Is anybody able to poke the system please to see what's going wrong? > I am afraid that it is again a time of public holiday in all our main R&D sites. It may be that someone is working today, but most developers are away. I do fully agree with you that such things should not happen in the first place. Yours, Tuukka > Sean > > > > > Sean > > > > On Thursday 05 May 2016 11:15:38 Sean Harmer wrote: > > > On Tuesday 03 May 2016 17:36:49 Jędrzej Nowacki wrote: > > > > On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote: > > > > > Do you mean VM template? If so then yes that's again something > > > > > that should ideally be verified before deployment. > > > > > > > > Eh, wrong phrasing. Templates are tested. The problem is that the > > > > current process is a bit racy. Updating template is a work that > > > > require time, especially for testing and deployment. Regressions > > > > may appear during that time window. Anyway the process is about to > > > > be changed soon. > > > > > > Here's another new failure mode: > > > > > > http://testresults.qt.io/logs/qt/qtbase/3356adaae5186a77c2aec458e2a1 > > > ebd3e4 > > > 0d > > > > b8ab/LinuxUbuntu_14_04x86_64LinuxUbuntu_14_04x86_64GCCDeveloperB > uild > > > _OutO > > > fSo > > > > urceBuild_QtLibInfix_QtNamespace/85d6b000f945a84bc84a4f01f53ac65bc05 > > > cbe86 > > > /bu ildlog.txt.gz > > > > > > Failing with: > > > > > > Determining architecture... () > > > make: Warning: File `../../../qt/qtbase/config.tests/arch/arch.pro' > > > has modification time 1.3e+03 s in the future > > > /home/qt/work/build/bin/qmake -qtconf > > > /home/qt/work/build/bin/qt.conf -nocache -spec > > > /home/qt/work/qt/qtbase/mkspecs/linux-g++ LIBS+= > QMAKE_CXXFLAGS+= > > > INCLUDEPATH+= CONFIG-=app_bundle -o Makefile > > > ../../../qt/qtbase/config.tests/arch/arch.pro > > > ... > > > > > > agent:2016/05/05 13:07:20 build.go:221: Killed process after timeout > > > (total > > > time) > > > agent:2016/05/05 13:07:20 agent.go:170: Build failed > > > agent:2016/05/05 13:07:20 agent.go:127: ERROR building: Timeout > > > after > > > 5m0s: > > > Maximum duration reached > > > agent:2016/05/05 13:07:20 build.go:158: Error reading from stdout/err: > > > Timeout after 5m0s: Maximum duration reached > > > > > > Sean > > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46- > 563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Thu May 5 16:08:33 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 5 May 2016 14:08:33 +0000 Subject: [Development] [Qt Quick] Automatically restoring focus to last focused item Message-ID: Consider the example below (requires Qt 5.7): import QtQuick 2.6 import QtQuick.Layouts 1.1 import QtQuick.Window 2.2 import QtQuick.Controls 2.0 ApplicationWindow { width: 400 height: 200 visible: true onActiveFocusItemChanged: print("activeFocusItem", activeFocusItem) header: ToolBar { RowLayout { focus: false implicitWidth: children[0].implicitWidth implicitHeight: children[0].implicitHeight ToolButton { text: qsTr("File") onClicked: fileMenu.open() Menu { id: fileMenu y: parent.height MenuItem { text: qsTr("New") } MenuItem { text: qsTr("open") } MenuItem { text: qsTr("Close") } } } } } FocusScope { id: focusScope focus: true anchors.fill: parent property bool toggled: false onToggledChanged: print("toggled", toggled) Keys.onPressed: { if (event.modifiers === Qt.AltModifier) { focusScope.toggled = true; } } Keys.onReleased: { if ((event.modifiers === Qt.AltModifier || event.key === Qt.Key_Alt) && !event.isAutoRepeat) { focusScope.toggled = false; } } RowLayout { anchors.centerIn: parent Button { id: penButton text: qsTr("Pen") highlighted: !focusScope.toggled } Button { id: eyedropperButton text: qsTr("Eyedropper") highlighted: focusScope.toggled } } } } The idea is that holding the Alt key down will toggle between two "modes". The mode is indicated by a highlighted button. Try switching between the buttons. Now open the menu by clicking the "File" button. The menu will receive focus and the focus scope will lose it. If you then close the menu and try to switch between the buttons again, it won't work because the focus scope never regained focus (the root item now has it). This is explained here [1]: "When a QML Item explicitly relinquishes focus (by setting its focus property to false while it has active focus), the system does not automatically select another type to receive focus. That is, it is possible for there to be no currently active focus." I'm not sure if "explicitly relinquishes focus" is exactly what's happening here, though. The FocusScope loses focus because something else was open temporarily. So now the developer has no other option than to listen to e.g. the menu visibility changes and explicitly set focus on the FocusScope accordingly. That's pretty gross if you ask me. I think we can do better. Specifically, I think that we should remember the last focused item, and give that focus, rather than give it to the root item. The question is, would it be an acceptable change for Qt 5? I'd assume that users are already working around this anyway, and so the fix wouldn't hurt. [1] http://doc.qt.io/qt-5/qtquick-input-focus.html From thiago.macieira at intel.com Thu May 5 18:22:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 May 2016 09:22:04 -0700 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: References: Message-ID: <9510515.AUIrav06Ky@tjmaciei-mobl4> On quinta-feira, 5 de maio de 2016 13:39:59 PDT Tim Blechmann wrote: > compiling the qt-5.7-beta tarball with msvc2013/64bit/static libraries, > out-of-tree build gives me: > > --- [cut] > h:\qt3rd\qtgamepad\src\gamepad\qgamepadmanager.h(42) : fatal error > C1083: Cannot open include file: 'QtGamepad/qtgamepadglobal.h': No such > file or directory > qgamepad.cpp > > --- > > i know ci builds with dozens of configurations are impractical and > require a significant amount of buildserver resources. but it would be > great if tarballs could be tested with non-standard configurations ... > namespaced qt, static libs, out-of-tree builds, slightly older compilers > ... all these configurations are often broken in released tarballs. i > suppose both qt devs and users would save quite some time and > frustrations, if these configurations could be tested as part of the > process of releasing a tarball. Hello Tim It should have been. That's why we have a release team that does sanity checking on the packages and releasing isn't just "make a git tag and create packages". Though it's also true that a beta release receives less attention than a full one. One thing, however, struck me in your description: you said you're building a *tarball* with MSVC2013. Does it mean you downloaded the .tar.gz or .tar.xz file for Windows? If so, be careful with line endings. I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present. Given the paths your build shows, I'm guessing you unpacked the sources in H:/qt3rd, which means this file should have ended up in H:/qt3rd/qtgamepad/include/QtGamepad/qtgamepadglobal.h Is that correct? Your command line had: -IH:/qt3rd/qtgamepad/include -IH:/qt3rd/qtgamepad/include/QtGamepad -I..\..\include -I..\..\include\QtGamepad So I have to ask: how did it *not* find the file? If your output is correct, it should have found by concatenating that first -I with the path being sought, which tells me that the difference may be a non-visible character, like a line-ending. Can you confirm that the command-line you pasted refers to the file that failed to build? There's a "jom" command in the middle of the output, which means that you used jom and that it was doing parallel builds, so it's possible that it referred to something else. As a rule of thumb, if a parallel build fails, rerun with -j1 to get the actual first error with no reordering. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Sean.Donnelly at autodesk.com Thu May 5 21:09:59 2016 From: Sean.Donnelly at autodesk.com (Sean Donnelly) Date: Thu, 5 May 2016 19:09:59 +0000 Subject: [Development] Suggestion: how to know when object is scheduled for deletion Message-ID: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> In our application we maintain a UI Inventory via a named object cache. When an object is destroyed we remove it from our cache and when the name is changed we also update our cache. However when an object is scheduled for deletion via QObject::deleteLater() the object remains in our cache until it's actually deleted. I have two proposals: 1. Could deleteLater() send a signal so that we can update our cache immediately and not find that UI object which is about to be deleted. 2. Could deleteLater() set a property to know the object is in an "about to be deleted state". That way our UI Inventory could be updated to ignore these objects. Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.ezust at gmail.com Thu May 5 21:43:52 2016 From: alan.ezust at gmail.com (Alan Ezust) Date: Thu, 5 May 2016 12:43:52 -0700 Subject: [Development] Suggestion: how to know when object is scheduled for deletion In-Reply-To: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> References: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> Message-ID: Looking at the implementation of deleteLater: { QCoreApplication::postEvent(this, new QDeferredDeleteEvent()); } It seems to me you can achieve what you want without modifying the implementation of deleteLater(), and instead making an event filter on QCoreApplication for QDeferredDeleteEvent. On Thu, May 5, 2016 at 12:09 PM, Sean Donnelly wrote: > In our application we maintain a UI Inventory via a named object cache. > When an object is destroyed we remove it from our cache and when the name > is changed we also update our cache. > > > > However when an object is scheduled for deletion via > QObject::deleteLater() the object remains in our cache until it’s actually > deleted. > > > > I have two proposals: > > > > 1. Could deleteLater() send a signal so that we can update our > cache immediately and not find that UI object which is about to be deleted. > > 2. Could deleteLater() set a property to know the object is in an > “about to be deleted state”. That way our UI Inventory could be updated to > ignore these objects. > > > > Thanks, > > Sean > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filippocucchetto at gmail.com Thu May 5 22:21:08 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Thu, 5 May 2016 22:21:08 +0200 Subject: [Development] Suggestion: how to know when object is scheduled for deletion In-Reply-To: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> References: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> Message-ID: It depends on your use case but maybe you can simply create a QObject that has the responsability of deleting your QObjects and emit a signal just after calling deleteLater. class MyDeleter : public QObject { ... signals: void aboutToBeDelete(QObject*); ... void invokeDeleteLater(QObject* other) { other->deleteLater(); emit aboutToBeDeleted(other) } ... } Depending on your architecture you can make it a singleton, global or context variable. After that you can replace everywhere: objectManagedByCache->deleteLater() with myDeleter->invokeDeleteLater(objectManagedByCache). You can also add this "invokeDeleteLater" directly to the class that manages your cache. 2016-05-05 21:09 GMT+02:00 Sean Donnelly : > In our application we maintain a UI Inventory via a named object cache. > When an object is destroyed we remove it from our cache and when the name > is changed we also update our cache. > > > > However when an object is scheduled for deletion via > QObject::deleteLater() the object remains in our cache until it’s actually > deleted. > > > > I have two proposals: > > > > 1. Could deleteLater() send a signal so that we can update our > cache immediately and not find that UI object which is about to be deleted. > > 2. Could deleteLater() set a property to know the object is in an > “about to be deleted state”. That way our UI Inventory could be updated to > ignore these objects. > > > > Thanks, > > Sean > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri May 6 01:00:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 May 2016 16:00:18 -0700 Subject: [Development] Suggestion: how to know when object is scheduled for deletion In-Reply-To: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> References: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> Message-ID: <2677901.lrVzSUeYEc@tjmaciei-mobl4> On quinta-feira, 5 de maio de 2016 19:09:59 PDT Sean Donnelly wrote: > In our application we maintain a UI Inventory via a named object cache. > When an object is destroyed we remove it from our cache and when the name > is changed we also update our cache. > > However when an object is scheduled for deletion via QObject::deleteLater() > the object remains in our cache until it's actually deleted. > > I have two proposals: > > > 1. Could deleteLater() send a signal so that we can update our cache > immediately and not find that UI object which is about to be deleted. The signal is destroyed() and is sent as soon the object actually gets deleted. > 2. Could deleteLater() set a property to know the object is in an > "about to be deleted state". That way our UI Inventory could be updated to > ignore these objects. That's a bad idea. If you deleteLater() an object in the current thread, the object is really not deleted and may still work fine. However, if you do that for an object in another thread, the object may get deleted immediately, so you can't touch the object anymore and you can't get to the property. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri May 6 01:01:06 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 May 2016 16:01:06 -0700 Subject: [Development] Suggestion: how to know when object is scheduled for deletion In-Reply-To: References: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> Message-ID: <3812660.ZDXCtsH303@tjmaciei-mobl4> On quinta-feira, 5 de maio de 2016 22:21:08 PDT Filippo Cucchetto wrote: > void invokeDeleteLater(QObject* other) { > other->deleteLater(); > emit aboutToBeDeleted(other) > } You want the emit before the deleteLater(), if the object can be in another thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tim at klingt.org Fri May 6 11:35:16 2016 From: tim at klingt.org (Tim Blechmann) Date: Fri, 6 May 2016 11:35:16 +0200 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <9510515.AUIrav06Ky@tjmaciei-mobl4> References: <9510515.AUIrav06Ky@tjmaciei-mobl4> Message-ID: <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> > I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and > confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present ah, thanks for the pointer ... importing qt tarballs into git repos is full of surprises: qtgamepad/.gitignore ignores 'include' my usual workflow is to import the qt-everywhere-enterprise-src*.tar tarball into a git repo, as i need to apply 10-40 patches to work around qt bugs. of course .gitignore or .gitmodules files don't exactly make this a no-brainer :/ thanks a lot! tim From apoenitz at t-online.de Fri May 6 11:44:04 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 6 May 2016 11:44:04 +0200 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> References: <9510515.AUIrav06Ky@tjmaciei-mobl4> <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> Message-ID: <20160506094404.GA2049@klara.mpi.htwm.de> On Fri, May 06, 2016 at 11:35:16AM +0200, Tim Blechmann wrote: > > I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and > > confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present > > ah, thanks for the pointer ... importing qt tarballs into git repos is > full of surprises: qtgamepad/.gitignore ignores 'include' > > my usual workflow is to import the qt-everywhere-enterprise-src*.tar > tarball into a git repo, as i need to apply 10-40 patches to work around > qt bugs. of course .gitignore or .gitmodules files don't exactly make > this a no-brainer :/ If you are using git anyway why don't you directly clone from the git repos? Andre' From sean.harmer at kdab.com Fri May 6 12:08:59 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 06 May 2016 11:08:59 +0100 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> References: <9510515.AUIrav06Ky@tjmaciei-mobl4> <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> Message-ID: <3198615.0g5XWvtkUF@cartman> On Friday 06 May 2016 11:35:16 Tim Blechmann wrote: > > I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and > > confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present > > ah, thanks for the pointer ... importing qt tarballs into git repos is > full of surprises: qtgamepad/.gitignore ignores 'include' > > my usual workflow is to import the qt-everywhere-enterprise-src*.tar > tarball into a git repo, as i need to apply 10-40 patches to work around > qt bugs. of course .gitignore or .gitmodules files don't exactly make > this a no-brainer :/ Which bugs? Can you not upstream the fixes? Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From tim at klingt.org Fri May 6 12:29:40 2016 From: tim at klingt.org (Tim Blechmann) Date: Fri, 6 May 2016 12:29:40 +0200 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <20160506094404.GA2049@klara.mpi.htwm.de> References: <9510515.AUIrav06Ky@tjmaciei-mobl4> <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> <20160506094404.GA2049@klara.mpi.htwm.de> Message-ID: >>> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and >>> confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present >> >> ah, thanks for the pointer ... importing qt tarballs into git repos is >> full of surprises: qtgamepad/.gitignore ignores 'include' >> >> my usual workflow is to import the qt-everywhere-enterprise-src*.tar >> tarball into a git repo, as i need to apply 10-40 patches to work around >> qt bugs. of course .gitignore or .gitmodules files don't exactly make >> this a no-brainer :/ > > If you are using git anyway why don't you directly clone from the > git repos? for practical reasons: qt is not one repo, but several glued together with submodules, so i'd have to mirror all submodule repos separately using the same structure as the upstream repos to make sure the 'url' works. whenever a new submodule is added one has to explicitly mirror it. also one will constantly run into merge conflicts in the main repository, as the git revisions will differ. if the qt repo were monolithic i'd be more than happy to use it directly, but with submodules it calls for trouble :/ From tim at klingt.org Fri May 6 12:55:47 2016 From: tim at klingt.org (Tim Blechmann) Date: Fri, 6 May 2016 12:55:47 +0200 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <3198615.0g5XWvtkUF@cartman> References: <9510515.AUIrav06Ky@tjmaciei-mobl4> <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> <3198615.0g5XWvtkUF@cartman> Message-ID: >>> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and >>> confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present >> >> ah, thanks for the pointer ... importing qt tarballs into git repos is >> full of surprises: qtgamepad/.gitignore ignores 'include' >> >> my usual workflow is to import the qt-everywhere-enterprise-src*.tar >> tarball into a git repo, as i need to apply 10-40 patches to work around >> qt bugs. of course .gitignore or .gitmodules files don't exactly make >> this a no-brainer :/ > > Which bugs? Can you not upstream the fixes? most of the fixes were backports or have been merged upstream at one point, but waiting for the next qt version wasn't an option. some of the fixes (including some provided by qtcompany or qtsupport) were rejected because they were not considered 'correct' (though for some issues an ugly hack is better than a crash of an end-user application). some of my patches were not adopted as submitted, but the algorithm was rewritten, but not merged yet. -- i cannot tell to end-users: "hey, i know this is going to crash, but the fix hasn't arrived upstream, yet" :) From oswald.buddenhagen at qt.io Fri May 6 13:02:48 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 6 May 2016 13:02:48 +0200 Subject: [Development] HEADS UP: Qt 5.6.1 branching ongoing Message-ID: <20160506110248.GA15804@troll08.it.local> The 5.6.1 branch is now available. Please start using it for changes targeting the Qt 5.6.1 release. We will merge the 5.6 branch to 5.6.1 a last time somewhen next week, so there should be enough time to finalize ongoing changes in 5.6, and start using 5.6.1 for new changes. Changes done on 5.6.1 are forward-merged to 5.6, 5.7, and dev - as usual. Don't cherry-pick in either direction if at all avoidable - as usual. From andrew.den.exter at qinetic.com.au Fri May 6 13:38:14 2016 From: andrew.den.exter at qinetic.com.au (Andrew den Exter) Date: Fri, 6 May 2016 21:38:14 +1000 Subject: [Development] [Qt Quick] Automatically restoring focus to last focused item In-Reply-To: References: Message-ID: That's a very universal solution to a specific problem and one that's going to have all kinds of unintended consequences. Without knowing why focus was taken from an item and given to another and why that other object relinquished focus it's impossible to know whether focus should be restored to that first item. That memory may have to go back more than one item as well, after all if you open one menu then another then the previous focus item is the first window and that's obviously not what you want to give focus to. What you want to do instead is introduce a FocusScope to ApplicationWindow. If the window's content item is a focus scope then giving focus to a menu which is outside of this scope will not affect focus within the scope, then whatever logic closes the menu can give focus back to the content item and that will implicitly return active focus to your item in the window body. Andrew On Fri, May 6, 2016 at 12:08 AM, Mitch Curtis wrote: > Consider the example below (requires Qt 5.7): > > import QtQuick 2.6 > import QtQuick.Layouts 1.1 > import QtQuick.Window 2.2 > import QtQuick.Controls 2.0 > > ApplicationWindow { > width: 400 > height: 200 > visible: true > > onActiveFocusItemChanged: print("activeFocusItem", activeFocusItem) > > header: ToolBar { > RowLayout { > focus: false > implicitWidth: children[0].implicitWidth > implicitHeight: children[0].implicitHeight > > ToolButton { > text: qsTr("File") > onClicked: fileMenu.open() > > Menu { > id: fileMenu > y: parent.height > > MenuItem { > text: qsTr("New") > } > MenuItem { > text: qsTr("open") > } > MenuItem { > text: qsTr("Close") > } > } > } > } > } > > FocusScope { > id: focusScope > focus: true > anchors.fill: parent > > property bool toggled: false > onToggledChanged: print("toggled", toggled) > > Keys.onPressed: { > if (event.modifiers === Qt.AltModifier) { > focusScope.toggled = true; > } > } > Keys.onReleased: { > if ((event.modifiers === Qt.AltModifier || event.key === > Qt.Key_Alt) && !event.isAutoRepeat) { > focusScope.toggled = false; > } > } > > RowLayout { > anchors.centerIn: parent > > Button { > id: penButton > text: qsTr("Pen") > highlighted: !focusScope.toggled > } > Button { > id: eyedropperButton > text: qsTr("Eyedropper") > highlighted: focusScope.toggled > } > } > } > } > > The idea is that holding the Alt key down will toggle between two "modes". > The mode is indicated by a highlighted button. > > Try switching between the buttons. Now open the menu by clicking the > "File" button. The menu will receive focus and the focus scope will lose > it. If you then close the menu and try to switch between the buttons again, > it won't work because the focus scope never regained focus (the root item > now has it). This is explained here [1]: > > "When a QML Item explicitly relinquishes focus (by setting its focus > property to false while it has active focus), the system does not > automatically select another type to receive focus. That is, it is possible > for there to be no currently active focus." > > I'm not sure if "explicitly relinquishes focus" is exactly what's > happening here, though. The FocusScope loses focus because something else > was open temporarily. So now the developer has no other option than to > listen to e.g. the menu visibility changes and explicitly set focus on the > FocusScope accordingly. That's pretty gross if you ask me. I think we can > do better. Specifically, I think that we should remember the last focused > item, and give that focus, rather than give it to the root item. The > question is, would it be an acceptable change for Qt 5? I'd assume that > users are already working around this anyway, and so the fix wouldn't hurt. > > [1] http://doc.qt.io/qt-5/qtquick-input-focus.html > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filippocucchetto at gmail.com Fri May 6 15:32:27 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Fri, 6 May 2016 15:32:27 +0200 Subject: [Development] Suggestion: how to know when object is scheduled for deletion In-Reply-To: <3812660.ZDXCtsH303@tjmaciei-mobl4> References: <7e7325c689d0472fa93c4f9e8558dcd5@DM2PR79MB029.MGDADSK.autodesk.com> <3812660.ZDXCtsH303@tjmaciei-mobl4> Message-ID: Yep correct 2016-05-06 1:01 GMT+02:00 Thiago Macieira : > On quinta-feira, 5 de maio de 2016 22:21:08 PDT Filippo Cucchetto wrote: > > void invokeDeleteLater(QObject* other) { > > other->deleteLater(); > > emit aboutToBeDeleted(other) > > } > > You want the emit before the deleteLater(), if the object can be in another > thread. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri May 6 23:39:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 06 May 2016 14:39:12 -0700 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> References: <9510515.AUIrav06Ky@tjmaciei-mobl4> <3330914f-feb9-5a20-8e25-e0e65e20208d@klingt.org> Message-ID: <2933289.LQHUiBWRZ6@tjmaciei-mobl4> On sexta-feira, 6 de maio de 2016 11:35:16 PDT Tim Blechmann wrote: > ah, thanks for the pointer ... importing qt tarballs into git repos is > full of surprises: qtgamepad/.gitignore ignores 'include' The release tarballs should have removed the .gitignore file. Compare http://code.qt.io/cgit/qt/qtbase.git/tree/.gitattributes?h=v5.7.0-beta1 with http://code.qt.io/cgit/qt/qtgamepad.git/tree/.gitattributes?h=v5.7.0-beta1 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From joseph.w.crowell at gmail.com Sat May 7 06:20:36 2016 From: joseph.w.crowell at gmail.com (Joseph Crowell) Date: Sat, 7 May 2016 14:20:36 +1000 Subject: [Development] Scope of source code license files In-Reply-To: <2292E19B-3536-487A-AC63-FC8C3FE1031B@qt.io> References: <2292E19B-3536-487A-AC63-FC8C3FE1031B@qt.io> Message-ID: <1c8d5145-e611-f3ef-1cd5-d2fda322b427@gmail.com> On 4/05/2016 7:39 PM, Lars Knoll wrote: > On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" wrote: > > > >> Hello, >> >> The LICENSE.GPLvX and LICENSE.LGPLvX files from >> http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with >> "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say >> "You may use, distribute and copy the Qt GUI Toolkit under the terms >> of..." >> >> Is this correct? What about non-GUI parts of the toolkit? > The GUI in here is just a historical thing. It applies to Qt. Wording should probably should be changed then as times have changed and Qt is certainly no longer just a GUI toolkit. > > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Sat May 7 18:21:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 07 May 2016 09:21:45 -0700 Subject: [Development] [Interest] .pc file generation In-Reply-To: <1630201.t0Gm5NvDKe@portia.local> References: <1630201.t0Gm5NvDKe@portia.local> Message-ID: <8371919.2Szt45B9SF@tjmaciei-mobl4> On sábado, 7 de maio de 2016 16:40:32 PDT René J.V. Bertin wrote: > Hi, > > Re: https://codereview.qt-project.org/#/c/140954/ > > Is the justification for omitting .pc files still relevant that "frameworks > are currently broken anyway"? They don't appear to be, but omitting > pkg-config files for them makes it impossible to build all dependent > software that uses pkg-config for finding Qt5. Example: poppler's Qt5 > wrapper. > > I think that's not really acceptable, especially since they again install > just fine after applying the reverse patch > (https://github.com/Homebrew/legacy-homebrew/commit/620baaf10c957875d9d2b95 > 8343456f0d35d15fc). > > Are there plans to address this issue, or should I file a bug report? [Thread moved to dev] Frameworks with pkg-config are broken, it appears, not Qt. If you have a suggestion of what we should produce, say so. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From krnekit at gmail.com Sat May 7 21:05:32 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Sat, 7 May 2016 22:05:32 +0300 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: References: <9510515.AUIrav06Ky@tjmaciei-mobl4> Message-ID: Re-sending to ml. 2016-05-07 22:03 GMT+03:00 Nikita Krupenko : > 2016-05-05 19:22 GMT+03:00 Thiago Macieira : >> One thing, however, struck me in your description: you said you're building a >> *tarball* with MSVC2013. Does it mean you downloaded the .tar.gz or .tar.xz >> file for Windows? If so, be careful with line endings. > > I can confirm build failures of qtgamepad v5.7.0-beta1 on Linux with > gcc 5.3.1, though the errors are different: > g++ -c -pipe -g -std=c++1z -fvisibility=hidden > -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time > -D_REENTRANT -fPIC -DQT_NO_TSLIB -DQT_NO_EXCEPTIONS > -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_PLUGIN > -DQT_PLATFORMSUPPORT_LIB -DQT_GAMEPAD_LIB -DQT_GUI_LIB -DQT_CORE_LIB > -I/mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev -I. > -I/mnt/store/Development/build_qt5.7_git/qtbase/include > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtPlatformSupport > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtPlatformSupport/5.7.0 > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtPlatformSupport/5.7.0/QtPlatformSupport > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtGui/5.7.0 > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtGui/5.7.0/QtGui > -I../../../../include/QtGamepad/5.7.0 > -I../../../../include/QtGamepad/5.7.0/QtGamepad -I../../../../include > -I../../../../include/QtGamepad > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtGui > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtCore/5.7.0 > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtCore/5.7.0/QtCore > -I/mnt/store/Development/build_qt5.7_git/qtbase/include/QtCore -I.moc > -isystem /usr/include/libdrm > -I/mnt/store/Development/qt5/qtbase/mkspecs/linux-g++ -o > .obj/qevdevgamepadbackend.o > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp: > In member function 'void > QEvdevGamepadDevice::EvdevAxisInfo::setAbsInfo(int, int)': > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp:79:67: > error: 'fabs' was not declared in this scope > flat = fabs(absInfo.flat / double(maxValue - minValue)); > ^ > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp: > In member function 'void > QEvdevGamepadDevice::processInputEvent(input_event*)': > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp:446:46: > error: 'fabs' was not declared in this scope > if (fabs(inf.normalized(e->value)) == 1) { > ^ > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp:506:98: > error: 'fabs' was not declared in this scope > emit m_backend->gamepadButtonPressed(m_productId, > info.gamepadMaxButton, fabs(val)); > > ^ > Makefile:1113: recipe for target '.obj/qevdevgamepadbackend.o' failed From roland.m.winklmeier at gmail.com Sat May 7 23:25:16 2016 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Sat, 7 May 2016 23:25:16 +0200 Subject: [Development] Does Qt 5.6 still depend on ICU? Message-ID: <572E5D3C.8070001@gmail.com> Dear Qt Devs, I'm currently preparing installers for a cross platform application (Win, Linux, OSX). I have investigated, which dependencies apart from the Qt5 libraries themselves are need to be shipped as well. But I'm a bit confused about the role of ICU. >From wiki pages (https://wiki.qt.io/Qt_5.6_Tools_and_Versions and https://wiki.qt.io/Building_Qt_5_from_Git), I understood that, ICU is only required for QtWebkit. I also learned that the ICU version shipped in Qt 5.6.0 is 56.1. However, I found the following facts a bit inconsistent: * Windows is actually shipping 54.1 instead of 56.1. Was the upgrade missed or is this on purpose? To me it is a minor issue, but I'm curious. * Official Windows QtCore binary is not linked against ICU libraries (at least from what I can see in dependency walker). Does it link at runtime? * Official Linux QtCore binary in contrast is linked against ICU (verified with ldd). * Official OS X QtCore binary again is not linked against ICU. Now my question: Is ICU mandatory for all platforms or maybe only for Linux? Ideally I could just skip shipping it in my installer, since I'm using a custom Qt5 build on my Debian server (I did not yet manage to use the official installer on a headless server with an install script). But I want to be sure, what features I'm loosing before any decision. ? *guess mode on* I guess, ICU was shipped previously because of QtWebkit. Since QtWebkit is no longer shipped in official installers, could ICU also be removed? I know what ICU is, but why is it shipped without linking against it? *guess mode off* Cheers Roland From samuel.gaist at edeltech.ch Sun May 8 00:47:18 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 8 May 2016 00:47:18 +0200 Subject: [Development] Qt QuickLook plugin In-Reply-To: <8B275AEE-E22C-498D-AAF7-5A15432E768D@qt.io> References: <8B275AEE-E22C-498D-AAF7-5A15432E768D@qt.io> Message-ID: On 2 mai 2016, at 09:07, Eike Ziller wrote: > >> On May 1, 2016, at 01:47, Jake Petroules wrote: >> >> That would be pretty awesome. It's possible we could ship it inside of Qt Creator? You can put them in either ~/Library/QuickLook or in $BUNDLE_CONTENTS/Library/QuickLook Sure thing, that's the direction I was looking for if possible :) Note that currently it is a really bare bone plugin. If it's made part of Qt Creator, we could maybe implement highlighting using Qt Creator's code model ? > > That made me start wondering why I do see a text preview for .qml files. We do declare these as OSType text in Qt Creator’s Info.plist. > So I tried https://codereview.qt-project.org/157721 for .pro, .pri, .qbs and .qrc as well, so far without any effect, but maybe that is because of some fancy OS caching of these values? > > Br, Eike Sorry, I currently don't know what may be the cause of this. Samuel > >>> On Apr 30, 2016, at 4:09 PM, Samuel Gaist wrote: >>> >>> Hi, >>> >>> I wrote a small QuickLook plugin for OS X that allows to get a preview of Qt's .pro, .pri and .qrc files without opening any editor. >>> >>> Would there be any interest in making it part of the standard OS X installation ? >>> >>> If so, what would be the process to include it ? >>> >>> Cheers >>> Samuel >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Jake Petroules - jake.petroules at theqtcompany.com >> Consulting Services Engineer - The Qt Company >> Qbs build system evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nassian at bitshift-dynamics.de Sun May 8 00:55:38 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Sun, 8 May 2016 00:55:38 +0200 Subject: [Development] Does Qt 5.6 still depend on ICU? In-Reply-To: <572E5D3C.8070001@gmail.com> References: <572E5D3C.8070001@gmail.com> Message-ID: <0F92F6E2-0ED5-40A3-83F1-1744F5001808@bitshift-dynamics.de> As far as I know Chromium also depends on ICU and without WebKit or WebEngine you may but need not to use ICU. But I sadly don't know if and what features are (internally) missing if Qt is not built with ICU - for our applications we always have to build it with because of WebKit/WebEngine. Beste Grüße / Best regards, Alexander Nassian > Am 07.05.2016 um 23:25 schrieb Roland Winklmeier : > > Dear Qt Devs, > > I'm currently preparing installers for a cross platform application > (Win, Linux, OSX). I have investigated, which dependencies apart from > the Qt5 libraries themselves are need to be shipped as well. But I'm a > bit confused about the role of ICU. > > From wiki pages (https://wiki.qt.io/Qt_5.6_Tools_and_Versions and > https://wiki.qt.io/Building_Qt_5_from_Git), I understood that, ICU is > only required for QtWebkit. I also learned that the ICU version shipped > in Qt 5.6.0 is 56.1. > > However, I found the following facts a bit inconsistent: > * Windows is actually shipping 54.1 instead of 56.1. Was the upgrade > missed or is this on purpose? To me it is a minor issue, but I'm curious. > * Official Windows QtCore binary is not linked against ICU libraries (at > least from what I can see in dependency walker). Does it link at runtime? > * Official Linux QtCore binary in contrast is linked against ICU > (verified with ldd). > * Official OS X QtCore binary again is not linked against ICU. > > Now my question: > Is ICU mandatory for all platforms or maybe only for Linux? Ideally I > could just skip shipping it in my installer, since I'm using a custom > Qt5 build on my Debian server (I did not yet manage to use the official > installer on a headless server with an install script). But I want to be > sure, what features I'm loosing before any decision. ? > > *guess mode on* > I guess, ICU was shipped previously because of QtWebkit. Since QtWebkit > is no longer shipped in official installers, could ICU also be removed? > I know what ICU is, but why is it shipped without linking against it? > *guess mode off* > > Cheers Roland > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Sun May 8 01:12:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 07 May 2016 16:12:16 -0700 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: References: Message-ID: <4354232.x34ARfPIjD@tjmaciei-mobl4> On sábado, 7 de maio de 2016 22:05:32 PDT Nikita Krupenko wrote: > Re-sending to ml. > > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevgame > > padbackend.cpp:79:67: error: 'fabs' was not declared in this scope > > flat = fabs(absInfo.flat / double(maxValue - minValue)); Missing #include. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun May 8 01:10:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 07 May 2016 16:10:53 -0700 Subject: [Development] Does Qt 5.6 still depend on ICU? In-Reply-To: <572E5D3C.8070001@gmail.com> References: <572E5D3C.8070001@gmail.com> Message-ID: <27100332.Nk7TVhMACJ@tjmaciei-mobl4> On sábado, 7 de maio de 2016 23:25:16 PDT Roland Winklmeier wrote: > From wiki pages (https://wiki.qt.io/Qt_5.6_Tools_and_Versions and > https://wiki.qt.io/Building_Qt_5_from_Git), I understood that, ICU is > only required for QtWebkit. I also learned that the ICU version shipped > in Qt 5.6.0 is 56.1. > > However, I found the following facts a bit inconsistent: > * Windows is actually shipping 54.1 instead of 56.1. Was the upgrade > missed or is this on purpose? To me it is a minor issue, but I'm curious. Looks like a mistake. > * Official Windows QtCore binary is not linked against ICU libraries (at > least from what I can see in dependency walker). Does it link at runtime? No. The build for Windows is using the Windows API so you can ship smaller builds without ICU. > * Official Linux QtCore binary in contrast is linked against ICU > (verified with ldd). The Linux build is linking against ICU because there's no fallback API of similar quality. And also because all Linux distros have ICU anyway. > * Official OS X QtCore binary again is not linked against ICU. Like Windows, OS X has a fallback API. In fact, Apple's API is almost a direct mapping of ICU's API. > Now my question: > Is ICU mandatory for all platforms or maybe only for Linux? Ideally I > could just skip shipping it in my installer, since I'm using a custom > Qt5 build on my Debian server (I did not yet manage to use the official > installer on a headless server with an install script). But I want to be > sure, what features I'm loosing before any decision. ? It's mandatory for none. You can choose if you build from sources, but note that the POSIX fallback for Unix systems is of much lower quality. The choices made for the binary builds are just that: choices. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Sun May 8 10:37:52 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Sun, 8 May 2016 08:37:52 +0000 Subject: [Development] Does Qt 5.6 still depend on ICU? In-Reply-To: <0F92F6E2-0ED5-40A3-83F1-1744F5001808@bitshift-dynamics.de> References: <572E5D3C.8070001@gmail.com> <0F92F6E2-0ED5-40A3-83F1-1744F5001808@bitshift-dynamics.de> Message-ID: > -----Ursprüngliche Nachricht----- > Von: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] Im Auftrag von Alexander Nassian > Gesendet: Sonntag, 8. Mai 2016 00:56 > An: Roland Winklmeier > Cc: development at qt-project.org > Betreff: Re: [Development] Does Qt 5.6 still depend on ICU? > > As far as I know Chromium also depends on ICU and without WebKit or > WebEngine you may but need not to use ICU. Qt WebEngine / Chromium on Windows builds with a statically linked version of ICU by default though, so there's no need to ship the ICU dll's for Qt WebEngine - just the icudtl.dat file . Regards Kai From roland.m.winklmeier at gmail.com Sun May 8 12:20:24 2016 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Sun, 8 May 2016 12:20:24 +0200 Subject: [Development] Does Qt 5.6 still depend on ICU? In-Reply-To: <27100332.Nk7TVhMACJ@tjmaciei-mobl4> References: <572E5D3C.8070001@gmail.com> <27100332.Nk7TVhMACJ@tjmaciei-mobl4> Message-ID: <572F12E8.1050304@gmail.com> On 05/08/2016 01:10 AM, Thiago Macieira wrote: > On sábado, 7 de maio de 2016 23:25:16 PDT Roland Winklmeier wrote: >> From wiki pages (https://wiki.qt.io/Qt_5.6_Tools_and_Versions and >> https://wiki.qt.io/Building_Qt_5_from_Git), I understood that, ICU is >> only required for QtWebkit. I also learned that the ICU version shipped >> in Qt 5.6.0 is 56.1. >> >> However, I found the following facts a bit inconsistent: >> * Windows is actually shipping 54.1 instead of 56.1. Was the upgrade >> missed or is this on purpose? To me it is a minor issue, but I'm curious. > > Looks like a mistake. Do you want me to raise a bug report? >> Now my question: >> Is ICU mandatory for all platforms or maybe only for Linux? Ideally I >> could just skip shipping it in my installer, since I'm using a custom >> Qt5 build on my Debian server (I did not yet manage to use the official >> installer on a headless server with an install script). But I want to be >> sure, what features I'm loosing before any decision. ? > > It's mandatory for none. You can choose if you build from sources, but note > that the POSIX fallback for Unix systems is of much lower quality. > > The choices made for the binary builds are just that: choices. > Thanks a lot. Now it is much clearer to me. I'll follow the official release binaries choice and link my custom Linux build against ICU. Cheers Roland From thiago.macieira at intel.com Sun May 8 20:19:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 08 May 2016 11:19:53 -0700 Subject: [Development] Does Qt 5.6 still depend on ICU? In-Reply-To: <572F12E8.1050304@gmail.com> References: <572E5D3C.8070001@gmail.com> <27100332.Nk7TVhMACJ@tjmaciei-mobl4> <572F12E8.1050304@gmail.com> Message-ID: <5164450.lCKsJ8HP15@tjmaciei-mobl4> On domingo, 8 de maio de 2016 12:20:24 PDT Roland Winklmeier wrote: > > Looks like a mistake. > > Do you want me to raise a bug report? Yes, please. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kangjoni76 at gmail.com Mon May 9 01:52:27 2016 From: kangjoni76 at gmail.com (kang joni) Date: Mon, 9 May 2016 06:52:27 +0700 Subject: [Development] Stop insertion QTextEdit unicode character. Message-ID: I accidentally was clicking insert Unicode character menu in QTextEdit. How to switch normal again to use ASCII character? I couldn't type any ASCII Character after clicking insert unicode character. My keyboard layout is US letter. And I didn't saw any docs explaining this features in either QTextedit nor QLineEdit? thanks From thiago.macieira at intel.com Mon May 9 07:28:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 08 May 2016 22:28:50 -0700 Subject: [Development] Stop insertion QTextEdit unicode character. In-Reply-To: References: Message-ID: <487604563.VdoPKbh4gJ@tjmaciei-mobl4> On segunda-feira, 9 de maio de 2016 06:52:27 PDT kang joni wrote: > I accidentally was clicking insert Unicode character menu in > QTextEdit. How to switch normal again to use ASCII character? I > couldn't type any ASCII Character after clicking > insert unicode character. My keyboard layout is US letter. And I > didn't saw any docs explaining this features in either QTextedit nor > QLineEdit? The question doesn't make sense. First of all, you probably have the wrong list. This list is for discussion about development _of_ Qt, not _with_ Qt. Second, what "insert Unicode character" menu? I don't see one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Eike.Ziller at qt.io Mon May 9 08:49:39 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 9 May 2016 06:49:39 +0000 Subject: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827414EC3@GL-EXC-01.iesve.com> References: <1577846.z2UKTiSPYj@tjmaciei-mobl4> <3709A7D425EE8C45991DB29EC2FACA8827414CCE@GL-EXC-01.iesve.com> <16262655.LcZiHKsi4R@tjmaciei-mobl4> <3709A7D425EE8C45991DB29EC2FACA8827414EC3@GL-EXC-01.iesve.com> Message-ID: <8241B79A-0D82-489F-ABDD-B92FF5CADAEB@qt.io> > On May 4, 2016, at 7:10 PM, Mark De Wit wrote: > > Hmm, is that proving my point, though? My understanding was that compiling Qt in a namespace and with unique filename was recommended to avoid (minimise) the likelihood of conflicting Qt versions in a single process. > > Is there documentation that states how one should build Qt for release with their own software? The trial & error approaches I have witnessed in the past have not been a positive experience. I think this lists the configure flags that we use for the Qt binary releases ourselves for the different platforms: http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/releases/release-56 Br, Eike > Mark > > -----Original Message----- > From: Development [mailto:development-bounces+mark.dewit=iesve.com at qt-project.org] On Behalf Of Thiago Macieira > Sent: 04 May 2016 17:43 > To: development at qt-project.org > Subject: Re: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4 > > On quarta-feira, 4 de maio de 2016 07:46:41 PDT Mark De Wit wrote: >> The configure flags are poorly documented, and options like qtlibinfix >> (which I understood to be a recommended best practice) isn't even mentioned >> on the configure flag page. > > Because it isn't a recommended best practice. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Eike.Ziller at qt.io Mon May 9 08:54:55 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 9 May 2016 06:54:55 +0000 Subject: [Development] Qt QuickLook plugin In-Reply-To: References: <8B275AEE-E22C-498D-AAF7-5A15432E768D@qt.io> Message-ID: <701F8EDE-8060-4E68-82A2-D5D86342DC46@qt.io> > On May 8, 2016, at 12:47 AM, Samuel Gaist wrote: > > > On 2 mai 2016, at 09:07, Eike Ziller wrote: > >> >>> On May 1, 2016, at 01:47, Jake Petroules wrote: >>> >>> That would be pretty awesome. It's possible we could ship it inside of Qt Creator? You can put them in either ~/Library/QuickLook or in $BUNDLE_CONTENTS/Library/QuickLook > > Sure thing, that's the direction I was looking for if possible :) > > Note that currently it is a really bare bone plugin. If it's made part of Qt Creator, we could maybe implement highlighting using Qt Creator's code model ? > >> >> That made me start wondering why I do see a text preview for .qml files. We do declare these as OSType text in Qt Creator’s Info.plist. >> So I tried https://codereview.qt-project.org/157721 for .pro, .pri, .qbs and .qrc as well, so far without any effect, but maybe that is because of some fancy OS caching of these values? >> >> Br, Eike > > Sorry, I currently don't know what may be the cause of this. The revised patch https://codereview.qt-project.org/157721 makes Quick Look show .pro/.pri/.qbs/.qrc/.ui/.qml/.qdoc/.qdocconf/.creator/.qmlproject files as text. .qml is already also handled by the Info.plist of qml.app (that’s why it already works there). I’ll look into adding the same to qmake/rcc/uic/qbs/qdoc, so one doesn’t even need to have Qt Creator installed. Br, Eike > Samuel > >> >>>> On Apr 30, 2016, at 4:09 PM, Samuel Gaist wrote: >>>> >>>> Hi, >>>> >>>> I wrote a small QuickLook plugin for OS X that allows to get a preview of Qt's .pro, .pri and .qrc files without opening any editor. >>>> >>>> Would there be any interest in making it part of the standard OS X installation ? >>>> >>>> If so, what would be the process to include it ? >>>> >>>> Cheers >>>> Samuel >>>> >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petroules at theqtcompany.com >>> Consulting Services Engineer - The Qt Company >>> Qbs build system evangelist - qbs.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> > -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From kangjoni76 at gmail.com Mon May 9 09:59:16 2016 From: kangjoni76 at gmail.com (kang joni) Date: Mon, 9 May 2016 14:59:16 +0700 Subject: [Development] Stop insertion QTextEdit unicode character. In-Reply-To: References: Message-ID: Sorry for my bad English, Quick grep-ing in qtbase 5.6 src/widgets/widgets/qwidgettextcontrol.cpp at line 3254 just found my case here. I don't know how to use this. And I didnt aware any of docs explaining this. If you right click on editable QLineEdit or QTextEdit there should be "Insert Unicode control character", sorry my former title was bit wrong typo here. So, back to my case whenever I type from ASCII and then accidentally clicking from "Insert Unicode control character" with any selecting LRM,RLM ... etc I didn't know how to switch back to type ASCI I character with exception close app window and reopen it again, and everything would be normal again. This all happen in all Qt apps. From nassian at bitshift-dynamics.de Mon May 9 10:16:19 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Mon, 9 May 2016 10:16:19 +0200 Subject: [Development] Stop insertion QTextEdit unicode character. In-Reply-To: References: Message-ID: <776C89A6-ACF4-4BFB-90D8-32F25D6C2CDB@bitshift-dynamics.de> You see the condition in line 2288: d->interactionFlags & Qt::TextEditable) && QGuiApplication::styleHints()->useRtlExtensions() So, right-to-left writing direction must be active and the input field must be editable. Are you using or do you need RTL writing? If not, you could just disable it as a quick fix. Maybe this context menu should be en-/disableable by the application developer? I don’t know enough about RTL systems, do they need this coding selection? Beste Grüße / Best regards, Alexander Nassian > Am 09.05.2016 um 09:59 schrieb kang joni : > > Sorry for my bad English, Quick grep-ing in qtbase 5.6 > src/widgets/widgets/qwidgettextcontrol.cpp at line 3254 just found my > case here. I don't know how to use this. And I didnt aware any of docs > explaining this. If you right click on editable QLineEdit or QTextEdit > there should be "Insert Unicode control > character", sorry my former title was bit wrong typo here. So, back > to my case whenever I type from ASCII and then accidentally clicking > from "Insert Unicode control > character" with any selecting LRM,RLM ... etc I didn't know how to > switch back to type ASCI I character with exception close app window > and reopen it again, and everything would be normal again. This all > happen in all Qt apps. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon May 9 10:45:48 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 9 May 2016 08:45:48 +0000 Subject: [Development] Heads up - 5.7 string freeze In-Reply-To: References: Message-ID: Hi all, As warned a while ago string freeze is now in effect. Please, no changes to translatable strings from this point, unless approved by the documentation team. Br, Jani ________________________________ From: Jani Heikkinen Sent: Wednesday, April 27, 2016 9:52 AM To: localization at qt-project.org Cc: development at qt-project.org; releasing at qt-project.org Subject: Heads up - 5.7 soft string freeze Hi all, Qt 5.7 beta is out & work towards final release continues. One step on the way is String Freeze which is planned to happen 7th May 2016, see https://wiki.qt.io/Qt-5.7-release. So it is time to start keeping the translatable strings as it is and fix remaining important issues. Br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From klochkov.kirill at gmail.com Mon May 9 11:16:02 2016 From: klochkov.kirill at gmail.com (Kirill Klochkov) Date: Mon, 9 May 2016 12:16:02 +0300 Subject: [Development] Qt 5.6 Crash in QV4::Value::as Message-ID: Hello, I need a suggestion how to narrow down a crash which occurs on Mac 10.11.4, Qt 5.6. I have QQuickView with complex UI structure. When a QQuickView is closed and the second one (with the same qml) opens the app crashes with the following call stack. 1 QV4::QQmlValueTypeWrapper const const * QV4::Value::as() const qv4value_p.h 350 0x1064d7318 2 QQmlBinding::write(QQmlPropertyData const&, QV4::Value const&, bool, QFlags) qqmlbinding.cpp 257 0x1064d5a73 3 QQmlBinding::update(QFlags) qqmlbinding.cpp 191 0x1064d5137 4 QQmlBinding::setEnabled(bool, QFlags) qqmlbinding.cpp 412 0x1064d6b99 5 QQmlObjectCreator::finalize(QQmlInstantiationInterrupt&) qqmlobjectcreator.cpp 1190 0x1064e8483 6 QQmlIncubatorPrivate::incubate(QQmlInstantiationInterrupt&) qqmlincubator.cpp 348 0x1064484a2 7 QQmlIncubationController::incubateFor(int) qqmlincubator.cpp 395 0x106449278 8 QQuickWindowIncubationController::incubate() qquickwindow.cpp 136 0x10480f2a5 9 QQuickWindowIncubationController::timerEvent(QTimerEvent *) qquickwindow.cpp 119 0x104812285 10 QObject::event(QEvent *) qobject.cpp 1237 0x1075df021 11 QApplicationPrivate::notify_helper(QObject *, QEvent *) qapplication.cpp 3714 0x10391563f 12 QApplication::notify(QObject *, QEvent *) qapplication.cpp 3157 0x103917458 13 WoowApplication::notify(QObject *, QEvent *) woowapplication.cpp 342 0x1004d6c17 14 QCoreApplication::notifyInternal2(QObject *, QEvent *) qcoreapplication.cpp 1015 0x107598125 15 QCoreApplication::sendEvent(QObject *, QEvent *) qcoreapplication.h 227 0x10759cdd8 16 QTimerInfoList::activateTimers() qtimerinfo_unix.cpp 637 0x107630cd8 17 QCocoaEventDispatcherPrivate::activateTimersSourceCallback(void *) qcocoaeventdispatcher.mm 119 0x10e14b364 18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 0x7fff953f8881 19 __CFRunLoopDoSources0 0x7fff953d7fbc 20 __CFRunLoopRun 0x7fff953d74df ... Unfortunately, I couldn’t manage to reproduce the crash on a test app. So, maybe one of you could help me to narrow the issue down? PS: I didn’t receive any feedback either from the support nor from the interest mailing list. Thanks, Kirill Klochkov From Tobias.Hunger at qt.io Mon May 9 11:21:21 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Mon, 9 May 2016 09:21:21 +0000 Subject: [Development] [Qt-creator] Nominating Marco Benelli for Approver status In-Reply-To: <1460534818.25741.38.camel@theqtcompany.com> References: <1460534818.25741.38.camel@theqtcompany.com> Message-ID: <1462785678.5572.21.camel@qt.io> Hello all, please welcome Marco Benelli as the newest approver to the Qt project. Best Regards, Tobias On Mi, 2016-04-13 at 08:06 +0000, Hunger Tobias wrote: > Hello Qt Developers, > > I hereby nominate Marco Benelli for Approver status. He has put in a lot of > effort to maintain the QML code inside Qt Creator over the recent month and in > fact is the default assignee for all bugs in that area of Qt Creator. > > He did good work in his area and Qt Creator in general, so I think he has more > than deserved Approver status by now. > > Best Regards, > Tobias --  Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From marc.mutz at kdab.com Mon May 9 11:48:05 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 9 May 2016 11:48:05 +0200 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <4354232.x34ARfPIjD@tjmaciei-mobl4> References: <4354232.x34ARfPIjD@tjmaciei-mobl4> Message-ID: <201605091148.06970.marc.mutz@kdab.com> On Sunday 08 May 2016 01:12:16 Thiago Macieira wrote: > On sábado, 7 de maio de 2016 22:05:32 PDT Nikita Krupenko wrote: > > Re-sending to ml. > > > > > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdevg > > > ame padbackend.cpp:79:67: error: 'fabs' was not declared in this scope > > > > > > flat = fabs(absInfo.flat / double(maxValue - minValue)); > > Missing #include. Already fixed: https://codereview.qt-project.org/151492 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From bogdan at kdab.com Mon May 9 11:55:05 2016 From: bogdan at kdab.com (BogDan Vatra) Date: Mon, 09 May 2016 12:55:05 +0300 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <201605091148.06970.marc.mutz@kdab.com> References: <4354232.x34ARfPIjD@tjmaciei-mobl4> <201605091148.06970.marc.mutz@kdab.com> Message-ID: <1588402.N2GH51aV3q@debian> On Monday 09 May 2016 11:48:05 Marc Mutz wrote: > On Sunday 08 May 2016 01:12:16 Thiago Macieira wrote: > > On sábado, 7 de maio de 2016 22:05:32 PDT Nikita Krupenko wrote: > > > Re-sending to ml. > > > > > > > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qevdev > > > > g > > > > ame padbackend.cpp:79:67: error: 'fabs' was not declared in this scope > > > > > > > > flat = fabs(absInfo.flat / double(maxValue - minValue)); > > > > Missing #include. > > Already fixed: https://codereview.qt-project.org/151492 It was in the wrong branch :) Different fix landed here: https://codereview.qt-project.org/#/c/158320/ Cheers, BogDan. From marc.mutz at kdab.com Mon May 9 12:41:11 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 9 May 2016 12:41:11 +0200 Subject: [Development] [5.7-beta] qtgamepad compile failure In-Reply-To: <1588402.N2GH51aV3q@debian> References: <201605091148.06970.marc.mutz@kdab.com> <1588402.N2GH51aV3q@debian> Message-ID: <201605091241.12989.marc.mutz@kdab.com> On Monday 09 May 2016 11:55:05 BogDan Vatra wrote: > On Monday 09 May 2016 11:48:05 Marc Mutz wrote: > > On Sunday 08 May 2016 01:12:16 Thiago Macieira wrote: > > > On sábado, 7 de maio de 2016 22:05:32 PDT Nikita Krupenko wrote: > > > > Re-sending to ml. > > > > > > > > > /mnt/store/Development/qt5/qtgamepad/src/plugins/gamepads/evdev/qev > > > > > dev g > > > > > ame padbackend.cpp:79:67: error: 'fabs' was not declared in this > > > > > scope > > > > > > > > > > flat = fabs(absInfo.flat / double(maxValue - > > > > > minValue)); > > > > > > Missing #include. > > > > Already fixed: https://codereview.qt-project.org/151492 > > It was in the wrong branch :) > Different fix landed here: https://codereview.qt-project.org/#/c/158320/ I'm pretty sure that two months ago, when my version was merged, there was no 5.7 branch, yet. Otherwise, I can't explain why I submitted to dev, sorry. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From Lars.Knoll at qt.io Mon May 9 13:17:23 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Mon, 9 May 2016 11:17:23 +0000 Subject: [Development] Nominating Edward Welbourne for approver status Message-ID: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> Hi, I'd like to nominate Edward Welbourne for Approver status. He's joined The Qt Company half a year ago, and has been working full time on Qt since. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:edward.welbourne%2540theqtcompany.com+status:merged,n,z And his extensive list of reviews at: https://codereview.qt-project.org/#/q/reviewer:%22Edward+Welbourne+%253Cedward.welbourne%2540theqtcompany.com%253E%22,n,z Cheers, Lars From Simon.Hausmann at qt.io Mon May 9 13:20:28 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 9 May 2016 11:20:28 +0000 Subject: [Development] Nominating Edward Welbourne for approver status In-Reply-To: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> References: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> Message-ID: Hi, +1. Simon ________________________________________ From: Development on behalf of Lars Knoll Sent: Monday, May 9, 2016 1:17:23 PM To: Qt development mailing list Subject: [Development] Nominating Edward Welbourne for approver status Hi, I'd like to nominate Edward Welbourne for Approver status. He's joined The Qt Company half a year ago, and has been working full time on Qt since. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:edward.welbourne%2540theqtcompany.com+status:merged,n,z And his extensive list of reviews at: https://codereview.qt-project.org/#/q/reviewer:%22Edward+Welbourne+%253Cedward.welbourne%2540theqtcompany.com%253E%22,n,z Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at qt.io Mon May 9 13:22:51 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Mon, 9 May 2016 11:22:51 +0000 Subject: [Development] Maintainers for Qt Charts and Data Visualization Message-ID: <64DF698D-AC5E-4EA8-8101-0A8BE32A18F4@qt.io> Hi, Since we now open sourced Charts and Data Visualisation for Qt 5.7, the modules also need a Maintainer. I'd like to propose the two people that have been maintaining these modules while they were developed inside TQtC to continue in this role: Miikka Heikkinen for Charts, and Tomi Korpipää for Data Visualisation. Cheers, Lars From Martin.Smith at qt.io Mon May 9 13:34:58 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 9 May 2016 11:34:58 +0000 Subject: [Development] Nominating Edward Welbourne for approver status In-Reply-To: References: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io>, Message-ID: +1 martin ________________________________________ From: Development on behalf of Simon Hausmann Sent: Monday, May 9, 2016 1:20:28 PM To: Lars Knoll; Qt development mailing list Subject: Re: [Development] Nominating Edward Welbourne for approver status Hi, +1. Simon ________________________________________ From: Development on behalf of Lars Knoll Sent: Monday, May 9, 2016 1:17:23 PM To: Qt development mailing list Subject: [Development] Nominating Edward Welbourne for approver status Hi, I'd like to nominate Edward Welbourne for Approver status. He's joined The Qt Company half a year ago, and has been working full time on Qt since. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:edward.welbourne%2540theqtcompany.com+status:merged,n,z And his extensive list of reviews at: https://codereview.qt-project.org/#/q/reviewer:%22Edward+Welbourne+%253Cedward.welbourne%2540theqtcompany.com%253E%22,n,z Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Mon May 9 13:35:11 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 9 May 2016 11:35:11 +0000 Subject: [Development] [Qt Quick] Automatically restoring focus to last focused item In-Reply-To: References: Message-ID: Thanks for the reply, Andrew. It looks like the contentItem of QQuickWindow is already a focus scope [1]: contentItemPrivate->flags |= QQuickItem::ItemIsFocusScope; Shouldn’t that already work, then? If I set QT_LOGGING_RULES= qt.quick.focus=true, and use the following example, I get the output below: http://pastebin.com/X9JMcpGh This is printed when the application has started: qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: scopeSubFocusItem: QObject(0x0) qt.quick.focus: item: QQuickFocusScope_QML_0(0x1e25bec66c0) qt.quick.focus: activeFocusItem: QObject(0x0) qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QObject(0x0) qt.quick.focus: item: QQuickRootItem(0x1e25bec0000) qt.quick.focus: activeFocusItem: QObject(0x0) qml: activeFocusItem QQuickFocusScope_QML_0(0x1e25bec66c0) This is printed when I open the menu: qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickToolBar(0x1e25bec2dc0) qt.quick.focus: scopeSubFocusItem: QObject(0x0) qt.quick.focus: item: QQuickToolButton(0x1e25bec2a60) qt.quick.focus: activeFocusItem: QQuickFocusScope_QML_0(0x1e25bec66c0) qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: scopeSubFocusItem: QQuickFocusScope_QML_0(0x1e25bec66c0) qt.quick.focus: item: QQuickToolBar(0x1e25bec2dc0) qt.quick.focus: activeFocusItem: QQuickFocusScope_QML_0(0x1e25bec66c0) qml: activeFocusItem QQuickToolButton(0x1e25bec2a60) qml: @@@@@@@@@ clicked menu toolbutton qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: scopeSubFocusItem: QQuickToolBar(0x1e25bec2dc0) qt.quick.focus: item: QQuickPopupItem(0x1e25bec29a0) qt.quick.focus: activeFocusItem: QQuickToolButton(0x1e25bec2a60) qml: activeFocusItem QQuickPopupItem(0x1e25bec29a0) And this is printed when I close the menu: qt.quick.focus: QQuickWindowPrivate::clearFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: item: QQuickPopupItem(0x1e25bec29a0) qt.quick.focus: activeFocusItem: QQuickPopupItem(0x1e25bec29a0) qml: activeFocusItem QQuickRootItem(0x1e25bec0000) qml: @@@@@@@@@ closed menu If I apply the following patch to qtquickcontrols2, the root item becomes the active focus item, and so pressing alt does nothing: diff --git a/src/quicktemplates2/qquickapplicationwindow.cpp b/src/quicktemplates2/qquickapplicationwindow.cpp index 401313d..cb8a2fa 100644 --- a/src/quicktemplates2/qquickapplicationwindow.cpp +++ b/src/quicktemplates2/qquickapplicationwindow.cpp @@ -424,6 +424,7 @@ QQuickItem *QQuickApplicationWindow::contentItem() const QQuickApplicationWindowPrivate *d = const_cast(d_func()); if (!d->contentItem) { d->contentItem = new QQuickItem(QQuickWindow::contentItem()); + d->contentItem->setFlag(QQuickItem::ItemIsFocusScope); d->relayout(); } return d->contentItem; [1] http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/items/qquickwindow.cpp#n483 From: Andrew den Exter [mailto:andrew.den.exter at qinetic.com.au] Sent: Friday, 6 May 2016 1:38 PM To: Mitch Curtis Cc: development at qt-project.org Subject: Re: [Development] [Qt Quick] Automatically restoring focus to last focused item That's a very universal solution to a specific problem and one that's going to have all kinds of unintended consequences. Without knowing why focus was taken from an item and given to another and why that other object relinquished focus it's impossible to know whether focus should be restored to that first item. That memory may have to go back more than one item as well, after all if you open one menu then another then the previous focus item is the first window and that's obviously not what you want to give focus to. What you want to do instead is introduce a FocusScope to ApplicationWindow. If the window's content item is a focus scope then giving focus to a menu which is outside of this scope will not affect focus within the scope, then whatever logic closes the menu can give focus back to the content item and that will implicitly return active focus to your item in the window body. Andrew On Fri, May 6, 2016 at 12:08 AM, Mitch Curtis > wrote: Consider the example below (requires Qt 5.7): import QtQuick 2.6 import QtQuick.Layouts 1.1 import QtQuick.Window 2.2 import QtQuick.Controls 2.0 ApplicationWindow { width: 400 height: 200 visible: true onActiveFocusItemChanged: print("activeFocusItem", activeFocusItem) header: ToolBar { RowLayout { focus: false implicitWidth: children[0].implicitWidth implicitHeight: children[0].implicitHeight ToolButton { text: qsTr("File") onClicked: fileMenu.open() Menu { id: fileMenu y: parent.height MenuItem { text: qsTr("New") } MenuItem { text: qsTr("open") } MenuItem { text: qsTr("Close") } } } } } FocusScope { id: focusScope focus: true anchors.fill: parent property bool toggled: false onToggledChanged: print("toggled", toggled) Keys.onPressed: { if (event.modifiers === Qt.AltModifier) { focusScope.toggled = true; } } Keys.onReleased: { if ((event.modifiers === Qt.AltModifier || event.key === Qt.Key_Alt) && !event.isAutoRepeat) { focusScope.toggled = false; } } RowLayout { anchors.centerIn: parent Button { id: penButton text: qsTr("Pen") highlighted: !focusScope.toggled } Button { id: eyedropperButton text: qsTr("Eyedropper") highlighted: focusScope.toggled } } } } The idea is that holding the Alt key down will toggle between two "modes". The mode is indicated by a highlighted button. Try switching between the buttons. Now open the menu by clicking the "File" button. The menu will receive focus and the focus scope will lose it. If you then close the menu and try to switch between the buttons again, it won't work because the focus scope never regained focus (the root item now has it). This is explained here [1]: "When a QML Item explicitly relinquishes focus (by setting its focus property to false while it has active focus), the system does not automatically select another type to receive focus. That is, it is possible for there to be no currently active focus." I'm not sure if "explicitly relinquishes focus" is exactly what's happening here, though. The FocusScope loses focus because something else was open temporarily. So now the developer has no other option than to listen to e.g. the menu visibility changes and explicitly set focus on the FocusScope accordingly. That's pretty gross if you ask me. I think we can do better. Specifically, I think that we should remember the last focused item, and give that focus, rather than give it to the root item. The question is, would it be an acceptable change for Qt 5? I'd assume that users are already working around this anyway, and so the fix wouldn't hurt. [1] http://doc.qt.io/qt-5/qtquick-input-focus.html _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon May 9 13:48:54 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 9 May 2016 13:48:54 +0200 Subject: [Development] Nominating Edward Welbourne for approver status In-Reply-To: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> References: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> Message-ID: <201605091348.56213.marc.mutz@kdab.com> On Monday 09 May 2016 13:17:23 Lars Knoll wrote: > Hi, > > I'd like to nominate Edward Welbourne for Approver status. He's joined The > Qt Company half a year ago, and has been working full time on Qt since. So that's why he never gave a +2 :) +1 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From andrew.den.exter at qinetic.com.au Mon May 9 15:17:40 2016 From: andrew.den.exter at qinetic.com.au (Andrew den Exter) Date: Mon, 9 May 2016 23:17:40 +1000 Subject: [Development] [Qt Quick] Automatically restoring focus to last focused item In-Reply-To: References: Message-ID: I was referring to ApplicationWindow's contentItem which is what you've patched in qtquickcontrols2. For items within the contentItem to have focus at startup you will also want to give that contentItem focus when it is constructed. Add d->contentItem->setFocus(true) to your patch and pressing alt will work again. Then to restore focus when the menu is closed I guess in either QQuickPopupPrivate::prepareExitTransition() or QQuickPopupPrivate:: finalizeExitTransition() you want again call setFocus(true) on ApplicationWindow's contentItem again. This works because making an item a focus scope isolates all of it's children from focus changes around it. With your example when forceActiveFocus() is called on the menu it removes focus from the contentItem scope breaking the active focus chain to focusScope but leaves the focus chain within contentItem intact so focusScope.focus is still true but focusScope.activeFocus is false. If the menu is closed and setFocus(true) is called on ApplicationWindow.contentItem then that restores the missing link in the active focus chain to focusScope and you're back to where you started. On Mon, May 9, 2016 at 9:35 PM, Mitch Curtis wrote: > Thanks for the reply, Andrew. > > > > It looks like the contentItem of QQuickWindow is already a focus scope [1]: > > > > contentItemPrivate->flags |= QQuickItem::ItemIsFocusScope; > > > > Shouldn’t that already work, then? > > > > If I set QT_LOGGING_RULES= qt.quick.focus=true, and use the following > example, I get the output below: > > > > http://pastebin.com/X9JMcpGh > > > > This is printed when the application has started: > > > > qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): > > qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) > > qt.quick.focus: scopeSubFocusItem: QObject(0x0) > > qt.quick.focus: item: QQuickFocusScope_QML_0(0x1e25bec66c0) > > qt.quick.focus: activeFocusItem: QObject(0x0) > > qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): > > qt.quick.focus: scope: QObject(0x0) > > qt.quick.focus: item: QQuickRootItem(0x1e25bec0000) > > qt.quick.focus: activeFocusItem: QObject(0x0) > > qml: activeFocusItem QQuickFocusScope_QML_0(0x1e25bec66c0) > > > > This is printed when I open the menu: > > > > qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): > > qt.quick.focus: scope: QQuickToolBar(0x1e25bec2dc0) > > qt.quick.focus: scopeSubFocusItem: QObject(0x0) > > qt.quick.focus: item: QQuickToolButton(0x1e25bec2a60) > > qt.quick.focus: activeFocusItem: > QQuickFocusScope_QML_0(0x1e25bec66c0) > > qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): > > qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) > > qt.quick.focus: scopeSubFocusItem: > QQuickFocusScope_QML_0(0x1e25bec66c0) > > qt.quick.focus: item: QQuickToolBar(0x1e25bec2dc0) > > qt.quick.focus: activeFocusItem: > QQuickFocusScope_QML_0(0x1e25bec66c0) > > qml: activeFocusItem QQuickToolButton(0x1e25bec2a60) > > qml: @@@@@@@@@ clicked menu toolbutton > > qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): > > qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) > > qt.quick.focus: scopeSubFocusItem: QQuickToolBar(0x1e25bec2dc0) > > qt.quick.focus: item: QQuickPopupItem(0x1e25bec29a0) > > qt.quick.focus: activeFocusItem: QQuickToolButton(0x1e25bec2a60) > > qml: activeFocusItem QQuickPopupItem(0x1e25bec29a0) > > > > And this is printed when I close the menu: > > > > qt.quick.focus: QQuickWindowPrivate::clearFocusInScope(): > > qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) > > qt.quick.focus: item: QQuickPopupItem(0x1e25bec29a0) > > qt.quick.focus: activeFocusItem: QQuickPopupItem(0x1e25bec29a0) > > qml: activeFocusItem QQuickRootItem(0x1e25bec0000) > > qml: @@@@@@@@@ closed menu > > > > If I apply the following patch to qtquickcontrols2, the root item becomes > the active focus item, and so pressing alt does nothing: > > > > diff --git a/src/quicktemplates2/qquickapplicationwindow.cpp > b/src/quicktemplates2/qquickapplicationwindow.cpp > > index 401313d..cb8a2fa 100644 > > --- a/src/quicktemplates2/qquickapplicationwindow.cpp > > +++ b/src/quicktemplates2/qquickapplicationwindow.cpp > > @@ -424,6 +424,7 @@ QQuickItem > *QQuickApplicationWindow::contentItem() const > > QQuickApplicationWindowPrivate *d = > const_cast(d_func()); > > if (!d->contentItem) { > > d->contentItem = new > QQuickItem(QQuickWindow::contentItem()); > > + d->contentItem->setFlag(QQuickItem::ItemIsFocusScope); > > d->relayout(); > > } > > return d->contentItem; > > > > [1] > http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/items/qquickwindow.cpp#n483 > > > > > > *From:* Andrew den Exter [mailto:andrew.den.exter at qinetic.com.au] > *Sent:* Friday, 6 May 2016 1:38 PM > *To:* Mitch Curtis > *Cc:* development at qt-project.org > *Subject:* Re: [Development] [Qt Quick] Automatically restoring focus to > last focused item > > > > That's a very universal solution to a specific problem and one that's > going to have all kinds of unintended consequences. Without knowing why > focus was taken from an item and given to another and why that other object > relinquished focus it's impossible to know whether focus should be restored > to that first item. That memory may have to go back more than one item as > well, after all if you open one menu then another then the previous focus > item is the first window and that's obviously not what you want to give > focus to. > > > > What you want to do instead is introduce a FocusScope to > ApplicationWindow. If the window's content item is a focus scope then > giving focus to a menu which is outside of this scope will not affect focus > within the scope, then whatever logic closes the menu can give focus back > to the content item and that will implicitly return active focus to your > item in the window body. > > > > > > Andrew > > > > > > On Fri, May 6, 2016 at 12:08 AM, Mitch Curtis wrote: > > Consider the example below (requires Qt 5.7): > > import QtQuick 2.6 > import QtQuick.Layouts 1.1 > import QtQuick.Window 2.2 > import QtQuick.Controls 2.0 > > ApplicationWindow { > width: 400 > height: 200 > visible: true > > onActiveFocusItemChanged: print("activeFocusItem", activeFocusItem) > > header: ToolBar { > RowLayout { > focus: false > implicitWidth: children[0].implicitWidth > implicitHeight: children[0].implicitHeight > > ToolButton { > text: qsTr("File") > onClicked: fileMenu.open() > > Menu { > id: fileMenu > y: parent.height > > MenuItem { > text: qsTr("New") > } > MenuItem { > text: qsTr("open") > } > MenuItem { > text: qsTr("Close") > } > } > } > } > } > > FocusScope { > id: focusScope > focus: true > anchors.fill: parent > > property bool toggled: false > onToggledChanged: print("toggled", toggled) > > Keys.onPressed: { > if (event.modifiers === Qt.AltModifier) { > focusScope.toggled = true; > } > } > Keys.onReleased: { > if ((event.modifiers === Qt.AltModifier || event.key === > Qt.Key_Alt) && !event.isAutoRepeat) { > focusScope.toggled = false; > } > } > > RowLayout { > anchors.centerIn: parent > > Button { > id: penButton > text: qsTr("Pen") > highlighted: !focusScope.toggled > } > Button { > id: eyedropperButton > text: qsTr("Eyedropper") > highlighted: focusScope.toggled > } > } > } > } > > The idea is that holding the Alt key down will toggle between two "modes". > The mode is indicated by a highlighted button. > > Try switching between the buttons. Now open the menu by clicking the > "File" button. The menu will receive focus and the focus scope will lose > it. If you then close the menu and try to switch between the buttons again, > it won't work because the focus scope never regained focus (the root item > now has it). This is explained here [1]: > > "When a QML Item explicitly relinquishes focus (by setting its focus > property to false while it has active focus), the system does not > automatically select another type to receive focus. That is, it is possible > for there to be no currently active focus." > > I'm not sure if "explicitly relinquishes focus" is exactly what's > happening here, though. The FocusScope loses focus because something else > was open temporarily. So now the developer has no other option than to > listen to e.g. the menu visibility changes and explicitly set focus on the > FocusScope accordingly. That's pretty gross if you ask me. I think we can > do better. Specifically, I think that we should remember the last focused > item, and give that focus, rather than give it to the root item. The > question is, would it be an acceptable change for Qt 5? I'd assume that > users are already working around this anyway, and so the fix wouldn't hurt. > > [1] http://doc.qt.io/qt-5/qtquick-input-focus.html > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at qt.io Mon May 9 14:32:30 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 9 May 2016 14:32:30 +0200 Subject: [Development] Qt CI reliability In-Reply-To: <2760300.rZfUxo7XgH@cartman> References: <4166383.CnvrWBLNsi@titan> <6885742.Lm1y6c2V3b@42> <2760300.rZfUxo7XgH@cartman> Message-ID: <1955448.mnmWNNsufe@42> > Determining architecture... () > make: Warning: File `../../../qt/qtbase/config.tests/arch/arch.pro' has > modification time 1.3e+03 s in the future > /home/qt/work/build/bin/qmake -qtconf /home/qt/work/build/bin/qt.conf > -nocache -spec /home/qt/work/qt/qtbase/mkspecs/linux-g++ LIBS+= > QMAKE_CXXFLAGS+= INCLUDEPATH+= CONFIG-=app_bundle -o Makefile > ../../../qt/qtbase/config.tests/arch/arch.pro > ... > > agent:2016/05/05 13:07:20 build.go:221: Killed process after timeout (total > time) > agent:2016/05/05 13:07:20 agent.go:170: Build failed > agent:2016/05/05 13:07:20 agent.go:127: ERROR building: Timeout after 5m0s: > Maximum duration reached > agent:2016/05/05 13:07:20 build.go:158: Error reading from stdout/err: > Timeout after 5m0s: Maximum duration reached > > Sean Date and time on nodes was out of sync. Now they are still out of sync but it should not affect the build anymore, while unziping source code we change ctime and atime 30 years to the past. The "fix" is deployed, if you see the problem again ping me. Cheers, Jędrek From thiago.macieira at intel.com Mon May 9 18:14:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 09 May 2016 09:14:26 -0700 Subject: [Development] Stop insertion QTextEdit unicode character. In-Reply-To: References: Message-ID: <3538831.1hjuys90CF@tjmaciei-mobl4> On segunda-feira, 9 de maio de 2016 14:59:16 PDT kang joni wrote: > If you right click on editable QLineEdit or QTextEdit > there should be "Insert Unicode control > character" I don't see that option. Is that OS-specific? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon May 9 18:15:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 09 May 2016 09:15:26 -0700 Subject: [Development] Qt 5.6 Crash in QV4::Value::as In-Reply-To: References: Message-ID: <2200549.Uf8dhuRxVT@tjmaciei-mobl4> On segunda-feira, 9 de maio de 2016 12:16:02 PDT Kirill Klochkov wrote: > I need a suggestion how to narrow down a crash which occurs on Mac 10.11.4, > Qt 5.6. Try it on Linux with Valgrind. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon May 9 18:17:06 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 09 May 2016 09:17:06 -0700 Subject: [Development] Maintainers for Qt Charts and Data Visualization In-Reply-To: <64DF698D-AC5E-4EA8-8101-0A8BE32A18F4@qt.io> References: <64DF698D-AC5E-4EA8-8101-0A8BE32A18F4@qt.io> Message-ID: <1539336.qp7NTnEj3y@tjmaciei-mobl4> On segunda-feira, 9 de maio de 2016 11:22:51 PDT Lars Knoll wrote: > Hi, > > Since we now open sourced Charts and Data Visualisation for Qt 5.7, the > modules also need a Maintainer. I'd like to propose the two people that > have been maintaining these modules while they were developed inside TQtC > to continue in this role: Miikka Heikkinen for Charts, and Tomi Korpipää > for Data Visualisation. Can someone who has worked with Mikka and Tomi and can confirm they've worked on the module do the +1? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon May 9 18:17:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 09 May 2016 09:17:20 -0700 Subject: [Development] Nominating Edward Welbourne for approver status In-Reply-To: <201605091348.56213.marc.mutz@kdab.com> References: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> <201605091348.56213.marc.mutz@kdab.com> Message-ID: <1580165.AytXQIa5FC@tjmaciei-mobl4> On segunda-feira, 9 de maio de 2016 13:48:54 PDT Marc Mutz wrote: > On Monday 09 May 2016 13:17:23 Lars Knoll wrote: > > Hi, > > > > I'd like to nominate Edward Welbourne for Approver status. He's joined The > > Qt Company half a year ago, and has been working full time on Qt since. > > So that's why he never gave a +2 :) > > +1 Indeed. +1 too -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Mon May 9 20:41:33 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 9 May 2016 20:41:33 +0200 Subject: [Development] Documentation for QPagedPrintDevice::setPageSize should specify a unit` In-Reply-To: <0EC3BE35-21D5-42A9-AF97-EB95F67AC438@pasco.com> References: <57B43E05-46FB-40A3-8B58-E5D1EF5CA050@pasco.com> <572AE2C9.1080906@familiesomers.nl> <0EC3BE35-21D5-42A9-AF97-EB95F67AC438@pasco.com> Message-ID: <5730D9DD.3000506@familiesomers.nl> Hi Steve, Thanks for actually stepping up the plate to create a contribution! It looks fine to me, but I cannot approve this myself. https://codereview.qt-project.org/158402 André Op 05/05/2016 om 19:34 schreef Steve Schilz: > Hi Andre, > > Challenge Accepted! > I have looked at this before and found it a lot to get set up. I really need to get over the hump so that I can do this. > If I understand correctly, docs are generated from comments in the source code… I have JIRA and Gerrit accounts, and am familiar with downloading building Qt. > > > So my next steps are > * Accept the contribution agreement > * Clone Qt - Which branch? 5.8? > * prepare a patch altering the docs in the source code comments, submit to code review… > > **** QUESTION ***** Who do I put as reviewer for this change? > > > Steve Schilz > PASCO scientific - think science > > > > > > > > > > On 5/4/16, 11:06 PM, "André Somers" wrote: > >> I think it does make sense. How about a making a small contribution to >> Qt to fix this? >> >> André >> >> Op 05/05/2016 om 01:25 schreef Steve Schilz: >>> Oops, I ment QTextDocument::setPageSize (http://doc.qt.io/qt-5/qtextdocument.html#pageSize-prop) >>> Does that make more sense? >>> >>> >>> Steve Schilz >>> PASCO scientific - think science >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 5/4/16, 2:17 PM, "Giuseppe D'Angelo" wrote: >>> >>>> Hi, >>>> >>>> On Wed, May 4, 2016 at 10:09 PM, Steve Schilz wrote: >>>>> The doc is confusing because it does not specify a unit for the input >>>>> parameter “pageSize" >>>> The parameter is of type QPageSize, which has multiple setters and >>>> constructors. Which one(s) is missing the unit specification? >>>> >>>> Thanks, >>>> -- >>>> Giuseppe D'Angelo >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Mon May 9 22:04:53 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 9 May 2016 20:04:53 +0000 Subject: [Development] Nominating Edward Welbourne for approver status In-Reply-To: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> References: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> Message-ID: <98541595-1C42-4A3E-B447-33A228F002E5@qt.io> On May 9, 2016, at 13:17, Lars Knoll wrote: > Hi, > > I'd like to nominate Edward Welbourne for Approver status. He's joined The Qt Company half a year ago, and has been working full time on Qt since. > > Here is his gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:edward.welbourne%2540theqtcompany.com+status:merged,n,z > > > And his extensive list of reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Edward+Welbourne+%253Cedward.welbourne%2540theqtcompany.com%253E%22,n,z > +1 From timur.pocheptsov at qt.io Tue May 10 05:21:43 2016 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Tue, 10 May 2016 03:21:43 +0000 Subject: [Development] Nominating Edward Welbourne for approver status In-Reply-To: <98541595-1C42-4A3E-B447-33A228F002E5@qt.io> References: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io>, <98541595-1C42-4A3E-B447-33A228F002E5@qt.io> Message-ID: +1 ________________________________________ From: Development on behalf of Shawn Rutledge Sent: Monday, May 9, 2016 10:04:53 PM To: Qt development mailing list Subject: Re: [Development] Nominating Edward Welbourne for approver status On May 9, 2016, at 13:17, Lars Knoll wrote: > Hi, > > I'd like to nominate Edward Welbourne for Approver status. He's joined The Qt Company half a year ago, and has been working full time on Qt since. > > Here is his gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:edward.welbourne%2540theqtcompany.com+status:merged,n,z > > > And his extensive list of reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Edward+Welbourne+%253Cedward.welbourne%2540theqtcompany.com%253E%22,n,z > +1 _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From pasi.keranen at qt.io Tue May 10 07:57:31 2016 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Tue, 10 May 2016 05:57:31 +0000 Subject: [Development] Maintainers for Qt Charts and Data Visualization Message-ID: <95E04B9E-60FB-4BCA-AC5E-1B525F020AF1@qt.io> Absolute, definite +1 for this! It’s long overdue :) Cheers, Pasi On 09/05/16 14:22, "Development on behalf of Lars Knoll" wrote: >Hi, > >Since we now open sourced Charts and Data Visualisation for Qt 5.7, the modules also need a Maintainer. I'd like to propose the two people that have been maintaining these modules while they were developed inside TQtC to continue in this role: Miikka Heikkinen for Charts, and Tomi Korpipää for Data Visualisation. > >Cheers, >Lars > > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From andy.shaw at qt.io Tue May 10 08:44:09 2016 From: andy.shaw at qt.io (Andy Shaw) Date: Tue, 10 May 2016 06:44:09 +0000 Subject: [Development] Maintainers for Qt Charts and Data Visualization In-Reply-To: <95E04B9E-60FB-4BCA-AC5E-1B525F020AF1@qt.io> References: <95E04B9E-60FB-4BCA-AC5E-1B525F020AF1@qt.io> Message-ID: +1 from me too, I have worked with them on it internally too so can verify that. Andy ________________________________________ Fra: Development på vegne av Pasi Keränen Sendt: 10. mai 2016 07:57:31 Til: Lars Knoll; Qt development mailing list Emne: Re: [Development] Maintainers for Qt Charts and Data Visualization Absolute, definite +1 for this! It’s long overdue :) Cheers, Pasi On 09/05/16 14:22, "Development on behalf of Lars Knoll" wrote: >Hi, > >Since we now open sourced Charts and Data Visualisation for Qt 5.7, the modules also need a Maintainer. I'd like to propose the two people that have been maintaining these modules while they were developed inside TQtC to continue in this role: Miikka Heikkinen for Charts, and Tomi Korpipää for Data Visualisation. > >Cheers, >Lars > > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Tue May 10 09:51:50 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 10 May 2016 07:51:50 +0000 Subject: [Development] Stop insertion QTextEdit unicode character. In-Reply-To: <3538831.1hjuys90CF@tjmaciei-mobl4> References: , <3538831.1hjuys90CF@tjmaciei-mobl4> Message-ID: Hi, It's dependent on the useRtlExtensions() hint in the style: http://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/widgets/qwidgettextcontrol.cpp#n2286 Simon ________________________________________ From: Development on behalf of Thiago Macieira Sent: Monday, May 9, 2016 6:14:26 PM To: development at qt-project.org Subject: Re: [Development] Stop insertion QTextEdit unicode character. On segunda-feira, 9 de maio de 2016 14:59:16 PDT kang joni wrote: > If you right click on editable QLineEdit or QTextEdit > there should be "Insert Unicode control > character" I don't see that option. Is that OS-specific? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Tue May 10 10:45:25 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 10 May 2016 08:45:25 +0000 Subject: [Development] [Qt Quick] Automatically restoring focus to last focused item In-Reply-To: References: Message-ID: Thanks Andrew, I’ll give that a go. For anyone who is interested, I’ve created QTBUG-53275 to track this. From: Andrew den Exter [mailto:andrew.den.exter at qinetic.com.au] Sent: Monday, 9 May 2016 3:18 PM To: Mitch Curtis Cc: development at qt-project.org Subject: Re: [Development] [Qt Quick] Automatically restoring focus to last focused item I was referring to ApplicationWindow's contentItem which is what you've patched in qtquickcontrols2. For items within the contentItem to have focus at startup you will also want to give that contentItem focus when it is constructed. Add d->contentItem->setFocus(true) to your patch and pressing alt will work again. Then to restore focus when the menu is closed I guess in either QQuickPopupPrivate::prepareExitTransition() or QQuickPopupPrivate::finalizeExitTransition() you want again call setFocus(true) on ApplicationWindow's contentItem again. This works because making an item a focus scope isolates all of it's children from focus changes around it. With your example when forceActiveFocus() is called on the menu it removes focus from the contentItem scope breaking the active focus chain to focusScope but leaves the focus chain within contentItem intact so focusScope.focus is still true but focusScope.activeFocus is false. If the menu is closed and setFocus(true) is called on ApplicationWindow.contentItem then that restores the missing link in the active focus chain to focusScope and you're back to where you started. On Mon, May 9, 2016 at 9:35 PM, Mitch Curtis > wrote: Thanks for the reply, Andrew. It looks like the contentItem of QQuickWindow is already a focus scope [1]: contentItemPrivate->flags |= QQuickItem::ItemIsFocusScope; Shouldn’t that already work, then? If I set QT_LOGGING_RULES= qt.quick.focus=true, and use the following example, I get the output below: http://pastebin.com/X9JMcpGh This is printed when the application has started: qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: scopeSubFocusItem: QObject(0x0) qt.quick.focus: item: QQuickFocusScope_QML_0(0x1e25bec66c0) qt.quick.focus: activeFocusItem: QObject(0x0) qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QObject(0x0) qt.quick.focus: item: QQuickRootItem(0x1e25bec0000) qt.quick.focus: activeFocusItem: QObject(0x0) qml: activeFocusItem QQuickFocusScope_QML_0(0x1e25bec66c0) This is printed when I open the menu: qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickToolBar(0x1e25bec2dc0) qt.quick.focus: scopeSubFocusItem: QObject(0x0) qt.quick.focus: item: QQuickToolButton(0x1e25bec2a60) qt.quick.focus: activeFocusItem: QQuickFocusScope_QML_0(0x1e25bec66c0) qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: scopeSubFocusItem: QQuickFocusScope_QML_0(0x1e25bec66c0) qt.quick.focus: item: QQuickToolBar(0x1e25bec2dc0) qt.quick.focus: activeFocusItem: QQuickFocusScope_QML_0(0x1e25bec66c0) qml: activeFocusItem QQuickToolButton(0x1e25bec2a60) qml: @@@@@@@@@ clicked menu toolbutton qt.quick.focus: QQuickWindowPrivate::setFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: scopeSubFocusItem: QQuickToolBar(0x1e25bec2dc0) qt.quick.focus: item: QQuickPopupItem(0x1e25bec29a0) qt.quick.focus: activeFocusItem: QQuickToolButton(0x1e25bec2a60) qml: activeFocusItem QQuickPopupItem(0x1e25bec29a0) And this is printed when I close the menu: qt.quick.focus: QQuickWindowPrivate::clearFocusInScope(): qt.quick.focus: scope: QQuickRootItem(0x1e25bec0000) qt.quick.focus: item: QQuickPopupItem(0x1e25bec29a0) qt.quick.focus: activeFocusItem: QQuickPopupItem(0x1e25bec29a0) qml: activeFocusItem QQuickRootItem(0x1e25bec0000) qml: @@@@@@@@@ closed menu If I apply the following patch to qtquickcontrols2, the root item becomes the active focus item, and so pressing alt does nothing: diff --git a/src/quicktemplates2/qquickapplicationwindow.cpp b/src/quicktemplates2/qquickapplicationwindow.cpp index 401313d..cb8a2fa 100644 --- a/src/quicktemplates2/qquickapplicationwindow.cpp +++ b/src/quicktemplates2/qquickapplicationwindow.cpp @@ -424,6 +424,7 @@ QQuickItem *QQuickApplicationWindow::contentItem() const QQuickApplicationWindowPrivate *d = const_cast(d_func()); if (!d->contentItem) { d->contentItem = new QQuickItem(QQuickWindow::contentItem()); + d->contentItem->setFlag(QQuickItem::ItemIsFocusScope); d->relayout(); } return d->contentItem; [1] http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/items/qquickwindow.cpp#n483 From: Andrew den Exter [mailto:andrew.den.exter at qinetic.com.au] Sent: Friday, 6 May 2016 1:38 PM To: Mitch Curtis > Cc: development at qt-project.org Subject: Re: [Development] [Qt Quick] Automatically restoring focus to last focused item That's a very universal solution to a specific problem and one that's going to have all kinds of unintended consequences. Without knowing why focus was taken from an item and given to another and why that other object relinquished focus it's impossible to know whether focus should be restored to that first item. That memory may have to go back more than one item as well, after all if you open one menu then another then the previous focus item is the first window and that's obviously not what you want to give focus to. What you want to do instead is introduce a FocusScope to ApplicationWindow. If the window's content item is a focus scope then giving focus to a menu which is outside of this scope will not affect focus within the scope, then whatever logic closes the menu can give focus back to the content item and that will implicitly return active focus to your item in the window body. Andrew On Fri, May 6, 2016 at 12:08 AM, Mitch Curtis > wrote: Consider the example below (requires Qt 5.7): import QtQuick 2.6 import QtQuick.Layouts 1.1 import QtQuick.Window 2.2 import QtQuick.Controls 2.0 ApplicationWindow { width: 400 height: 200 visible: true onActiveFocusItemChanged: print("activeFocusItem", activeFocusItem) header: ToolBar { RowLayout { focus: false implicitWidth: children[0].implicitWidth implicitHeight: children[0].implicitHeight ToolButton { text: qsTr("File") onClicked: fileMenu.open() Menu { id: fileMenu y: parent.height MenuItem { text: qsTr("New") } MenuItem { text: qsTr("open") } MenuItem { text: qsTr("Close") } } } } } FocusScope { id: focusScope focus: true anchors.fill: parent property bool toggled: false onToggledChanged: print("toggled", toggled) Keys.onPressed: { if (event.modifiers === Qt.AltModifier) { focusScope.toggled = true; } } Keys.onReleased: { if ((event.modifiers === Qt.AltModifier || event.key === Qt.Key_Alt) && !event.isAutoRepeat) { focusScope.toggled = false; } } RowLayout { anchors.centerIn: parent Button { id: penButton text: qsTr("Pen") highlighted: !focusScope.toggled } Button { id: eyedropperButton text: qsTr("Eyedropper") highlighted: focusScope.toggled } } } } The idea is that holding the Alt key down will toggle between two "modes". The mode is indicated by a highlighted button. Try switching between the buttons. Now open the menu by clicking the "File" button. The menu will receive focus and the focus scope will lose it. If you then close the menu and try to switch between the buttons again, it won't work because the focus scope never regained focus (the root item now has it). This is explained here [1]: "When a QML Item explicitly relinquishes focus (by setting its focus property to false while it has active focus), the system does not automatically select another type to receive focus. That is, it is possible for there to be no currently active focus." I'm not sure if "explicitly relinquishes focus" is exactly what's happening here, though. The FocusScope loses focus because something else was open temporarily. So now the developer has no other option than to listen to e.g. the menu visibility changes and explicitly set focus on the FocusScope accordingly. That's pretty gross if you ask me. I think we can do better. Specifically, I think that we should remember the last focused item, and give that focus, rather than give it to the root item. The question is, would it be an acceptable change for Qt 5? I'd assume that users are already working around this anyway, and so the fix wouldn't hurt. [1] http://doc.qt.io/qt-5/qtquick-input-focus.html _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frederik.Gladhorn at qt.io Tue May 10 14:12:44 2016 From: Frederik.Gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 10 May 2016 12:12:44 +0000 Subject: [Development] CI breakage Message-ID: Hi all, sadly we messed up a bit and have been ignoring build results for a week on Windows :( This nicely shows the value of the continuous integration system, Qt is broken on some Windows build configurations. In order to get the situation under control, we'll revert the offending patch, temporarily breaking builds. If you get weird errors on Windows builds/tests that don't make sense, that might be the reason. Bear with us, we'll all try to get everything working again ASAP. (I take the blame as usual ;)) Cheers, Frederik -------------- next part -------------- An HTML attachment was scrubbed... URL: From krnekit at gmail.com Tue May 10 16:21:04 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Tue, 10 May 2016 17:21:04 +0300 Subject: [Development] [Announce] Qt 5.7.0 Beta released In-Reply-To: <5718D0C5.4000705@rpzdesign.com> References: <5718D0C5.4000705@rpzdesign.com> Message-ID: 2016-04-21 16:08 GMT+03:00 md at rpzdesign.com : > 5) Decouple the GUI/QML from NetworkResourceManager. The NetworkResourceManager should be an optional component, not required for every project. > If you need to download QML using an URL, provide a bridge class to perform that. Isn't it what's you need? https://code.qt.io/cgit/qt/qtdeclarative.git/commit/?id=c7ac28fa354b96de37dc6cde5e3728da8daaacbb From thiago.macieira at intel.com Tue May 10 20:30:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 10 May 2016 11:30:30 -0700 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? Message-ID: <1870465.YMDxbbm7c5@tjmaciei-mobl4> I've just found out that MSVC 2015 Update 2 added the compiler option /utf-8, which is documented as: /utf-8 set source and execution character set to UTF-8 See https://blogs.msdn.microsoft.com/vcblog/2016/02/22/new-options-for-managing-character-sets-in-the-microsoft-cc-compiler/ I'd like to turn that option on for at least all of our source code, Once we can drop support for MSVC versions older than 2015 Update 2, we'll be able to write proper Unicode literals in all systems. The question is: do I turn it on for user code too? Or just ours? See also the bottom of the blog, that says: > In a future major release of the compiler, we would like to change default > handling of BOM-less files to assume UTF-8 Proof: The following file is encoded in UTF-8, as required for Qt sources. $ cat test.cpp extern "C" { extern const char s[] = "Résumé"; extern const char s8[] = u8"Résumé"; extern const char16_t su[] = u"Résumé"; extern const wchar_t sl[] = L"Résumé"; } Compiled with the /utf-8 option, the data is in the form we'd expect: s DB 'R', 0c3H, 0a9H, 'sum', 0c3H, 0a9H, 00H ORG $+7 s8 DB 'R', 0c3H, 0a9H, 'sum', 0c3H, 0a9H, 00H ORG $+7 su DB 'R', 00H, 0e9H, 00H, 's', 00H, 'u', 00H, 'm', 00H, 0e9H, 00H DB 00H, 00H ORG $+2 sl DB 'R', 00H, 0e9H, 00H, 's', 00H, 'u', 00H, 'm', 00H, 0e9H, 00H DB 00H, 00H Which is the same as what we've got on Linux and OS X with Clang and GCC (assembly listing from Clang on Linux): s: .asciz "R\303\251sum\303\251" .size s, 9 .type s8, at object # @s8 .globl s8 s8: .asciz "R\303\251sum\303\251" .size s8, 9 .type su, at object # @su .globl su .align 2 su: .short 82 # 0x52 .short 233 # 0xe9 .short 115 # 0x73 .short 117 # 0x75 .short 109 # 0x6d .short 233 # 0xe9 .short 0 # 0x0 .size su, 14 Without that option, we had: s DB 'R', 0c3H, 0a9H, 'sum', 0c3H, 0a9H, 00H ORG $+7 s8 DB 'R', 0c3H, 083H, 0c2H, 0a9H, 'sum', 0c3H, 083H, 0c2H, 0a9H DB 00H ORG $+3 su DB 'R', 00H, 0c3H, 00H, 0a9H, 00H, 's', 00H, 'u', 00H, 'm', 00H DB 0c3H, 00H, 0a9H, 00H, 00H, 00H ORG $+6 sl DB 'R', 00H, 0c3H, 00H, 0a9H, 00H, 's', 00H, 'u', 00H, 'm', 00H DB 0c3H, 00H, 0a9H, 00H, 00H, 00H The above contains Mojibake for the s8, su and sl variables. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Wed May 11 00:59:14 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 10 May 2016 19:59:14 -0300 Subject: [Development] Acceptable CC licenses for Qt Message-ID: <4422295.9qpMLJGLRa@luna> Hi! I would like to know what are the acceptable Creative Common licenses for Qt. The reason why I'm asking is because qt3d's examples/qt3d/audio-visualizer- qml/music/tiltshifted_lost_neon_sun.mp3 is under the CC-BY-ND license, which is undistributable by Debian, Ubuntu and derivatives. Qt 3D maintainers: would you accept a different licensed file for this example? Thanks in advance, Lisandro. -- Without us [Free Software developers], people would study computer science and programming without ever having seen a real program in its entirety. That's like becoming writers without ever having read a complete book. Matthias Ettrich, founder of the KDE project. http://www.efytimes.com/efytimes/25412/news.htm Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From Lars.Knoll at qt.io Wed May 11 09:59:38 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Wed, 11 May 2016 07:59:38 +0000 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? In-Reply-To: <1870465.YMDxbbm7c5@tjmaciei-mobl4> References: <1870465.YMDxbbm7c5@tjmaciei-mobl4> Message-ID: Finally! We should certainly turn it on for Qt. User code is a bit more sensitive. What are we currently doing on the other compilers? Are we assuming utf8 as the input encoding by default? If yes, we should aim for consistency and turn it on for user code on msvc2015 as well, but there should be an option to disable it and we'd need to clearly document this in the Changelog. Cheers, Lars On 10/05/16 20:30, "Development on behalf of Thiago Macieira" wrote: >I've just found out that MSVC 2015 Update 2 added the compiler option /utf-8, >which is documented as: > > /utf-8 set source and execution character set to UTF-8 > >See https://blogs.msdn.microsoft.com/vcblog/2016/02/22/new-options-for-managing-character-sets-in-the-microsoft-cc-compiler/ > >I'd like to turn that option on for at least all of our source code, Once we >can drop support for MSVC versions older than 2015 Update 2, we'll be able to >write proper Unicode literals in all systems. > >The question is: do I turn it on for user code too? Or just ours? > >See also the bottom of the blog, that says: >> In a future major release of the compiler, we would like to change default >> handling of BOM-less files to assume UTF-8 > >Proof: > >The following file is encoded in UTF-8, as required for Qt sources. > >$ cat test.cpp >extern "C" { >extern const char s[] = "Résumé"; >extern const char s8[] = u8"Résumé"; >extern const char16_t su[] = u"Résumé"; >extern const wchar_t sl[] = L"Résumé"; >} > >Compiled with the /utf-8 option, the data is in the form we'd expect: >s DB 'R', 0c3H, 0a9H, 'sum', 0c3H, 0a9H, 00H > ORG $+7 >s8 DB 'R', 0c3H, 0a9H, 'sum', 0c3H, 0a9H, 00H > ORG $+7 >su DB 'R', 00H, 0e9H, 00H, 's', 00H, 'u', 00H, 'm', 00H, 0e9H, 00H > DB 00H, 00H > ORG $+2 >sl DB 'R', 00H, 0e9H, 00H, 's', 00H, 'u', 00H, 'm', 00H, 0e9H, 00H > DB 00H, 00H > >Which is the same as what we've got on Linux and OS X with Clang and GCC >(assembly listing from Clang on Linux): > >s: > .asciz "R\303\251sum\303\251" > .size s, 9 > > .type s8, at object # @s8 > .globl s8 >s8: > .asciz "R\303\251sum\303\251" > .size s8, 9 > > .type su, at object # @su > .globl su > .align 2 >su: > .short 82 # 0x52 > .short 233 # 0xe9 > .short 115 # 0x73 > .short 117 # 0x75 > .short 109 # 0x6d > .short 233 # 0xe9 > .short 0 # 0x0 > .size su, 14 > >Without that option, we had: > >s DB 'R', 0c3H, 0a9H, 'sum', 0c3H, 0a9H, 00H > ORG $+7 >s8 DB 'R', 0c3H, 083H, 0c2H, 0a9H, 'sum', 0c3H, 083H, 0c2H, 0a9H > DB 00H > ORG $+3 >su DB 'R', 00H, 0c3H, 00H, 0a9H, 00H, 's', 00H, 'u', 00H, 'm', 00H > DB 0c3H, 00H, 0a9H, 00H, 00H, 00H > ORG $+6 >sl DB 'R', 00H, 0c3H, 00H, 0a9H, 00H, 's', 00H, 'u', 00H, 'm', 00H > DB 0c3H, 00H, 0a9H, 00H, 00H, 00H > >The above contains Mojibake for the s8, su and sl variables. >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at qt.io Wed May 11 10:04:36 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Wed, 11 May 2016 08:04:36 +0000 Subject: [Development] Acceptable CC licenses for Qt In-Reply-To: <4422295.9qpMLJGLRa@luna> References: <4422295.9qpMLJGLRa@luna> Message-ID: On 11/05/16 00:59, "Development on behalf of Lisandro Damián Nicanor Pérez Meyer" wrote: >Hi! I would like to know what are the acceptable Creative Common licenses for >Qt. > >The reason why I'm asking is because qt3d's examples/qt3d/audio-visualizer- >qml/music/tiltshifted_lost_neon_sun.mp3 is under the CC-BY-ND license, which >is undistributable by Debian, Ubuntu and derivatives. It's the -ND variants that cause issues, right? In that case, I'd say we should avoid those if possible. > >Qt 3D maintainers: would you accept a different licensed file for this >example? Would be good if you can find something different. In general: If you add 3rd party content to Qt (not only code), please check with me. Cheers, Lars From Simon.Hausmann at qt.io Wed May 11 10:07:08 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 11 May 2016 08:07:08 +0000 Subject: [Development] Acceptable CC licenses for Qt In-Reply-To: References: <4422295.9qpMLJGLRa@luna>, Message-ID: I have the strong feeling that perhaps there's an alternate solution, given that the file in question was probably produced by Pasi :) Simon ________________________________________ From: Development on behalf of Lars Knoll Sent: Wednesday, May 11, 2016 10:04:36 AM To: Lisandro Damián Nicanor Pérez Meyer; development at qt-project.org Subject: Re: [Development] Acceptable CC licenses for Qt On 11/05/16 00:59, "Development on behalf of Lisandro Damián Nicanor Pérez Meyer" wrote: >Hi! I would like to know what are the acceptable Creative Common licenses for >Qt. > >The reason why I'm asking is because qt3d's examples/qt3d/audio-visualizer- >qml/music/tiltshifted_lost_neon_sun.mp3 is under the CC-BY-ND license, which >is undistributable by Debian, Ubuntu and derivatives. It's the -ND variants that cause issues, right? In that case, I'd say we should avoid those if possible. > >Qt 3D maintainers: would you accept a different licensed file for this >example? Would be good if you can find something different. In general: If you add 3rd party content to Qt (not only code), please check with me. Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed May 11 10:19:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 May 2016 01:19:33 -0700 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? In-Reply-To: References: <1870465.YMDxbbm7c5@tjmaciei-mobl4> Message-ID: <2865750.BEQoFvjr4q@tjmaciei-mobl4> On quarta-feira, 11 de maio de 2016 07:59:38 PDT Lars Knoll wrote: > Finally! > > We should certainly turn it on for Qt. > > User code is a bit more sensitive. What are we currently doing on the other > compilers? Are we assuming utf8 as the input encoding by default? If yes, > we should aim for consistency and turn it on for user code on msvc2015 as > well, but there should be an option to disable it and we'd need to clearly > document this in the Changelog. GCC and Clang on Unix systems already operate like this new MSVC option. They do that irrespective of what your locale settings are: sources are assumed to be UTF-8, period. But unlike MSVC now, they only complain about non-UTF8 code if they are required to convert/validate it. MSVC is documented to convert to Unicode as it parses, so it may fail to compile even where non-UTF8 is found in regular, narrow character literals. If you take the code from the OP and convert to Latin1, then compile, you'll get errors. GCC complains about the u and L literals: error: converting to execution character set: Invalid or incomplete multibyte or wide character Clang complains about all four, with the first one (regular char) just a warning: warning: illegal character encoding in string literal [-Winvalid-source- encoding] error: illegal character encoding in string literal -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From announce at qt-project.org Wed May 11 13:06:36 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 11 May 2016 11:06:36 +0000 Subject: [Development] [Announce] Qt Creator 4.0.0 released Message-ID: We are happy to announce the release of Qt Creator 4.0.0: http://blog.qt.io/blog/2016/05/11/qt-creator-4-0-0-released/ Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From michael.bruning at qt.io Wed May 11 13:14:09 2016 From: michael.bruning at qt.io (=?UTF-8?Q?Michael_Br=c3=bcning?=) Date: Wed, 11 May 2016 13:14:09 +0200 Subject: [Development] Nominating Alexandru Croitor for Approver status Message-ID: <57331401.6020201@qt.io> Hi all, I would like to nominate Alexandru Croitor for Approver status. Alexandru joined The Qt Company about 6 months ago and has been working full time on Qt since then and especially on the Qt WebEngine module. Here is his Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:"Alexandru Croitor "status:merged,n,z And a list of his reviews: https://codereview.qt-project.org/#/q/reviewer:"Alexandru Croitor ",n,z Cheers, Michael From perezmeyer at gmail.com Wed May 11 14:25:19 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 11 May 2016 09:25:19 -0300 Subject: [Development] Acceptable CC licenses for Qt In-Reply-To: References: <4422295.9qpMLJGLRa@luna> Message-ID: <4894909.Piv2sV2XSW@luna> On Wednesday 11 May 2016 08:04:36 Lars Knoll wrote: [snip] > > It's the -ND variants that cause issues, right? In that case, I'd say we > should avoid those if possible. Right, we can only accept CC-BY-SA 3.0 or 4.0. > >Qt 3D maintainers: would you accept a different licensed file for this > >example? > > > Would be good if you can find something different. > > In general: If you add 3rd party content to Qt (not only code), please check > with me. Thanks! -- 6 - ¿Cuál es el botón del mouse que permite acceder a las acciones más comunes de archivos? a- El derecho b- El izquierdo c- El central ... ¿PORQUÉ no puedo ver la cara de un usuario de Macintosh?, ¿EH? Guillermo Marraco http://mx.grulic.org.ar/lurker/message/20080307.112156.460149a2.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From marc.mutz at kdab.com Wed May 11 15:30:04 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 11 May 2016 15:30:04 +0200 Subject: [Development] Update on Q_FOREACH (was: Re: QStringLiteral vs QLatin1String , foreach vs for range) In-Reply-To: <01C34874-6C72-43B7-8CD9-2926F1C1ED86@theqtcompany.com> References: <201601201158.59836.marc.mutz@kdab.com> <01C34874-6C72-43B7-8CD9-2926F1C1ED86@theqtcompany.com> Message-ID: <201605111530.05507.marc.mutz@kdab.com> On Wednesday 20 January 2016 11:17:02 Knoll Lars wrote: > On 20/01/16 11:58, "Development on behalf of Marc Mutz" wrote: > >On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote: > >> On Wednesday 20 January 2016 08:12:58 André Somers wrote: > >> > Where is this qAsConst coming from? When was it introduced? Where is > >> > it documented? > >> > >> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs. > > > >It was intended as private API for use within Qt. If the sentiment is that > >it should be public, I'll add proper docs. > > > >If the sentiment is also that we should start to discourage the use of > >Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + > >range-for. > > +1 to both. Let's encourage people to use range-for and qAsConst instead of > foreach. Qt 5.7 will have a QT_NO_FOREACH macros (currently integrating) which you can define for your library after porting away from Q_FOREACH/foreach to prevent new uses from creeping in: DEFINES += QT_NO_FOREACH To help modules that want to apply this macro, please don't add new uses of Q_FOREACH or foreach to header files (public or private) because such use leaks into other user's code. I'll fix the existing uses in 5.7, if you don't beat me. Unless you're targeting 5.6, please try not to add new uses of foreach anywhere, strongly preferring C++11 range-for. I note in passing that Q_FOREACH / foreach was never intended to be used in Qt library code, because it generates inferior code to all other looping constructs: https://codereview.qt-project.org/78965 In my measurements, you can expect 80-100B in text size saved per Q_FOREACH loop converted to C++11 range-for. More if you happened to use Q_FOREACH on a QVarLengthArray ;) Small porting guide: - Q_FOREACH(type item, functionCall()) + const auto items = functionCall(); + for (type item : items) - Q_FOREACH(type item, const container) + for (type item : const container) - Q_FOREACH(type item, mutable container) + for (type item : qAsConst(mutable container)) + // if 'container' is not modified (directly or indirectly) in the loop + // body, otherwise iterate over a copy (as Q_FOREACH did) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From krnekit at gmail.com Wed May 11 15:46:36 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Wed, 11 May 2016 16:46:36 +0300 Subject: [Development] Acceptable CC licenses for Qt In-Reply-To: References: <4422295.9qpMLJGLRa@luna> Message-ID: 2016-05-11 11:04 GMT+03:00 Lars Knoll : > Would be good if you can find something different. > > In general: If you add 3rd party content to Qt (not only code), please check with me. This thread quite in time :) I want to use this Google Material icons [1] for the QtQuick Controls 2 Material style. The icons are CC-BY 4.0. Is it ok? And if it is, should there be some notes about these icons in code or in LICENSE files in project? [1] https://design.google.com/icons/ From andy.shaw at qt.io Wed May 11 15:50:50 2016 From: andy.shaw at qt.io (Andy Shaw) Date: Wed, 11 May 2016 13:50:50 +0000 Subject: [Development] Should the system proxies default setting be switched to true? Message-ID: For some time now we have had the means to configure Qt to use system proxies so that they are on by default or to turn it on via QNetworkProxyFactory. However, this is off by default so it is becoming a reoccurrence that people don't realise that it is not using the system proxies until later on. Potentially not until after a product has been released. The reasoning that this was not done before was due to the fact that there was a problem on Windows with it taking too long in some cases to get the information. However this seems to be solved for the most part and expected in some cases due to the fact that it is down to the system, but it is just an initial start up check in this case. That said, does anyone see any problems with switching it so that we can now have it turned on by default from Qt 5.8? Naturally the configure option would stay so people can still turn it off if they wish. For reference the original thread about this can be found:   http://lists.qt-project.org/pipermail/development/2012-October/007037.html Andy From perezmeyer at gmail.com Wed May 11 15:54:41 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 11 May 2016 10:54:41 -0300 Subject: [Development] Acceptable CC licenses for Qt In-Reply-To: References: <4422295.9qpMLJGLRa@luna> Message-ID: <2248837.2ean04dHB5@tonks> On Wednesday 11 May 2016 16:46:36 Nikita Krupenko wrote: [snip] > This thread quite in time :) > > I want to use this Google Material icons [1] for the QtQuick Controls > 2 Material style. The icons are CC-BY 4.0. Is it ok? And if it is, > should there be some notes about these icons in code or in LICENSE > files in project? > > [1] https://design.google.com/icons/ You made me notice that CC-By without -NC and/or -ND (ie, just CC-BY) should also be OK for Debian/Ubuntu + derivatives. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From michal.klocek at qt.io Wed May 11 15:55:53 2016 From: michal.klocek at qt.io (Michal Klocek) Date: Wed, 11 May 2016 15:55:53 +0200 Subject: [Development] Nominating Alexandru Croitor for Approver status In-Reply-To: <57331401.6020201@qt.io> References: <57331401.6020201@qt.io> Message-ID: <573339E9.7030501@qt.io> +1 cheers Mike On 05/11/2016 01:14 PM, Michael Brüning wrote: > Hi all, > > I would like to nominate Alexandru Croitor for Approver status. > Alexandru joined The Qt Company about 6 months ago and has been > working full time on Qt since then and especially on the Qt WebEngine > module. > > Here is his Gerrit dashboard: > https://codereview.qt-project.org/#/q/owner:"Alexandru Croitor > "status:merged,n,z > > And a list of his reviews: > https://codereview.qt-project.org/#/q/reviewer:"Alexandru Croitor > ",n,z > > Cheers, > Michael > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From joerg.bornemann at qt.io Wed May 11 15:59:33 2016 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Wed, 11 May 2016 15:59:33 +0200 Subject: [Development] Nominating Alexandru Croitor for Approver status In-Reply-To: <57331401.6020201@qt.io> References: <57331401.6020201@qt.io> Message-ID: <4133d570-e6d1-e222-a2c2-18549bc09d77@qt.io> On 11/05/2016 13:14, Michael Brüning wrote: > I would like to nominate Alexandru Croitor for Approver status. > Alexandru joined The Qt Company about 6 months ago and has been working > full time on Qt since then and especially on the Qt WebEngine module. +1 Also for his talent to pick (and fix) the tough issues. DISCLAIMER: he's sitting next door. From Simon.Hausmann at qt.io Wed May 11 16:07:57 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 11 May 2016 14:07:57 +0000 Subject: [Development] Nominating Alexandru Croitor for Approver status In-Reply-To: <57331401.6020201@qt.io> References: <57331401.6020201@qt.io> Message-ID: +1 Simon ________________________________________ From: Development on behalf of Michael Brüning Sent: Wednesday, May 11, 2016 1:14:09 PM To: development at qt-project.org Subject: [Development] Nominating Alexandru Croitor for Approver status Hi all, I would like to nominate Alexandru Croitor for Approver status. Alexandru joined The Qt Company about 6 months ago and has been working full time on Qt since then and especially on the Qt WebEngine module. Here is his Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:"Alexandru Croitor "status:merged,n,z And a list of his reviews: https://codereview.qt-project.org/#/q/reviewer:"Alexandru Croitor ",n,z Cheers, Michael _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Wed May 11 16:45:54 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 11 May 2016 14:45:54 +0000 Subject: [Development] Short maintenance break in CI tomorrow morning Message-ID: Hi, There will be a maintenance break for the CI environment on Thursday 12th of May at 7am-8am Finnish time (UTC+2), when we switch the control network traffic to a different firewall. There are no changes to CI environment itself, and the IP addresses do not change. During the break the CI environment is unavailable. Yours, Tuukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Wed May 11 17:42:11 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 11 May 2016 12:42:11 -0300 Subject: [Development] Should the system proxies default setting be switched to true? In-Reply-To: References: Message-ID: <3865120.l8xjl0VBII@tonks> On Wednesday 11 May 2016 13:50:50 Andy Shaw wrote: > For some time now we have had the means to configure Qt to use system > proxies so that they are on by default or to turn it on via > QNetworkProxyFactory. However, this is off by default so it is becoming a > reoccurrence that people don't realise that it is not using the system > proxies until later on. Potentially not until after a product has been > released. > > > The reasoning that this was not done before was due to the fact that there > was a problem on Windows with it taking too long in some cases to get the > information. However this seems to be solved for the most part and expected > in some cases due to the fact that it is down to the system, but it is just > an initial start up check in this case. > > > That said, does anyone see any problems with switching it so that we can now > have it turned on by default from Qt 5.8? Naturally the configure option > would stay so people can still turn it off if they wish. > > > For reference the original thread about this can be found: > > > http://lists.qt-project.org/pipermail/development/2012-October/007037.html Last time I tried that switch on Debian (last year?) the proxy was applied to all the protocols and not just http. I think Thiago or I submitted a patch to gerrit and I think it was merged. I'll try to get qtbase rebuilt with that option on and see what happens. -- Lo que me sorprende de las mujeres es que se arrancan los pelos desde la raíz con cera caliente y aún así le temen a las arañas. Jerry Seinfeld lis: comentario sobre tu frase.... yo soy mujer, yo me arranco los pelos y VOS le tenes miedo a las arañas.... María Luján Pérez Meyer (mi hermana) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From apoenitz at t-online.de Wed May 11 18:27:29 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 11 May 2016 18:27:29 +0200 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? In-Reply-To: References: <1870465.YMDxbbm7c5@tjmaciei-mobl4> Message-ID: <20160511162729.GA1325@klara.mpi.htwm.de> On Wed, May 11, 2016 at 07:59:38AM +0000, Lars Knoll wrote: > Finally! > > We should certainly turn it on for Qt. TBH, I don't see much of an advantage. Qt sources are (or should have been) 7-bit clean and this still looks like a sensible "least surprise" approach in general for any intended-to-be-portable code base. I understand that being able to use UTF-8 could make some tests more readable, so I am not really opposed to the idea, it's just that it doesn't look like a big win in total. > User code is a bit more sensitive. What are we currently doing on the > other compilers? Are we assuming utf8 as the input encoding by > default? If yes, we should aim for consistency and turn it on for user > code on msvc2015 as well, but there should be an option to disable it > and we'd need to clearly document this in the Changelog. One question is what happens with files that have non-uniform encodings in comments which seemed to be a rather common phenomenon at a time. It's unclear to me after reading the blog post. I don't know how modern MSVC react to them, but it used to just ignore any junk in comments (like one \author entry with Latin1 encoded umlauts and the next one with UTF-8 encoding) If using that switch means that such code suddenly fails to compile we should not enforce it on user code. Andre' From apoenitz at t-online.de Wed May 11 18:55:03 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 11 May 2016 18:55:03 +0200 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? In-Reply-To: <2865750.BEQoFvjr4q@tjmaciei-mobl4> References: <1870465.YMDxbbm7c5@tjmaciei-mobl4> <2865750.BEQoFvjr4q@tjmaciei-mobl4> Message-ID: <20160511165503.GB1325@klara.mpi.htwm.de> On Wed, May 11, 2016 at 01:19:33AM -0700, Thiago Macieira wrote: > On quarta-feira, 11 de maio de 2016 07:59:38 PDT Lars Knoll wrote: > > Finally! > > > > We should certainly turn it on for Qt. > > > > User code is a bit more sensitive. What are we currently doing on > > the other compilers? Are we assuming utf8 as the input encoding by > > default? If yes, we should aim for consistency and turn it on for > > user code on msvc2015 as well, but there should be an option to > > disable it and we'd need to clearly document this in the Changelog. > > GCC and Clang on Unix systems already operate like this new MSVC > option. They do that irrespective of what your locale settings are: > sources are assumed to be UTF-8, period. I don't see this for GCC 5.2.1 Linux for string literals, even with -Wall It pretty much looks like they are put 1:1 into the object files, no matter what the encoding is. Clang issues a "warning: illegal character encoding in string literal", but it's a just warning that can be switched off. Judging from the top 20 hits in my favourite search engine the feature is (a) controversial, and (b) there are still tons of 8-bit non-UTF8 encoded sources around. Andre' From kde at carewolf.com Wed May 11 19:27:33 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 11 May 2016 19:27:33 +0200 Subject: [Development] Nominating Alexandru Croitor for Approver status In-Reply-To: <57331401.6020201@qt.io> References: <57331401.6020201@qt.io> Message-ID: <201605111927.33945.kde@carewolf.com> + 1 `Allan On Wednesday 11 May 2016, Michael Brüning wrote: > Hi all, > > I would like to nominate Alexandru Croitor for Approver status. > Alexandru joined The Qt Company about 6 months ago and has been working > full time on Qt since then and especially on the Qt WebEngine module. > > Here is his Gerrit dashboard: > https://codereview.qt-project.org/#/q/owner:"Alexandru Croitor > "status:merged,n,z > > And a list of his reviews: > https://codereview.qt-project.org/#/q/reviewer:"Alexandru Croitor > ",n,z > > Cheers, > Michael > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed May 11 19:52:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 May 2016 10:52:43 -0700 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? In-Reply-To: <20160511162729.GA1325@klara.mpi.htwm.de> References: <1870465.YMDxbbm7c5@tjmaciei-mobl4> <20160511162729.GA1325@klara.mpi.htwm.de> Message-ID: <5314672.Mf4SiJQVde@tjmaciei-mobl4> On quarta-feira, 11 de maio de 2016 18:27:29 PDT André Pönitz wrote: > On Wed, May 11, 2016 at 07:59:38AM +0000, Lars Knoll wrote: > > Finally! > > > > We should certainly turn it on for Qt. > > TBH, I don't see much of an advantage. Qt sources are (or should > have been) 7-bit clean and this still looks like a sensible "least > surprise" approach in general for any intended-to-be-portable code base. They are, which means we will not see immediate benefit to our own code by turning this on. And since we'll still have to cope with MSVC 2013 and the early versions of 2015, we won't be able to make use of it for some time. But it will eventually allow us to write UTF-8 directly inline in our sources. > I understand that being able to use UTF-8 could make some tests > more readable, so I am not really opposed to the idea, it's just > that it doesn't look like a big win in total. Fair enough. > > User code is a bit more sensitive. What are we currently doing on the > > other compilers? Are we assuming utf8 as the input encoding by > > default? If yes, we should aim for consistency and turn it on for user > > code on msvc2015 as well, but there should be an option to disable it > > and we'd need to clearly document this in the Changelog. > > One question is what happens with files that have non-uniform > encodings in comments which seemed to be a rather common phenomenon > at a time. It's unclear to me after reading the blog post. > I don't know how modern MSVC react to them, but it used > to just ignore any junk in comments (like one \author entry with > Latin1 encoded umlauts and the next one with UTF-8 encoding) That's a good question. I haven't tested the option myself yet, but I guess we'll learn more soon. Clearly, there's no need to rush here. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed May 11 19:55:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 May 2016 10:55:36 -0700 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? In-Reply-To: <20160511165503.GB1325@klara.mpi.htwm.de> References: <1870465.YMDxbbm7c5@tjmaciei-mobl4> <2865750.BEQoFvjr4q@tjmaciei-mobl4> <20160511165503.GB1325@klara.mpi.htwm.de> Message-ID: <2481085.iYT1OPe3Ey@tjmaciei-mobl4> On quarta-feira, 11 de maio de 2016 18:55:03 PDT André Pönitz wrote: > > GCC and Clang on Unix systems already operate like this new MSVC > > option. They do that irrespective of what your locale settings are: > > sources are assumed to be UTF-8, period. > > I don't see this for GCC 5.2.1 Linux for string literals, even with > -Wall It pretty much looks like they are put 1:1 into the object files, > no matter what the encoding is. For narrow, non-Unicode character literals. Try that with the ones that do require transcoding and you'll see. What's more, GCC assumes that the source is UTF-8, so it will not transform the u8"" string literals. That means that if your source is not what it is supposed to be, you'll produce invalid UTF-8 sequences. > Clang issues a "warning: illegal character encoding in string > literal", but it's a just warning that can be switched off. > > Judging from the top 20 hits in my favourite search engine the feature > is (a) controversial, and (b) there are still tons of 8-bit non-UTF8 > encoded sources around. Indeed, and that's probably why GCC does not print a warning. But see if you find people complaining about the transcoding done for u, U and L literals. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 12 00:24:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 May 2016 15:24:25 -0700 Subject: [Development] Please review https://codereview.qt-project.org/157499 Message-ID: <2448272.bBpoLOHaPm@tjmaciei-mobl4> It's my own change and and I can't even do a maintainer-approval because there are no +1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Thu May 12 08:20:48 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 12 May 2016 06:20:48 +0000 Subject: [Development] Header review for 5.7 (vs 5.6) In-Reply-To: References: Message-ID: Hi, What is the status with the this? It seems several modules doesn't have '+1' yet. We need to conclude this soon to b e able to release 'RC' as planned Missing '+1': * https://codereview.qt-project.org/157805 – qtbase * https://codereview.qt-project.org/157790 – qtactiveqt * https://codereview.qt-project.org/157793 – qtlocation * https://codereview.qt-project.org/157795 – qtconnectivity * https://codereview.qt-project.org/157796 – qtwayland * https://codereview.qt-project.org/157797 – qt3d * https://codereview.qt-project.org/157801 – qtandroidextras * https://codereview.qt-project.org/157802 – qtwebsockets * https://codereview.qt-project.org/157803 – qtwebengine * https://codereview.qt-project.org/157804 – qtcanvas3d br, Jani ________________________________________ From: Development on behalf of Edward Welbourne Sent: Tuesday, May 3, 2016 7:24 PM To: development at qt-project.org Subject: [Development] Header review for 5.7 (vs 5.6) Hi all, As we approach the release of 5.7.0, we naturally need to review the changes to APIs for all the usual things. This time, however, we decided [0] it would be nice to actually make use of Gerrit's ability to display changes nicely, rather than [1] displaying a diff as if it were an enormous file to be added to a module. While we were at it, we decided [2] to filter out, as well as the copyright header changes our old script discarded, various rather boring changes, such as just adding a Q_ALWAYS_INLINE, Q_DECL_NOTHROW or Q_CONSTEXPR to a declaration. [0] https://bugreports.qt.io/browse/QTQAINFRA-973 [1] https://codereview.qt-project.org/#/c/153346/ [2] https://codereview.qt-project.org/155745 Consequently, to take the example of qtbase, instead of looking at more than 100 k lines with no colouring mark-up to help you see what's really changed, reviewers only need to look at a little under 8 k lines, split up nicely by which file they're in and actually making good use of Gerrit's ability to display diffs nicely. Just be sure you don't do anything silly like telling Gerrit to merge these commits :-) The scripts to do this are still a bit fresh (I was fixing bugs in them on Friday and still testing yesterday) and anyone nervous of whether they might be mistaking meaninful changes for boring is welcome to take a look [3] (and let me know so I can fix that). If you actually want to run this at home, you'll need python's dulwich package installed, for the git magic it does. [3] https://codereview.qt-project.org/157299 Yesterday's header diffs are all listed in [4], but I'll list them here, too, for the convenience of those whose mailers understand links: * https://codereview.qt-project.org/157805 – qtbase * https://codereview.qt-project.org/157789 – qtdeclarative * https://codereview.qt-project.org/157790 – qtactiveqt * https://codereview.qt-project.org/157791 – qtmultimedia * https://codereview.qt-project.org/157792 – qttools * https://codereview.qt-project.org/157793 – qtlocation * https://codereview.qt-project.org/157795 – qtconnectivity * https://codereview.qt-project.org/157796 – qtwayland * https://codereview.qt-project.org/157797 – qt3d * https://codereview.qt-project.org/157798 – qtquickcontrols * https://codereview.qt-project.org/157799 – qtserialport * https://codereview.qt-project.org/157800 – qtx11extras * https://codereview.qt-project.org/157801 – qtandroidextras * https://codereview.qt-project.org/157802 – qtwebsockets * https://codereview.qt-project.org/157803 – qtwebengine * https://codereview.qt-project.org/157804 – qtcanvas3d [4] https://bugreports.qt.io/browse/QTQAINFRA-973#comment-318470 Please take a look at the modules you care about and point out anything that's going to cause problems for the usual compatibility constraints, Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at qt.io Thu May 12 08:41:21 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 12 May 2016 06:41:21 +0000 Subject: [Development] Should the system proxies default setting be switched to true? In-Reply-To: References: Message-ID: +1 for switching to using the system proxy settings by default. I'm still a bit wary about the 'Windows issue' though. To cite our documentation [1]: "On Windows platforms, this function may take several seconds to execute depending on the configuration of the user's system." Was that the problem with Windows versions configured for automatically querying for PAC files, but never getting any response? Regards Kai [1]: http://doc.qt.io/qt-5/qnetworkproxyfactory.html#systemProxyForQuery > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Andy Shaw > Sent: Wednesday, May 11, 2016 3:51 PM > To: development at qt-project.org > Subject: [Development] Should the system proxies default setting be > switched to true? > > For some time now we have had the means to configure Qt to use system > proxies so that they are on by default or to turn it on via > QNetworkProxyFactory. However, this is off by default so it is becoming a > reoccurrence that people don't realise that it is not using the system proxies > until later on. Potentially not until after a product has been released. > > > The reasoning that this was not done before was due to the fact that there > was a problem on Windows with it taking too long in some cases to get the > information. However this seems to be solved for the most part and > expected in some cases due to the fact that it is down to the system, but it is > just an initial start up check in this case. > > > That said, does anyone see any problems with switching it so that we can > now have it turned on by default from Qt 5.8? Naturally the configure option > would stay so people can still turn it off if they wish. > > > For reference the original thread about this can be found: > > >   http://lists.qt-project.org/pipermail/development/2012- > October/007037.html > > > Andy > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andy.shaw at qt.io Thu May 12 09:54:41 2016 From: andy.shaw at qt.io (Andy Shaw) Date: Thu, 12 May 2016 07:54:41 +0000 Subject: [Development] Should the system proxies default setting be switched to true? In-Reply-To: References: , Message-ID: There is an issue but this comes from the Windows side and is also documented by Microsoft as being a problem I believe on their side. But this should only be experienced the first time it needs to do this though, whereas before it would do this all the time. However, I would personally expect that if this is happening for a user, it will not be happening for just Qt either. Andy ________________________________________ Fra: Kai Koehne Sendt: 12. mai 2016 08:41:21 Til: Andy Shaw; development at qt-project.org Emne: RE: [Development] Should the system proxies default setting be switched to true? +1 for switching to using the system proxy settings by default. I'm still a bit wary about the 'Windows issue' though. To cite our documentation [1]: "On Windows platforms, this function may take several seconds to execute depending on the configuration of the user's system." Was that the problem with Windows versions configured for automatically querying for PAC files, but never getting any response? Regards Kai [1]: http://doc.qt.io/qt-5/qnetworkproxyfactory.html#systemProxyForQuery > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Andy Shaw > Sent: Wednesday, May 11, 2016 3:51 PM > To: development at qt-project.org > Subject: [Development] Should the system proxies default setting be > switched to true? > > For some time now we have had the means to configure Qt to use system > proxies so that they are on by default or to turn it on via > QNetworkProxyFactory. However, this is off by default so it is becoming a > reoccurrence that people don't realise that it is not using the system proxies > until later on. Potentially not until after a product has been released. > > > The reasoning that this was not done before was due to the fact that there > was a problem on Windows with it taking too long in some cases to get the > information. However this seems to be solved for the most part and > expected in some cases due to the fact that it is down to the system, but it is > just an initial start up check in this case. > > > That said, does anyone see any problems with switching it so that we can > now have it turned on by default from Qt 5.8? Naturally the configure option > would stay so people can still turn it off if they wish. > > > For reference the original thread about this can be found: > > > http://lists.qt-project.org/pipermail/development/2012- > October/007037.html > > > Andy > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Thu May 12 10:01:35 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 12 May 2016 08:01:35 +0000 Subject: [Development] Should the system proxies default setting be switched to true? In-Reply-To: References: , , Message-ID: Right, it begs the question: If a third-party application like Chrome can use system proxy settings by default, why can't or don't we? :) Simon ________________________________________ From: Development on behalf of Andy Shaw Sent: Thursday, May 12, 2016 9:54:41 AM To: Kai Koehne; development at qt-project.org Subject: Re: [Development] Should the system proxies default setting be switched to true? There is an issue but this comes from the Windows side and is also documented by Microsoft as being a problem I believe on their side. But this should only be experienced the first time it needs to do this though, whereas before it would do this all the time. However, I would personally expect that if this is happening for a user, it will not be happening for just Qt either. Andy ________________________________________ Fra: Kai Koehne Sendt: 12. mai 2016 08:41:21 Til: Andy Shaw; development at qt-project.org Emne: RE: [Development] Should the system proxies default setting be switched to true? +1 for switching to using the system proxy settings by default. I'm still a bit wary about the 'Windows issue' though. To cite our documentation [1]: "On Windows platforms, this function may take several seconds to execute depending on the configuration of the user's system." Was that the problem with Windows versions configured for automatically querying for PAC files, but never getting any response? Regards Kai [1]: http://doc.qt.io/qt-5/qnetworkproxyfactory.html#systemProxyForQuery > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Andy Shaw > Sent: Wednesday, May 11, 2016 3:51 PM > To: development at qt-project.org > Subject: [Development] Should the system proxies default setting be > switched to true? > > For some time now we have had the means to configure Qt to use system > proxies so that they are on by default or to turn it on via > QNetworkProxyFactory. However, this is off by default so it is becoming a > reoccurrence that people don't realise that it is not using the system proxies > until later on. Potentially not until after a product has been released. > > > The reasoning that this was not done before was due to the fact that there > was a problem on Windows with it taking too long in some cases to get the > information. However this seems to be solved for the most part and > expected in some cases due to the fact that it is down to the system, but it is > just an initial start up check in this case. > > > That said, does anyone see any problems with switching it so that we can > now have it turned on by default from Qt 5.8? Naturally the configure option > would stay so people can still turn it off if they wish. > > > For reference the original thread about this can be found: > > > http://lists.qt-project.org/pipermail/development/2012- > October/007037.html > > > Andy > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Thu May 12 12:01:47 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 12 May 2016 10:01:47 +0000 Subject: [Development] Qt 5.6.1 snapshot for testing In-Reply-To: References: Message-ID: Hi all, We have finally Qt 5.6.1 packages for testing here: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.1/445/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.1/416/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.1/347/ src: http://download.qt.io/snapshots/qt/5.6/5.6.1/latest_src(Mirroring ongoing) Packages are done from '5.6' branch so new changes from '5.6.1' are still missing. Latest qt5.git integration in these packages: https://codereview.qt-project.org /#/c/158300/ Packages are RTA smoke tested & seems to be OK so please test the packages & report all possible release blockers immediately; We are planning to release Qt 5.6.1 still during May. These aren't yet final Qt 5.6.1 packages; There is still some blockers open, see https://bugreports.qt.io/issues/?filter=17596. Most of change files are still missing & Venu should be working with initial ones. After those are available Maintainers needs to update those immediately... br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Thu May 12 12:03:46 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 12 May 2016 12:03:46 +0200 Subject: [Development] HEADS UP: Qt 5.6.1 branching ongoing In-Reply-To: <20160506110248.GA15804@troll08.it.local> References: <20160506110248.GA15804@troll08.it.local> Message-ID: <20160512100346.GA25701@troll08.it.local> 5.6.1 is fully branched now. staging is limited to the release team. as usual, i'm taking retargeting requests for tardy changes. On Fri, May 06, 2016 at 01:02:48PM +0200, Oswald Buddenhagen wrote: > The 5.6.1 branch is now available. Please start using it for changes > targeting the Qt 5.6.1 release. > > We will merge the 5.6 branch to 5.6.1 a last time somewhen next week, so > there should be enough time to finalize ongoing changes in 5.6, and > start using 5.6.1 for new changes. > > Changes done on 5.6.1 are forward-merged to 5.6, 5.7, and dev - as usual. > Don't cherry-pick in either direction if at all avoidable - as usual. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andrew.knight at intopalo.com Thu May 12 13:58:38 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Thu, 12 May 2016 14:58:38 +0300 Subject: [Development] Proposing Oliver Wolff as QtANGLE maintainer Message-ID: ANGLE is an important third-party library used in Qt for Windows applications, and keeping the dependency up-to-date over the releases is an important and challenging task. It involves testing on a sea of Windows configurations, creating/maintaining patches for Qt, and upstreaming those to the ANGLE project (part of Chromium). Until recently, I was the acting maintainer of this dependency. Now, Oliver Wolff has taken the lead over this part of Qt, upgrading ANGLE for Qt 5.7, and continuing to dutifully patch it as bugs are uncovered. Although this is not an official Qt module or platform, I propose Oliver as the new (Qt) ANGLE maintainer. He deserves a badge of honor for taking on this often less-than-satisfying, yet crucial, task within the Qt Project. Cheers, Andrew From andrew.knight at intopalo.com Thu May 12 14:09:44 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Thu, 12 May 2016 15:09:44 +0300 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer Message-ID: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> The Windows Runtime port of Qt covers the platform-specific code in Qt, most of it in the "winrt" platform plugin, which enables Qt to run as Windows 8/10 Store Apps, on Windows Phone 8/10, and Windows IoT Core. As the standing Windows Runtime Platform Maintainer, I hereby step down from my post. Over the past year, my contributions to the port have wained, and I simply do not have time to keep up with Windows development. It would be in the best interest of the Qt Project to nominate a new Maintainer. That said, I would like to propose Maurice Kalinowski as the new Windows Runtime Platform Maintainer. He has been active for the entire existence of the port, and has been the primary contributor to it for at least the past six months. He is continuously staying informed of the state of Microsoft's OS technologies, testing Qt on different devices (including the HoloLens!), and making the port better in general. In many ways, he is the acting maintainer already. Cheers, Andrew From tero.kojo at qt.io Thu May 12 14:55:52 2016 From: tero.kojo at qt.io (Tero Kojo) Date: Thu, 12 May 2016 12:55:52 +0000 Subject: [Development] Qt World Summit call for papers open Message-ID: Hello, The call for papers for Qt World Summit 2016 has been opened! This year the premier Qt event is held October 18-20, 2016 in San Francisco, CA. The main themes of the summit are: - Creating Connected Devices and Internet of Things - Things getting smaller - Next generation graphics approaches - The future of user interfaces and 3D - Software as a differentiator - Industries being revolutionized by software: Automotive, Medical/Health, Consumer Electronics, Industrial Automation, Aerospace/Defense and more - Software solution for multi-platform development - desktop, mobile and embedded For these themes, we are looking for inspiring strategy and industry talks (Technology Strategy) as well as more hands-on technical talks (Qt for Application Development and Device Creation). The deadline for submissions is May 20. Show us your best work! The direct link to submit your talks is this: https://www.surveymonkey.com/r/QtWS16 For more details including the full call see: http://blog.qt.io/blog/2016/04/28/call-for-papers-qt-world-summit-2016/ Best, Tero -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Thu May 12 15:33:39 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 12 May 2016 13:33:39 +0000 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer In-Reply-To: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> References: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Andrew Knight > That said, I would like to propose Maurice Kalinowski as the new Windows > Runtime Platform Maintainer. +1 -- Alex From alexander.blasche at qt.io Thu May 12 15:34:42 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 12 May 2016 13:34:42 +0000 Subject: [Development] Proposing Oliver Wolff as QtANGLE maintainer In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Andrew Knight > Although this is not an official Qt module or platform, I propose Oliver > as the new (Qt) ANGLE maintainer. He deserves a badge of honor for > taking on this often less-than-satisfying, yet crucial, task within the > Qt Project. Indeed, thank you very much for stepping up. Here is my +1. -- Alex From thiago.macieira at intel.com Thu May 12 16:35:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 12 May 2016 07:35:29 -0700 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer In-Reply-To: References: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> Message-ID: <3136266.zqrpx4pJkc@tjmaciei-mobl4> On quinta-feira, 12 de maio de 2016 13:33:39 PDT Alexander Blasche wrote: > > -----Original Message----- > > From: Development [mailto:development- > > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Andrew Knight > > > > That said, I would like to propose Maurice Kalinowski as the new Windows > > Runtime Platform Maintainer. > > +1 +1 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Thu May 12 16:47:26 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 12 May 2016 14:47:26 +0000 Subject: [Development] Proposing Oliver Wolff as QtANGLE maintainer In-Reply-To: References: Message-ID: +1 Simon ________________________________________ From: Development on behalf of Andrew Knight Sent: Thursday, May 12, 2016 1:58:38 PM To: development at qt-project.org Subject: [Development] Proposing Oliver Wolff as QtANGLE maintainer ANGLE is an important third-party library used in Qt for Windows applications, and keeping the dependency up-to-date over the releases is an important and challenging task. It involves testing on a sea of Windows configurations, creating/maintaining patches for Qt, and upstreaming those to the ANGLE project (part of Chromium). Until recently, I was the acting maintainer of this dependency. Now, Oliver Wolff has taken the lead over this part of Qt, upgrading ANGLE for Qt 5.7, and continuing to dutifully patch it as bugs are uncovered. Although this is not an official Qt module or platform, I propose Oliver as the new (Qt) ANGLE maintainer. He deserves a badge of honor for taking on this often less-than-satisfying, yet crucial, task within the Qt Project. Cheers, Andrew _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Thu May 12 16:48:05 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 12 May 2016 14:48:05 +0000 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer In-Reply-To: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> References: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> Message-ID: +1. Those mobile Windows platforms keep coming back to Maurice :) Simon ________________________________________ From: Development on behalf of Andrew Knight Sent: Thursday, May 12, 2016 2:09:44 PM To: development at qt-project.org Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer The Windows Runtime port of Qt covers the platform-specific code in Qt, most of it in the "winrt" platform plugin, which enables Qt to run as Windows 8/10 Store Apps, on Windows Phone 8/10, and Windows IoT Core. As the standing Windows Runtime Platform Maintainer, I hereby step down from my post. Over the past year, my contributions to the port have wained, and I simply do not have time to keep up with Windows development. It would be in the best interest of the Qt Project to nominate a new Maintainer. That said, I would like to propose Maurice Kalinowski as the new Windows Runtime Platform Maintainer. He has been active for the entire existence of the port, and has been the primary contributor to it for at least the past six months. He is continuously staying informed of the state of Microsoft's OS technologies, testing Qt on different devices (including the HoloLens!), and making the port better in general. In many ways, he is the acting maintainer already. Cheers, Andrew _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Jake.Petroules at qt.io Thu May 12 17:05:35 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 12 May 2016 15:05:35 +0000 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer In-Reply-To: References: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> Message-ID: +1. I touch Windows as little as possible, yet I'm still aware of Maurice's prominence in the WinRT space. :) On May 12, 2016, at 7:48 AM, Simon Hausmann > wrote: +1. Those mobile Windows platforms keep coming back to Maurice :) Simon ________________________________________ From: Development > on behalf of Andrew Knight > Sent: Thursday, May 12, 2016 2:09:44 PM To: development at qt-project.org Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer The Windows Runtime port of Qt covers the platform-specific code in Qt, most of it in the "winrt" platform plugin, which enables Qt to run as Windows 8/10 Store Apps, on Windows Phone 8/10, and Windows IoT Core. As the standing Windows Runtime Platform Maintainer, I hereby step down from my post. Over the past year, my contributions to the port have wained, and I simply do not have time to keep up with Windows development. It would be in the best interest of the Qt Project to nominate a new Maintainer. That said, I would like to propose Maurice Kalinowski as the new Windows Runtime Platform Maintainer. He has been active for the entire existence of the port, and has been the primary contributor to it for at least the past six months. He is continuously staying informed of the state of Microsoft's OS technologies, testing Qt on different devices (including the HoloLens!), and making the port better in general. In many ways, he is the acting maintainer already. Cheers, Andrew _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmaxera at gmail.com Thu May 12 23:08:38 2016 From: gmaxera at gmail.com (Gianluca) Date: Thu, 12 May 2016 22:08:38 +0100 Subject: [Development] Is Qt able to render emoji font using the SVGinOT ? Message-ID: Hello, I’m wondering if Qt is able to render the coloured emoji font that use the SVGinOT (https://www.w3.org/2013/10/SVG_in_OpenType/) extension. Thanks, Gianluca. From Shawn.Rutledge at qt.io Fri May 13 07:24:03 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 13 May 2016 05:24:03 +0000 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer In-Reply-To: References: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> Message-ID: <10F72DF4-7FB6-4339-BDF8-AF13D7CCD864@qt.io> > On 12 May 2016, at 17:05, Jake Petroules wrote: > > +1. I touch Windows as little as possible, yet I'm still aware of Maurice's prominence in the WinRT space. :) +1 likewise. From paul.tvete at qt.io Fri May 13 08:32:48 2016 From: paul.tvete at qt.io (Paul Olav Tvete) Date: Fri, 13 May 2016 08:32:48 +0200 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer In-Reply-To: <10F72DF4-7FB6-4339-BDF8-AF13D7CCD864@qt.io> References: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> <10F72DF4-7FB6-4339-BDF8-AF13D7CCD864@qt.io> Message-ID: <8719431.8D8JT81oma@dragaera> On fredag 13. mai 2016 05.24.03 CEST Shawn Rutledge wrote: > > On 12 May 2016, at 17:05, Jake Petroules wrote: > > > > +1. I touch Windows as little as possible, yet I'm still aware of > > Maurice's prominence in the WinRT space. :) > +1 likewise. +1 from me too :) - Paul From Lars.Knoll at qt.io Fri May 13 09:07:52 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Fri, 13 May 2016 07:07:52 +0000 Subject: [Development] Proposing Oliver Wolff as QtANGLE maintainer In-Reply-To: References: Message-ID: +1 Lars On 12/05/16 16:47, "Development on behalf of Simon Hausmann" wrote: > >+1 > > >Simon >________________________________________ >From: Development on behalf of Andrew Knight >Sent: Thursday, May 12, 2016 1:58:38 PM >To: development at qt-project.org >Subject: [Development] Proposing Oliver Wolff as QtANGLE maintainer > >ANGLE is an important third-party library used in Qt for Windows >applications, and keeping the dependency up-to-date over the releases is >an important and challenging task. It involves testing on a sea of >Windows configurations, creating/maintaining patches for Qt, and >upstreaming those to the ANGLE project (part of Chromium). > >Until recently, I was the acting maintainer of this dependency. Now, >Oliver Wolff has taken the lead over this part of Qt, upgrading ANGLE >for Qt 5.7, and continuing to dutifully patch it as bugs are uncovered. > >Although this is not an official Qt module or platform, I propose Oliver >as the new (Qt) ANGLE maintainer. He deserves a badge of honor for >taking on this often less-than-satisfying, yet crucial, task within the >Qt Project. > > >Cheers, > >Andrew > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at qt.io Fri May 13 09:08:20 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Fri, 13 May 2016 07:08:20 +0000 Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer In-Reply-To: <10F72DF4-7FB6-4339-BDF8-AF13D7CCD864@qt.io> References: <6514cd20-f6ce-8f08-13fd-3a5ec1192ce4@intopalo.com> <10F72DF4-7FB6-4339-BDF8-AF13D7CCD864@qt.io> Message-ID: Another +1 Lars On 13/05/16 07:24, "Development on behalf of Shawn Rutledge" wrote: > >> On 12 May 2016, at 17:05, Jake Petroules wrote: >> >> +1. I touch Windows as little as possible, yet I'm still aware of Maurice's prominence in the WinRT space. :) > >+1 likewise. > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From eskil.abrahamsen-blomfeldt at qt.io Fri May 13 09:28:46 2016 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Fri, 13 May 2016 09:28:46 +0200 Subject: [Development] Is Qt able to render emoji font using the SVGinOT ? In-Reply-To: References: Message-ID: Den 12.05.2016 23:08, skrev Gianluca: > Hello, > I’m wondering if Qt is able to render the coloured emoji font that use the SVGinOT (https://www.w3.org/2013/10/SVG_in_OpenType/) extension. Hi, No, none of the font backends we use support them. The only support for it that I have heard of is in Firefox, though some Adobe applications probably support it as well. Qt 5.7.0 does support the Google format (CBDT/CBLC) on Android and Linux, the Apple format (SBIX) on iOS and OSX, and the Microsoft format (COLR/CPAL) on Windows. -- Eskil Abrahamsen Blomfeldt Senior Manager, Qt Graphics/Multimedia The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.shaw at qt.io Fri May 13 11:11:35 2016 From: andy.shaw at qt.io (Andy Shaw) Date: Fri, 13 May 2016 09:11:35 +0000 Subject: [Development] Should the system proxies default setting be switched to true? In-Reply-To: References: , , , Message-ID: Since there does not seem to be any general objections, I have submitted a patch for this - https://codereview.qt-project.org/159120 - this is for 5.8. If anyone does see an issue then please say so in the comments, I will give it a bit of time before merging once it gets its +2 in order to give it a chance to be tried out in case someone hits a problem. Andy ________________________________________ Fra: Simon Hausmann Sendt: 12. mai 2016 10:01:35 Til: Andy Shaw; Kai Koehne; development at qt-project.org Emne: Re: [Development] Should the system proxies default setting be switched to true? Right, it begs the question: If a third-party application like Chrome can use system proxy settings by default, why can't or don't we? :) Simon ________________________________________ From: Development on behalf of Andy Shaw Sent: Thursday, May 12, 2016 9:54:41 AM To: Kai Koehne; development at qt-project.org Subject: Re: [Development] Should the system proxies default setting be switched to true? There is an issue but this comes from the Windows side and is also documented by Microsoft as being a problem I believe on their side. But this should only be experienced the first time it needs to do this though, whereas before it would do this all the time. However, I would personally expect that if this is happening for a user, it will not be happening for just Qt either. Andy ________________________________________ Fra: Kai Koehne Sendt: 12. mai 2016 08:41:21 Til: Andy Shaw; development at qt-project.org Emne: RE: [Development] Should the system proxies default setting be switched to true? +1 for switching to using the system proxy settings by default. I'm still a bit wary about the 'Windows issue' though. To cite our documentation [1]: "On Windows platforms, this function may take several seconds to execute depending on the configuration of the user's system." Was that the problem with Windows versions configured for automatically querying for PAC files, but never getting any response? Regards Kai [1]: http://doc.qt.io/qt-5/qnetworkproxyfactory.html#systemProxyForQuery > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Andy Shaw > Sent: Wednesday, May 11, 2016 3:51 PM > To: development at qt-project.org > Subject: [Development] Should the system proxies default setting be > switched to true? > > For some time now we have had the means to configure Qt to use system > proxies so that they are on by default or to turn it on via > QNetworkProxyFactory. However, this is off by default so it is becoming a > reoccurrence that people don't realise that it is not using the system proxies > until later on. Potentially not until after a product has been released. > > > The reasoning that this was not done before was due to the fact that there > was a problem on Windows with it taking too long in some cases to get the > information. However this seems to be solved for the most part and > expected in some cases due to the fact that it is down to the system, but it is > just an initial start up check in this case. > > > That said, does anyone see any problems with switching it so that we can > now have it turned on by default from Qt 5.8? Naturally the configure option > would stay so people can still turn it off if they wish. > > > For reference the original thread about this can be found: > > > http://lists.qt-project.org/pipermail/development/2012- > October/007037.html > > > Andy > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Fri May 13 12:49:59 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 13 May 2016 12:49:59 +0200 Subject: [Development] Qt World Summit call for papers open In-Reply-To: References: Message-ID: <2902917.mmSRBqL3HL@oscar> Hi, In addition to the Qt World Summit, I would like to remind you about QtCon. There will be the Qt Contribution summit hapening there, but it is also some kind of substitute for the fact that there will not be devdays or QtWS in europe this year. Any talk that is relevant for the technical track of the Qt Wold Summit would also be relevant for QtCon. So have a look at the call for paper: https://qtcon.org/cfp the deadline for submission is on May 15. (This Sunday, so hurry up, altough there will probably be an extension) QtCon will be in Berlin, 2-4 September 2016: https://qtcon.org/ -- Olivier On Donnerstag, 12. Mai 2016 12:55:52 CEST Tero Kojo wrote: > Hello, > > The call for papers for Qt World Summit 2016 has been opened! > > This year the premier Qt event is held October 18-20, 2016 in San Francisco, > CA. > > The main themes of the summit are: > > - Creating Connected Devices and Internet of Things > > - Things getting smaller > > - Next generation graphics approaches > > - The future of user interfaces and 3D > > - Software as a differentiator - Industries being revolutionized by > software: Automotive, Medical/Health, Consumer Electronics, Industrial > Automation, Aerospace/Defense and more > > - Software solution for multi-platform development - desktop, > mobile and embedded > > For these themes, we are looking for inspiring strategy and industry talks > (Technology Strategy) as well as more hands-on technical talks (Qt for > Application Development and Device Creation). > > The deadline for submissions is May 20. > Show us your best work! > > The direct link to submit your talks is this: > https://www.surveymonkey.com/r/QtWS16 > > For more details including the full call see: > http://blog.qt.io/blog/2016/04/28/call-for-papers-qt-world-summit-2016/ > > Best, > Tero From oswald.buddenhagen at qt.io Fri May 13 13:36:30 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 13 May 2016 13:36:30 +0200 Subject: [Development] HEADS UP: Qt 5.7.0 branching ongoing Message-ID: <20160513113630.GA6600@troll08.it.local> The 5.7.0 branch is now available. Please start using it for changes targeting the Qt 5.7.0 release. We will merge the 5.7 branch to 5.7.0 a last time on May 19th, so there should be enough time to finalize ongoing changes in 5.7, and start using 5.7.0 for new changes. Changes done on 5.7.0 are forward-merged to 5.7 and dev - as usual. Don't cherry-pick in either direction if at all avoidable - as usual. From thiago.macieira at intel.com Fri May 13 17:52:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 13 May 2016 08:52:08 -0700 Subject: [Development] Qt World Summit call for papers open In-Reply-To: <2902917.mmSRBqL3HL@oscar> References: <2902917.mmSRBqL3HL@oscar> Message-ID: <4491572.iFdVJ0cqDG@tjmaciei-mobl4> On sexta-feira, 13 de maio de 2016 12:49:59 PDT Olivier Goffart wrote: > Hi, > In addition to the Qt World Summit, I would like to remind you about QtCon. > There will be the Qt Contribution summit hapening there, but it is also some > kind of substitute for the fact that there will not be devdays or QtWS in > europe this year. > Any talk that is relevant for the technical track of the Qt Wold Summit > would also be relevant for QtCon. So have a look at the call for paper: > https://qtcon.org/cfp > the deadline for submission is on May 15. (This Sunday, so hurry up, altough > there will probably be an extension) > > QtCon will be in Berlin, 2-4 September 2016: https://qtcon.org/ Are the talks going to be running in parallel with QtCS? Or are they at separate times? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat May 14 03:34:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 13 May 2016 18:34:57 -0700 Subject: [Development] Short QDateTime optimisation In-Reply-To: <5784738.OpFL0vJWxE@tjmaciei-mobl4> References: <5784738.OpFL0vJWxE@tjmaciei-mobl4> Message-ID: <9504599.ERri7Ymj4a@tjmaciei-mobl4> On domingo, 1 de maio de 2016 19:35:19 PDT Thiago Macieira wrote: > Hello > The changes are ready for review https://codereview.qt-project.org/157713 https://codereview.qt-project.org/158944 https://codereview.qt-project.org/158945 https://codereview.qt-project.org/158952 https://codereview.qt-project.org/158951 https://codereview.qt-project.org/159080 https://codereview.qt-project.org/159081 https://codereview.qt-project.org/159082 https://codereview.qt-project.org/158953 https://codereview.qt-project.org/159083 > https://codereview.qt-project.org/157714 https://codereview.qt-project.org/159087 https://codereview.qt-project.org/159084 https://codereview.qt-project.org/159085 Some are already approved. I had staged them, but the CI for dev appears to be stuck for 17 hours and 30 minutes as of now. And no, that wasn't after the end of Friday: the last integration start was at 10:00 CEST, so by 14:00 it should have been clear it was stuck. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mikkel at krautz.dk Sat May 14 10:19:38 2016 From: mikkel at krautz.dk (Mikkel Krautz) Date: Sat, 14 May 2016 10:19:38 +0200 Subject: [Development] CMake, PRLs, static Qt and private Qt deps Message-ID: Before Qt 5.0 was released, the CMake helper files included a useful feature that read .prl files in order to find and include Qt dependencies (such as, say, libqtpcre, but also dynamic system libraries, and whatever else) in CMake builds against a statically linked Qt. This was removed by the following change: https://codereview.qt-project.org/#/c/37307/ https://github.com/qtproject/qtbase/commit/102e1822ffcdc9954d3c698f863734a8083e349c This means that building against a static Qt simply isn't practical using Qt's CMake support, in that you'd have to manually specify the internal dependencies, or include a CMake-based prl reader in your own source tree. Are there any new developments regarding this? The code review mentions that CMake might grow to support this use case better in the future -- does anyone know whether anything has improved on that front? I realize that Qt 5.0 was a while ago, and there seemingly hasn't been any great demand for this. But it is a feature I would like to have. I'm not volunteering just yet, but would this feature be accepted back in, if implemented properly? Thanks, Mikkel P.S. If anyone's interested, there is a bit of unused code in qtbase/mkspecs//features/create_cmake.prf relating PRL files and CMake that could probably removed for now. It was only added to support this feature. From tim at klingt.org Sat May 14 14:30:47 2016 From: tim at klingt.org (Tim Blechmann) Date: Sat, 14 May 2016 14:30:47 +0200 Subject: [Development] CMake, PRLs, static Qt and private Qt deps In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Before Qt 5.0 was released, the CMake helper files included a > useful feature that read .prl files in order to find and include > Qt dependencies (such as, say, libqtpcre, but also dynamic system > libraries, and whatever else) in CMake builds against a statically > linked Qt. > > This was removed by the following change: > > https://codereview.qt-project.org/#/c/37307/ > https://github.com/qtproject/qtbase/commit/102e1822ffcdc9954d3c698f863 734a8083e349c > > This means that building against a static Qt simply isn't > practical using Qt's CMake support, in that you'd have to manually > specify the internal dependencies, or include a CMake-based prl > reader in your own source tree. > > Are there any new developments regarding this? https://bugreports.qt.io/browse/QTBUG-38913 the bug celebrated it's 2-year anniversary last week. labeled as 'Reported_by_support_silver', but i wouldn't bet that anything happens here as building qt projects with cmake doesn't seem to have any priority for the upstream devs. using private qt headers is also not possible with the upstream cmake files :/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXNxp3AAoJEAIkvWiom07DI6IQAIMxA1+ZqdtwIP46BGGAU2Nn qJUARfYYBHmQpPl4eek+Bz8gC8W4QIZnCWKYnDYUEYwKzlaeTu68Q3uF+l+7ntU3 qaMxIoo3/+WjlHOKRfI5R+li/v4Lg506pWUSCPdOBOR1Zk3/XGUxJLqYTBu1Guo7 w8g8El/7LOwO5OCPM4TKCi83B8mzqN8kwIcQyf2pYt54SE2TU3zG6EzLaAmNa8Kc SLlCj6cDb/FZ0qd1FRUSV7DPmyRyVn3mVkLBQ31HvEaxhaZ9qXJuP0XP+CC2uU5n uPLAoAYfX9KQhu2JEsIQWfFniWrHX1vh7fE3MnzJ5faXoDekHc9Il8czuRhT+x17 hqSbze4/1Z8R+gQTbSf1dqDx6mT0xhjG2p1oXwZznBFZdbS/cviCmjz7o8oOQ/PD gU22EPo+FXZztZQ3Kh0MDIEu2dBBFgTERg3yrxldTCDBmkTrYlZ2uw15U66Cv+NL QDuYIAojma2u88z9PDBfz2sT5UYyB93vTSKyx7Fo37fnmaKkai89sFVd/R9vdeko Iq/V3JgK00fNUio4ruV07wHeuZS9kl70cVYgtL408ea2p0/UbCvTeKwUmQf4MzpH Nc7H32Nz0+IyFa0fK6Ul/cFIrpHZEErbxjDSRdQI6sBgtByn780w5ITHiH8J9gDy ge0OkmpI9wUjgK2kYlIR =LAmF -----END PGP SIGNATURE----- From matnares at gmail.com Sun May 15 09:40:48 2016 From: matnares at gmail.com (=?UTF-8?B?TWF0w61hcyBOw6lzdG9yIEFyZXM=?=) Date: Sun, 15 May 2016 04:40:48 -0300 Subject: [Development] Bluetooth Services problem In-Reply-To: References: Message-ID: Problem persist in QT 5.6.1 some help will be very appreciated !! 2016-05-05 3:34 GMT-03:00 Matías Néstor Ares : > Hi Everybody!! > > I'm having an issue with bluetooth on QML on android Qt 5.6.0 > I can't even fully test the example: > http://doc.qt.io/qt-5/qtbluetooth-scanner-example.html > > trying to access service inside onServiceDiscovered: it gets undefined. > > > as documentation says : > *serviceDiscovered(BluetoothService service) * serviceDiscovered > parameter is "service" but it is undefined... > > is it a bug? is there some workaround? > > Thanks in advance. > > Best regards > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabrice.salvaire at orange.fr Sun May 15 11:38:53 2016 From: fabrice.salvaire at orange.fr (Fabrice Salvaire) Date: Sun, 15 May 2016 11:38:53 +0200 Subject: [Development] Bluetooth Services problem In-Reply-To: References: Message-ID: Hi, Indeed bluetooth is broken. Best would be to provide information for QTBUG-52277 I don't have time to investigate on it actually. Fabrice Le 05/05/2016 à 08:34, Matías Néstor Ares a écrit : > Hi Everybody!! > > I'm having an issue with bluetooth on QML on android Qt 5.6.0 > I can't even fully test the example: > http://doc.qt.io/qt-5/qtbluetooth-scanner-example.html > > trying to access service inside onServiceDiscovered: it gets undefined. > > > as documentation says : *serviceDiscovered(BluetoothService service) > * serviceDiscovered parameter is "service" but it is undefined... > > is it a bug? is there some workaround? > > Thanks in advance. > > Best regards > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Mon May 16 06:18:11 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 16 May 2016 04:18:11 +0000 Subject: [Development] Qt World Summit call for papers open In-Reply-To: <4491572.iFdVJ0cqDG@tjmaciei-mobl4> References: <2902917.mmSRBqL3HL@oscar> <4491572.iFdVJ0cqDG@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Sent: perjantaina 13. toukokuuta 2016 18.52 > To: development at qt-project.org > Subject: Re: [Development] Qt World Summit call for papers open > > On sexta-feira, 13 de maio de 2016 12:49:59 PDT Olivier Goffart wrote: > > Hi, > > In addition to the Qt World Summit, I would like to remind you about > QtCon. > > There will be the Qt Contribution summit hapening there, but it is > > also some kind of substitute for the fact that there will not be > > devdays or QtWS in europe this year. > > Any talk that is relevant for the technical track of the Qt Wold > > Summit would also be relevant for QtCon. So have a look at the call for > paper: > > https://qtcon.org/cfp > > the deadline for submission is on May 15. (This Sunday, so hurry up, > > altough there will probably be an extension) > > > > QtCon will be in Berlin, 2-4 September 2016: https://qtcon.org/ > > Are the talks going to be running in parallel with QtCS? Or are they at > separate times? > Hi, Main focus of QtCon / QtCS are Qt contributors, i.e. the usual style of QtCS talks + hopefully a bit more reaching to the other communities to get more people interested in contributing to Qt. Programme of the event is still being drafted, but I would expect that there is time to join both kinds of sessions - ones intended to get more people working closer with and contributing to Qt as well as ones intended for those already well versed in Qt internals. Main focus of QWS are Qt users, i.e. the traditional Qt DevDays talks + a bit more industry / business / tech strategy talks than before, maybe. Yours, Tuukka > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From markg85 at gmail.com Mon May 16 12:32:41 2016 From: markg85 at gmail.com (Mark Gaiser) Date: Mon, 16 May 2016 12:32:41 +0200 Subject: [Development] QVariant performance Message-ID: Hi, Just a fyi since the article might be of interest to some on this list. I just stumbled upon this github project [1]. The article and rationale for that project can be found here [2]. It claims to be a stack based "variant" implementation made for performance and as little overhead as possible. Perhaps the code has some nice tricks that could be used to make QVariant faster? QVariant in those benchmarks, as seen in [1], seems to be the slowest when compared to std::any, boost::any and his own variant. [1] https://github.com/david-grs/static_any [2] http://david-grs.github.io/low_latency_stack_based_boost_any/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Mon May 16 12:50:22 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 16 May 2016 12:50:22 +0200 Subject: [Development] QVariant performance In-Reply-To: References: Message-ID: <6098235.jhFS15pBuJ@oscar> On Montag, 16. Mai 2016 12:32:41 CEST Mark Gaiser wrote: > Hi, > > Just a fyi since the article might be of interest to some on this list. > I just stumbled upon this github project [1]. > The article and rationale for that project can be found here [2]. > > It claims to be a stack based "variant" implementation made for performance > and as little overhead as possible. Perhaps the code has some nice tricks > that could be used to make QVariant faster? QVariant in those benchmarks, > as seen in [1], seems to be the slowest when compared to std::any, > boost::any and his own variant. > > [1] https://github.com/david-grs/static_any > [2] http://david-grs.github.io/low_latency_stack_based_boost_any/ There is still this patch that saves a memory alocation for most types (like std::string used in that benchmark): https://codereview.qt-project.org/140435/ [The problem that was raised was the fact that it does not respect the alignement. But since the current implementation does not respect it either, i don't think it should be a blocker for the patch.] Of course, there is no way we can compete with static_any that stores everything on the stack. But this has nother limitations that are not desirable for a more generic QVariant. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From sean.harmer at kdab.com Mon May 16 12:52:57 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 16 May 2016 11:52:57 +0100 Subject: [Development] QVariant performance In-Reply-To: References: Message-ID: <133037016.C2fWLFJxKV@titan> On Monday 16 May 2016 12:32:41 Mark Gaiser wrote: > Hi, > > Just a fyi since the article might be of interest to some on this list. > I just stumbled upon this github project [1]. > The article and rationale for that project can be found here [2]. > > It claims to be a stack based "variant" implementation made for performance > and as little overhead as possible. Perhaps the code has some nice tricks > that could be used to make QVariant faster? QVariant in those benchmarks, > as seen in [1], seems to be the slowest when compared to std::any, > boost::any and his own variant. Thanks for the article. QVariant has to deal with dynamic type registration. This in turn leads to lots of locking of metatype information - something that profiling Qt 3D has pointed as being an issue. In the case of the article you link and for Qt 3D we have a set of known types that we need to cater for. So QVariant is too general here and some templated types will be better suited and higher performing than QVariant or any other variant like type. We have a WIP to replace the use of QVariant on the backend of Qt 3D but it would benefit all of Qt (including Qt 3D frontend to backend change notifications) if we can also improve the locking behaviour of QVariant. We have some ideas here to either use thread local storage in addition to the global metatype information registry and/or to use a scheme involving atomic compare/exchange when updating metatype registration info. Cheers, Sean > > [1] https://github.com/david-grs/static_any > [2] http://david-grs.github.io/low_latency_stack_based_boost_any/ -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From thiago.macieira at intel.com Mon May 16 17:22:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 May 2016 08:22:26 -0700 Subject: [Development] QVariant performance In-Reply-To: <133037016.C2fWLFJxKV@titan> References: <133037016.C2fWLFJxKV@titan> Message-ID: <2593477.VJZDousJlN@tjmaciei-mobl4> On segunda-feira, 16 de maio de 2016 11:52:57 PDT Sean Harmer wrote: > We have a WIP to replace the use of QVariant on the backend of Qt 3D but it > would benefit all of Qt (including Qt 3D frontend to backend change > notifications) if we can also improve the locking behaviour of QVariant. We > have some ideas here to either use thread local storage in addition to the > global metatype information registry and/or to use a scheme involving > atomic compare/exchange when updating metatype registration info. Uncontended locks in Qt are extremely cheap. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sean.harmer at kdab.com Mon May 16 19:06:27 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 16 May 2016 18:06:27 +0100 Subject: [Development] QVariant performance In-Reply-To: <2593477.VJZDousJlN@tjmaciei-mobl4> References: <133037016.C2fWLFJxKV@titan> <2593477.VJZDousJlN@tjmaciei-mobl4> Message-ID: <2065078.0M3tnt7KRH@titan> On Monday 16 May 2016 08:22:26 Thiago Macieira wrote: > On segunda-feira, 16 de maio de 2016 11:52:57 PDT Sean Harmer wrote: > > We have a WIP to replace the use of QVariant on the backend of Qt 3D but > > it > > would benefit all of Qt (including Qt 3D frontend to backend change > > notifications) if we can also improve the locking behaviour of QVariant. > > We > > have some ideas here to either use thread local storage in addition to the > > global metatype information registry and/or to use a scheme involving > > atomic compare/exchange when updating metatype registration info. > > Uncontended locks in Qt are extremely cheap. They're better now than they were since Olivier rewrote QReadWriteLock recently. Probably the biggest hit we see from the use of QVariant in Qt 3D these days is the memory allocations for passing around QMatrix4x4's in them. We will soon replace these with a strongly typed alternative. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From thiago.macieira at intel.com Mon May 16 22:31:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 May 2016 13:31:59 -0700 Subject: [Development] QVariant performance In-Reply-To: <2065078.0M3tnt7KRH@titan> References: <2593477.VJZDousJlN@tjmaciei-mobl4> <2065078.0M3tnt7KRH@titan> Message-ID: <2251341.8XpxdrCYmo@tjmaciei-mobl4> On segunda-feira, 16 de maio de 2016 18:06:27 PDT Sean Harmer wrote: > > Uncontended locks in Qt are extremely cheap. > > They're better now than they were since Olivier rewrote QReadWriteLock > recently. I have a mind to see if a solution inspired by the WTF::Lock solution (see https://webkit.org/blog/6161/locking-in-webkit/ ) to see if QWaitCondition performance would improve and if we could get rid of the ugly freelist backing QMutex on non-futex platforms. But if I can't get benefit for QWaitCondition, then I won't bother. Platforms without futex will suffer and people should just get a better OS instead (like Linux or Windows 8). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon May 16 22:42:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 May 2016 13:42:32 -0700 Subject: [Development] =?utf-8?q?dev_CI_integration_stuck_for_3=C2=BD_days?= Message-ID: <9093003.uVVIQWAqJl@tjmaciei-mobl4> Will someone PLEASE look into the qtbase/dev integration? https://codereview.qt-project.org/156523 has been integrating for (at the time of writing this email) 84 and a half hours -- 3.5 days -- and that's including two full working days in Finland, one in Germany and Norway as today is is a bank holiday in those countries. I believe we'll break the record by the time someone gets around to fixing this, if we haven't yet. Let's not hope we have to wait until after tomorrow's holiday in Norway for it to get back to working. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Mon May 16 23:06:31 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 16 May 2016 23:06:31 +0200 Subject: [Development] QVariant performance In-Reply-To: <2065078.0M3tnt7KRH@titan> References: <2593477.VJZDousJlN@tjmaciei-mobl4> <2065078.0M3tnt7KRH@titan> Message-ID: <3768848.EN6HPfYbFU@oscar> On Montag, 16. Mai 2016 18:06:27 CEST Sean Harmer wrote: > Probably the biggest hit we see from the use of QVariant in Qt 3D these days > is the memory allocations for passing around QMatrix4x4's in them. We will > soon replace these with a strongly typed alternative. Can you try this patch to see if this improve the situation? https://codereview.qt-project.org/140435/ (There should be one memory allocation instead of two) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Simon.Hausmann at qt.io Tue May 17 08:08:50 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 17 May 2016 06:08:50 +0000 Subject: [Development] =?iso-8859-1?q?dev_CI_integration_stuck_for_3=BD_da?= =?iso-8859-1?q?ys?= In-Reply-To: <9093003.uVVIQWAqJl@tjmaciei-mobl4> References: <9093003.uVVIQWAqJl@tjmaciei-mobl4> Message-ID: Hi, I just looked into it and it looks like an inconsistency in the gerrit database. The latest builds branch points to a set of changes that are in staged state, while the change that is in integrating change is not in that branch. I've found the build branch that had the integrating change and rejected the change (and staged it again). It appears that the change was staged Friday morning and nobody noticed it during Friday. Then came a long weekend, with Monday off and Tuesday also off in Norway. Simon ________________________________________ From: Development on behalf of Thiago Macieira Sent: Monday, May 16, 2016 10:42:32 PM To: development at qt-project.org Subject: [Development] dev CI integration stuck for 3½ days Will someone PLEASE look into the qtbase/dev integration? https://codereview.qt-project.org/156523 has been integrating for (at the time of writing this email) 84 and a half hours -- 3.5 days -- and that's including two full working days in Finland, one in Germany and Norway as today is is a bank holiday in those countries. I believe we'll break the record by the time someone gets around to fixing this, if we haven't yet. Let's not hope we have to wait until after tomorrow's holiday in Norway for it to get back to working. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From skostysh at lyx.org Tue May 17 08:30:17 2016 From: skostysh at lyx.org (Scott Kostyshak) Date: Tue, 17 May 2016 02:30:17 -0400 Subject: [Development] Regression from 5.5.1 to 5.6.0 affecting LyX release Message-ID: <20160517063017.ocv3fto3zvc2mg5i@cotopaxi> Dear all, Behavior has changed between Qt 5.5.1 and Qt 5.6.0 and I would like to confirm that it is indeed a bug, and also ask if someone can suggest a workaround? The bug report is posted here: https://bugreports.qt.io/browse/QTBUG-53272 I posted on qt-interest [1], but did not get any bites and since it is related to the development of Qt I'm asking here. It is affecting our LyX 2.2.0 release so any advice would be appreciated. Scott [1] http://lists.qt-project.org/pipermail/interest/2016-May/022658.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From thiago.macieira at intel.com Tue May 17 08:43:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 May 2016 23:43:36 -0700 Subject: [Development] =?utf-8?q?dev_CI_integration_stuck_for_3=C2=BD_days?= In-Reply-To: References: <9093003.uVVIQWAqJl@tjmaciei-mobl4> Message-ID: <2214043.hyfFyfdyLP@tjmaciei-mobl4> On terça-feira, 17 de maio de 2016 06:08:50 PDT Simon Hausmann wrote: > Hi, > > I just looked into it and it looks like an inconsistency in the gerrit > database. The latest builds branch points to a set of changes that are in > staged state, while the change that is in integrating change is not in that > branch. I've found the build branch that had the integrating change and > rejected the change (and staged it again). > > It appears that the change was staged Friday morning and nobody noticed it > during Friday. Then came a long weekend, with Monday off and Tuesday also > off in Norway. Thanks Simon. For anyone keeping score, this was 94 hours. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at qt.io Tue May 17 08:55:36 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Tue, 17 May 2016 06:55:36 +0000 Subject: [Development] Bluetooth Services problem In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Matías Néstor > Ares > Sent: Sunday, 15 May 2016 9:41 > To: > Subject: Re: [Development] Bluetooth Services problem > > Problem persist in QT 5.6.1 > some help will be very appreciated !! What platform are you using QtBluetooth on? (Bluez, Android, iOS and what particular version) Please state the qtconnectivity SHA that you are using for your 5.6.1 build! Which particular discovery mode triggers the warning (full or minimal)? What exactly is printed in your command line when onServiceDiscovered is triggered? -- Alex > 2016-05-05 3:34 GMT-03:00 Matías Néstor Ares >: > > > Hi Everybody!! > > I'm having an issue with bluetooth on QML on android Qt 5.6.0 > I can't even fully test the example: > http://doc.qt.io/qt-5/qtbluetooth-scanner-example.html > > trying to access service inside onServiceDiscovered: it gets undefined. > > > as documentation says : serviceDiscovered(BluetoothService service) > serviceDiscovered parameter is "service" but it is undefined... > > is it a bug? is there some workaround? > > Thanks in advance. > > Best regards > From marc.mutz at kdab.com Tue May 17 09:28:19 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 17 May 2016 09:28:19 +0200 Subject: [Development] QVariant performance In-Reply-To: <133037016.C2fWLFJxKV@titan> References: <133037016.C2fWLFJxKV@titan> Message-ID: <201605170928.21373.marc.mutz@kdab.com> On Monday 16 May 2016 12:52:57 Sean Harmer wrote: > We have a WIP to replace the use of QVariant on the backend of Qt 3D but > it would benefit all of Qt (including Qt 3D frontend to backend change > notifications) if we can also improve the locking behaviour of QVariant. > We have some ideas here to either use thread local storage in addition to > the global metatype information registry and/or to use a scheme involving > atomic compare/exchange when updating metatype registration info. Almost complete lockless metatype registry: https://codereview.qt-project.org/30559 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From matnares at gmail.com Tue May 17 11:45:53 2016 From: matnares at gmail.com (=?UTF-8?B?TWF0w61hcyBOw6lzdG9yIEFyZXM=?=) Date: Tue, 17 May 2016 06:45:53 -0300 Subject: [Development] Bluetooth Services problem In-Reply-To: References: Message-ID: Hello Alex, nice to meet you. I'm working on an android app right now. The issue is the same in many devices, (tablets and phones). I'm using QT 5.6.0 and 5.6.1 using android NDK r10e version (I will update to 11) Both, I downloaded from http://download.qt.io/snapshots/qt/5.6/ *How do I check the SHA ?* in both *full* or *minimal* discovery is the same symptom. inside onServiceDiscovered "service" is undefined. for example: in the BTscanner example File: scanner.qml the execution of line : onServiceDiscovered: console.log("Found new service " + *service.deviceAddress* + " " + service.deviceName + " " + service.serviceName); throw : TypeError: Cannot read property *'deviceAddress'* of undefined I take a look to the source file qtconnectivity/src/imports/bluetooth/qdeclarativebluetoothdiscoverymodel.cpp and I see the emit serviceDiscovered(bs); line is passing a pointer QDeclarativeBluetoothService *bs = new QDeclarativeBluetoothService(service, this); I'm not sure, but maybe, it is relate to other issue i have experienced. I was using grabToImage in qml to pass an image to a C++ function: Something like this: QML: var m_status = testIMG.grabToImage(function(imgResult) { CPPClass.analyzeImage(imgResult.image) }); CPP: (Header File) QString analyzeImage(QImage &image); Previously on Qt 5.5 that was working OK But after upgrading to Qt 5.6 it stop working. I changed QString analyzeImage(QImage *&*image); to QString analyzeImage(QImage image); and it is working again. It was broken in linux desktop and android, i have not tested other platforms yet. (Obviously I prefer the previous way) So my hypothesis is: Maybe something related with passing References and Pointers between C++ and QML is broken. I really have no time to get my hands deeper in the Qt code to confirm this hypothesis. But I think the problem may be related somehow. is there some other information you need? please let me know Best Regards. 2016-05-17 3:55 GMT-03:00 Alexander Blasche : > > > > -----Original Message----- > > From: Development [mailto:development- > > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Matías > Néstor > > Ares > > Sent: Sunday, 15 May 2016 9:41 > > To: > > Subject: Re: [Development] Bluetooth Services problem > > > > Problem persist in QT 5.6.1 > > some help will be very appreciated !! > > What platform are you using QtBluetooth on? (Bluez, Android, iOS and what > particular version) > Please state the qtconnectivity SHA that you are using for your 5.6.1 > build! > Which particular discovery mode triggers the warning (full or minimal)? > What exactly is printed in your command line when onServiceDiscovered is > triggered? > > -- > Alex > > > 2016-05-05 3:34 GMT-03:00 Matías Néstor Ares > >: > > > > > > Hi Everybody!! > > > > I'm having an issue with bluetooth on QML on android Qt 5.6.0 > > I can't even fully test the example: > > http://doc.qt.io/qt-5/qtbluetooth-scanner-example.html > > > > trying to access service inside onServiceDiscovered: it gets > undefined. > > > > > > as documentation says : serviceDiscovered(BluetoothService > service) > > serviceDiscovered parameter is "service" but it is undefined... > > > > is it a bug? is there some workaround? > > > > Thanks in advance. > > > > Best regards > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Tue May 17 12:49:17 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 17 May 2016 12:49:17 +0200 Subject: [Development] =?iso-8859-1?q?dev_CI_integration_stuck_for_3=BD_da?= =?iso-8859-1?q?ys?= In-Reply-To: References: <9093003.uVVIQWAqJl@tjmaciei-mobl4> Message-ID: <20160517104917.GG24382@troll08.it.local> On Tue, May 17, 2016 at 06:08:50AM +0000, Simon Hausmann wrote: > I just looked into it and it looks like an inconsistency in the gerrit database. The latest builds branch points to a set of changes that are in staged state, while the change that is in integrating change is not in that branch. I've found the build branch that had the integrating change and rejected the change (and staged it again). > yes, fregl (or nierob?) diagnosed that there was a network outage during the time the CI was supposed to report the result to gerrit, and the system apparently has no queue/retry mechanism for this. so it's out of sync now. Somebody (TM) needs to (re-)execute the relevant commands by hand ... > It appears that the change was staged Friday morning and nobody noticed it during Friday. Then came a long weekend, with Monday off and Tuesday also off in Norway. > > Simon > ________________________________________ > From: Development on behalf of Thiago Macieira > Sent: Monday, May 16, 2016 10:42:32 PM > To: development at qt-project.org > Subject: [Development] dev CI integration stuck for 3½ days > > Will someone PLEASE look into the qtbase/dev integration? > > https://codereview.qt-project.org/156523 has been integrating for (at the time > of writing this email) 84 and a half hours -- 3.5 days -- and that's including > two full working days in Finland, one in Germany and Norway as today is is a > bank holiday in those countries. I believe we'll break the record by the time > someone gets around to fixing this, if we haven't yet. > > Let's not hope we have to wait until after tomorrow's holiday in Norway for it > to get back to working. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Tue May 17 15:45:41 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 17 May 2016 15:45:41 +0200 Subject: [Development] [HEADS UP]: gerrit notification mails lost Message-ID: <20160517134541.GA5104@troll08.it.local> somewhen in the last days, gerrit started to silently fail to send most notification mails. the problem was "fixed" with a restart, but the already missed notifications are lost. so it is a good idea to check your dashboard for recent activity if you're usually relying on a notification-based workflow. From sorokin.vasiliy at gmail.com Tue May 17 16:29:35 2016 From: sorokin.vasiliy at gmail.com (Sorokin Vasiliy) Date: Tue, 17 May 2016 17:29:35 +0300 Subject: [Development] QML Signal handlers order. Message-ID: Hello. Example: MyButton.qml import QtQuick 2.5 import QtQuick.Controls 1.4 Button { onClicked: { console.log("inner") } } mail.qml import QtQuick 2.5 import QtQuick.Window 2.2 import QtQuick.Controls 1.4 Window { visible: true MyButton { text: "OK" onClicked: { console.log("outter") } } } When I click on button I got this output: qml: inner qml: outter And my question is: Is this calls order guaranteed? -- Best Regards, Vasiliy Sorokin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sorokin.vasiliy at gmail.com Tue May 17 16:58:27 2016 From: sorokin.vasiliy at gmail.com (Sorokin Vasiliy) Date: Tue, 17 May 2016 17:58:27 +0300 Subject: [Development] QML Signal handlers order. Message-ID: Hello. Example: MyButton.qml import QtQuick 2.5 import QtQuick.Controls 1.4 Button { onClicked: { console.log("inner") } } mail.qml import QtQuick 2.5 import QtQuick.Window 2.2 import QtQuick.Controls 1.4 Window { visible: true MyButton { text: "OK" onClicked: { console.log("outter") } } } When I click on button I got this output: qml: inner qml: outter And my question is: Is this calls order guaranteed? -- Best Regards, Vasiliy Sorokin -------------- next part -------------- An HTML attachment was scrubbed... URL: From filippocucchetto at gmail.com Tue May 17 20:07:34 2016 From: filippocucchetto at gmail.com (filippocucchetto at gmail.com) Date: Tue, 17 May 2016 20:07:34 +0200 Subject: [Development] QML Signal handlers order. In-Reply-To: References: Message-ID: <2744371.WOkcots9Eu@as5951g> On martedì 17 maggio 2016 17:58:27 CEST Sorokin Vasiliy wrote: > Hello. > > Example: > > MyButton.qml > > import QtQuick 2.5 > > import QtQuick.Controls 1.4 > > > Button { > > onClicked: { > > console.log("inner") > > } > > } > > > mail.qml > > import QtQuick 2.5 > > import QtQuick.Window 2.2 > > import QtQuick.Controls 1.4 > > Window { > > visible: true > > > MyButton { > > text: "OK" > > onClicked: { > > console.log("outter") > > } > > } > > } > > > When I click on button I got this output: > > > qml: inner > > qml: outter > > And my question is: > > Is this calls order guaranteed? > > -- > Best Regards, > Vasiliy Sorokin Hi, AFAIK you shouldn't rely on any order of execution of slots invoked by a signal invokation. See http://doc.qt.io/qt-5.6/signalsandslots.html#signals in particular """ If several slots are connected to one signal, the slots will be executed one after the other, in the order they have been connected, when the signal is emitted. """ Obviously what you wrote it's just a little example but there're lot of ways to solve it: 1) Add a different signal to My Button Button { ... signal afterClicked() onClicked: { // Do something afterClicked() } } 2) Hide the inner clicked signal Item { id: root signal clicked() Button { onClicked: { // Do something root.clicked() } } } From sylvain at sylvaingarrigues.com Tue May 17 22:50:59 2016 From: sylvain at sylvaingarrigues.com (Sylvain Garrigues) Date: Tue, 17 May 2016 22:50:59 +0200 Subject: [Development] FreeBSD / Clang / Raspberry Pi Message-ID: <1FC83DB6-54E4-410D-A533-73E8768D9F73@sylvaingarrigues.com> Hello, I have ported Qt 5.6 to FreeBSD / Raspberry Pi and would like to share my config. I have a question though. I have created a « device » mkspec (mkspecs/device/freebsd-rasp-pi-clang/ to follow the scheme) and I am using it with '-platform freebsd-clang -device freebsd-rasp-pi-clang’ but technically *I am not cross-compiling* as either the port is built on the Pi or it will later be on the FreeBSD packages building infrastructures which runs QEMU arm simulators which emulate a complete arm system (filesystem, kernel, etc). Therefore it’s always an arm compiler producing arm binaries on a freebsd system - no cross compiling. So should I just create a mkspecs/freebsd-clang-rasp-pi/ in the top mkspecs folder and just use -platform freebsd-clang-rasp-pi? (no -device option) I can see that using a device is triggering a cross_compile qmake feature with configure, and it has side effects (e.g. no stripping) - hence the question. Happy to hear your thoughts. Sylvain. From jani.heikkinen at qt.io Wed May 18 06:44:45 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 18 May 2016 04:44:45 +0000 Subject: [Development] New Qt 5.7.0 RC snapshot available Message-ID: Hi all, New Qt 5.7.0 RC snapshot available Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/456/ Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/424/ Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/354/ src: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/latest_src/submodules/ Packages are RTA sanity checked and everything seems to be pretty much Ok. So please test the packages and make sure all Qt 5.7.0 blockers are visible in https://bugreports.qt.io/issues/?filter=17619. We are planning to release Qt 5.7.0 rc 1st of June and so on all blockers must be fixed latest 23rd May. Then we have enough time to integrate changes in qt5.qit, create and test the packages before rc. Known issues in the packages: - WebEngine and WebView missing from 32 bit windows packages - Serialbus missing form Windows Android packages - VKB and qtquickcontrols2 example paths are wrong Last qt5.git integration in these packages: https://codereview.qt-project.org/#/c/156546/ Patch Set 26: Code-Review+2 Sanity-Review+1 qt/qt3d 7c9331e953700e4c35e4bd3d51ebc49e4c3b0f80..faf56f50608f9391d2a73ed7c61bfdd9c2afab78: > Make QSceneChange ctor protected to prevent direct use > Split out QPropertyValue[Added|Removed] classes > Rename QNodeRemovedPropertyChange -> QPropertyNodeRemovedChange > Rename QNodeAddedPropertyChange -> QPropertyNodeAddedChange > QNode[Added|Removed]PropertyChange inheritance changed > Add QStaticPropertyValueRemovedChangeBase > Add QStaticPropertyValueAddedChangeBase > Make typed property change a private header template > QNodePropertyChange -> QPropertyUpdatedChange > QNodePropertyChangeBase -> QStaticPropertyUpdatedChangeBase > QNodeDynamicPropertyChange -> QDynamicPropertyUpdatedChange > Rename QNodePropertyChangeBase -> QPropertyChangeBase > Mark QNodeUpdatedChangeBase ctor protected and export class > Make ctors explicit, provide out of line dtors and export classes > Remove QSceneChange::SenderType > Change arbiter checks DeliveryFlags > QBackendNodePropertyChange sets delivery flags to all > Add setter/getter for delivery flags to QSceneChange > Remove unnecessary forward declaration and move another > Remove QSceneChange::timestamp() > Remove ChangeFlag from NodeUpdated change type ctors > Temporarily remove use of a custom allocator for QNodePropertyChanges > Change inheritance of QNode[Added|Removed]PropertyChange > Move change classes into their own dir and tidy up .pro/.pri files > Add QPropertyValueRemovedChangeBase > Add QPropertyValueAddedChangeBase > Rename NodeAdded/NodeRemoved ChangeFlags > Rename NodeUpdated ChangeFlag to PropertyUpdated > Fix compilation on MSVC2013 > Fix reset in bigmodel example > Add QNode::notifyObservers() > QRenderState needs to create creation changes too > Set QObject parent immediately and defer backend notifications > qgltf: fix GCC 6 warning about misleading indention > ShaderParameterPack: use rvalue QVector::push_back > ShaderParameterPack: fix parameter passing (II) > ShaderParameterPack: fix parameter passing (I) > Mark more types movable/primitive/shared > Removing defunct examples - Cpp_example > QShaderData should notify dynamic property changes > Add convenience to notify dynamic property changes > Add missing pointer typedef > Properly export QNodeDynamicPropertyChange symbols > Replaced FPS Camera with Orbit - Custom-mesh-cpp > Replaced FPS Camera with Orbit - Custom-mesh > Replaced FPS Camera with Orbit - Loader-qml > Replaced FPS Camera with Orbit - MouseInpt > Replaced FPS Camera with Orbit - Simple-cpp > Replaced FPS Camera with Orbit - Simple-qml > Replaced FPS Camera with Orbit - Smpl Shader > Replaced FPS Camera with Orbit - Tessellation > Add missing "We mean it" warnings > Add QNodeDynamicPropertyChange class > Change QNodePropertyChangeBase to inherit from QNodeUpdatedChangeBase > Add QNodeUpdatedChangeBase > Remove unneeded ctors from QSceneChange and subclasses > Add Q_DECL_NOEXCEPT to getters in QSceneChange > Cleanup defunct comment in qscenechange.h > Rename ObserverType to SenderType in QSceneChange > Port missing examples to the new Layer(Filter) API > Removing defunct examples - Torus-qml > Removing defunct examples - Playground-qml > Remove NodeAboutToBeDeleted change type enum value > GLTFIO: claim copyright for the substantial recent changes > GLTFIO: move QFile::readAll() into resolveLocalData() > GLTFIO: replace QMap with QHash > GLTFIO: includemocs > GLTFIO: use printf-style qWarning/qDebug where possible > GLTFIO: wrap remaining qWarning()s in Q_UNLIKELY > GLTFIO: replace static const QLatin1Strings with #defines > GLTFIO: brush up ctors of nested structs > GLTFIO: avoid some hidden detaches > GLTFIO: remove {QMap,QMultiHash}::remove() calls > GLTFIO: eradicate remaining Q_FOREACH loops > GLTFIO: remove {QMap,QMultiHash}::contains() calls > GLTFIO: fix leak of QShaderProgram in processJSONProgram() > GLTFIO: don't iterate over QMap::values() > GLTFIO: don't iterate over QMap::keys() > GLTFIO: don't iterate over QJsonObject::keys() > GLTFIO: replace QStringLiteral and C literals with QLatin1Strings in comparisons > GLTFIO: the standard uniform name isn't actually needed > GLTFIO: use QLatin1String instead of QStringLiteral > GLTFIO: remove QJsonObject::contains() calls > QRenderAspect: use QSharedPointer::create() > render: eradicate Q_FOREACH loops [remaining low-risk] > input/frontend: eradicate Q_FOREACH loops [low-risk] > render/materialsystem: eradicate Q_FOREACH loops [low-risk] > render/framegraph: eradicate Q_FOREACH loops [low-risk] > QAbstractPhysicalDeviceBackendNode: remove unused function > Introduce local macros for declaring types as movable/primitive/shared > Send shader data's property reader to the backend > Add another missing Qt3DExtras import. > Don't hide function in base class change > Don't set null as event source > Add firstVertex to QGeometryRenderer API > Get rid of QLayer::names > Update docs/examples: QClearBuffer -> QClearBuffers > Adjust LayerFilter's layers property behavior > Change QList properties to QVector > Add more missing Qt3D.Extras imports to the examples. > QClearBuffers: clear specific QRenderTargetOutputs > Fix for loading using a Mesh > Remove setTargetNode()/targetNode() from backend property changes > Introduce QTypedBackendNodePropertyChange > Add missing import Qt3D.Extras to wave example > Introduce QBackendNodePropertyChangeBase class > Camera controller naming convention > Get metaobject directly from the QObject > Remove QBackendNode::updateFromPeer() > QTexImageData to QTextureImageData > Remove cloning from QGamepadInput > Fix qmltypes generation, add them to the sources > Don't crash when introspected by qmlplugindump > Make sure this is a NodeUpdated change > Make QSceneIOPlugin private for the time being > Fix CLANG reported warnings > Bring more type safety to the buttons properties > Rename QSceneParserPlugin to QSceneIOPlugin > Make QInputDevicePlugin and friends private > Remove TransformType from the public API > Turn QAxisInput into QAbstractAxisInput > Split QAnalogAxisInput out of QAxisInput > Remove unused function > Splitting of QAxisInput > Fixed picking example > Remove QbackendNode::setPeer(QNode *) > QObjectPicker creates and handles creation changes > Add QBackendNodeTester to enable testing of QBackendNode private methods > Remove virtual QBackendNode *create(QNode *frontend) const > Tidy QBackendNode a little > Remove unused map of clones > Remove temporary envvar for trying no clone approach > Tidy up comments in QNode > Make QAbstractNodeFactory private > Q_NULLPTR -> nullptr > Fix -Wreorder warning in renderer > Fix trianglevisitor traversing triangle strips > Add we mean it to qfirstpersoncameracontroller_p.h > Add we mean it to QGraphicsApiFilter header > Fix warning in Renderer > tst_trianglesextractor: fix test to pass > QNodeRemovedChange: contains QNodeIdTypePair > QAbstractAspect: remove all traces of cloning > QNodeAddedChange: contains a QNodeIdTypePair > QAbstractAspect: remove cloning code path > Move last remaining pieces of examples-common to Qt3DExtras > QNode: initialize m_typeInfo to Q_NULLPTR > Add missing import for Qt3DExtras. > ShaderData: Comment out NodeAdded/Removed sections > geometries: use QSharedPointer::create() for QBufferDataGenerators > GenericDeviceBackendNode: aggregate mutex by value > QThreadPooler: aggregate mutex by value > QRayCastingService: don't iterate over QHash::values() > QItemModelBuffer: don't iterate over QHash::keys() > InputChord: replace a Q_FOREACH with assignment > QAspectEngine: replace a Q_FOREACH loop with qDeleteAll() > input/backend: eradicate Q_FOREACH loops [low-risk] > render/jobs: eradicate Q_FOREACH loops [low-risk] > PickBoundingVolumeJob: optimize EntityGatherer > Make QNodeDestroyedChange public > Move QNodeIdPair into qnode.h > QLayer/Layer create and handle creation changes > QRenderTarget/RenderTarget create and handles creation changes > QNodeCreation overhaul > Strip out cloning subsystem > Fix memory leaks in render aspect > Fix memory leaks in renderer > render/frontend: eradicate Q_FOREACH loops [low-risk] > QSortPolicy: fix argument passing > Handle case where rendersurfaceselector is root of the FG > Fix wave example > Adapt the assimp scene parser to use the node factory > Only try to move scene subtree if non null > QSortPolicy fix > Fix direction for directional and spot lights > Repair attenuation handling > Repair this example > QAbstractLight now inherits directly QComponent > Don’t expose QGenericInputDevice to QML > Whitespace fix > QShaderData also recognizes dynamic properties > Prevent QAbstractLight instances creation > Make the type property read-only on QAbstractLight > Don't copy non-writable properties > Rename QLight to QAbstractLight > Activate input handling > Fix attenuation use in SpotLight > MouseEventFilter: handle HoverMove events > Scene3DItem: add the hoverEnabled property > Fix memory leaks in input > Fix memory leaks in openglvertexarrayobject > De-inline some polymorphic dtors > Fix: restore FilterKeyManager > Fix forward declare of struct GraphicsApiFilterData > Render::Renderer: eradicate remaining Q_FOREACH loop > render/backend: eradicate Q_FOREACH loops [low-risk] > QThreadPooler: QVector::clear() no longer sheds capacity > QThreadPooler: minimize critical section > Fix static builds > Make public headers compile with -Wzero-as-null-pointer-constant > GeometryRenderer use new added/removed change types > Texture use new added/removed change types > Technique use new added/removed change types > RenderPass use new added/removed change types > Material use new added/removed change types > Effect use new added/removed change types > QGeometry use new added/removed change types > QTechniqueFilter use new added/removed change types > Rename QTechniqueFilter::criteria() to matchAll() > QRenderState use new added/removed change types > RenderPassFilter use new added/removed change types > RenderTarget use new added/removed change types > AbstractPhysicalDevice use new added/removed change types > QLogicalDevice/LogicalDevice use new added/removed change types > QInputSequence/InputSequence use new added/removed change types > QInputChord/InputChord use new added/removed change types > QAxis/Axis use new added/removed change types > QAction/Action use new added/removed change types > Add change type for NodeRemoved changes > Add a specific change type for NodeAdded changes > Moves QSortCriterion flag to QSortPolicy and remove it > QGraphicsApiFilter: get rid of the copy method > Technique/Renderer: use GraphicsShaderData > QGraphicsApiFilter: move all members to dedicated struct > ShaderData: implement initializeFromPeer > QShaderData: add createNodeCreationChange member function > Fix memory leaks in aspects > Fix QGamepadInput > QGoochMaterial export and documentation fix > QGoochMaterial namespace fix > QParameter: don't manually send property change > standardUniformSetter bug fix > QNode: make cleanup a private slot > Move defaults and geometries out of Qt3DRender and into Qt3DExtras > Rename QBackendScenePropertyChange -> QBackendNodePropertyChange > QBackendScenePropertyChange cleanups > Add convenience ctors that set the change type and observable type > Fix -Wreorder warning > Fix TextureImage source update. > Add Mouse Wheel event handling in the backend > QVectorize Quick3DShaderDataArray > Fix comparison of enums > Rename QScenePropertyChange -> QNodePropertyChange > Introduce a new base class for node property change events > If scene has more than one mesh, only the last one added can be modified > Added the rest of Qt3DCore doc skeletons > Fix rendering when having multiple leaf nodes in framegraph > Add new example to demonstrate dynamic component addition/removal > Use new component added/removed changes > Add change types for component added/removed > Silence some unused variable warnings > QVectorize QRenderTargetSelector > Fix ClearColor for Scene3D usage. > QFrameAction: remove virtual on onTriggered > Fix make TextureImage ReadWrite > QVectorize PointLightBlock > Handle frontend texture change status > AntiAliasing added as Renderstate > QSceneLoader now avoids cloning > Cleanup assimp example a little > QVectorize QAspectManager qt/qtwebengine 7d172fcf39fa2a5d7d5202f20c599eb678f6cb58..023168cf91dc7ac11ced1b6a60ca7aa248987810: > Change messagebox in simplebrowser example > Remove notifier signals for spellchecking support > Fix debug-only build on Windows > Merge remote-tracking branch 'origin/5.6' into 5.7 > Remove spellchecking support > Add spellcheck autotest > Adds qwebengine_convert_dict tool > Use empty default values in spellcheck init > Doc: Document how dictionaries are loaded > Remove warnings about missing dictionaries > Provide a debug version of QtWebEngineProcess > Doc: How recentlyAudibleChanged and setMuted interact > Combine candidate icons for a page into a single icon > Remove availableDictionaries from spellcheck api > Update Chromium > Get additional sanitizer dependencies from upstream chromium. > Cleanup license leftovers > Revert "Fix unexpected passes in tst_QWebEnginePage." > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > Add missing icon getter and corresponding signal to QWebEngineView > Make public API test up to date > Remove WebAudio settings > Replace print dialog with a custom one for printing to pdf. > Disable extensions at compile time > Cleanup copyright and origin in src/core > Copyright cleanup in core/renderer sources > Implement hooks for pepper isolated filesystem > [OSX] Try and load the widevine plugin where Chrome looks for it. > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > Add icon role to WebEngineHistoryListModel > Add changes-5.7.0 > Update Chromium > Parse logging verbosity levels > SimpleBrowser: Use new QWebEnginePage::icon API > Add QQuickWebEngineFaviconProvider > Add comments to new ResourceType enums qt/qtscxml 7e885ef3952830b9683d145aadc592c66cec180d..bdbe7d947a65070b59ac24cf9f05247037863ef8: > Fix valid children according to scxml specification > Set the event type of done.state events to internal. > Add qmltypes file to QtScxml types > Remove dead code > Don't leak m_doc->root when nested occurred. > Fix the event's debugString(). qt/qtsensors 33d15b76dfdb95da5970b8e0294bbb87ea1eb9a8..f32489e379805c51b28ae5d471491a649283fd8d: > Update QtSensors QML version for Qt 5.7 release qt/qtserialbus 1675a0d726e5c07c275c0981cc3deb5ffbcc6afc..ad54496cce03077073660c5c440b0f45b7e46496: > Merge remote-tracking branch 'origin/5.6' into 5.7 qt/qtdeclarative 9bb640625d1e929f8caac34fa0a0fedeef8687ca..531d00c1909527cb1bc28f17197267ccde408b0c: > QML: Fix anchors on Windows. > QML: Remove internal field padding from QQuickAnchorPrivate. > Merge remote-tracking branch 'origin/5.6.1' into 5.7 > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > QQuickWindowPrivate: Only update transform on polish if needed > V4: make QQmlEnginePrivate::dereferenceScarceResources inlinable. > Docs: Prefer Q_ENUM over Q_ENUMS > Add QVector support to JS sequences > Fix qmlimportscanner to find Qt Quick Controls 2 styles > Add Qt::ImInputItemClipRectangle support to QtQuick items > Quick: expose movementDirection of PathView > QmlProfiler: Reduce memory usage for file names and URLs > V4 profiler: Don't duplicate function locations > QML: Fix qmlplugindump Info.plist > QML: Replace qIsFinite with qt_is_finite. > qmlplugindump: skip "private" directories. > Abort application if QJSEngine is constructed before QCoreApplication > Particles: Invalidate all group IDs when groups are reset. > Qml: use qDeleteAll more > QmlProfiler: Pass detailType directly, rather than as a bit field > Merge remote-tracking branch 'origin/5.6' into 5.7 > Use QStringRef to optimize memory allocation > Fix performance issues when handling layout changed in Quick item views. > QML: Drop unnecessary include > QmlDebug: Adapt to renaming of Qt Creators "QML/JS" console > QQuickTextInput: Listen for changes to cursorFlashTime > QQuickTextControlPrivate: Listen for changes to cursorFlashTime > Allow target path version in a parent module > Minor cleanup: Remove unused forward declaration > Fix assertion in qt_create_image_data() qt/qtmultimedia 7f286e0965eb31f29c68b1c1e32d2653ae34014e..08e13bfcdb23eabfbc47bca7499b0b8aadce0ac7: > Merge remote-tracking branch 'origin/5.6' into 5.7 > Skip integration tests when the service is not available. > Update QML revisions for CameraImageProcessing > Do not pin Multimedia QML module version > DirectShow: Improve error handling. > Update qmltypes for Qt Multimedia > Mark CameraImageProcessing's new brightness property with revision 2 > Add new QDeclarativePlayList 5.7 items with new QML revision > Add missing \since tag for brightness property > Blacklist tst_qaudioinput and tst_qaudiooutput tests from OpenSUSE 42.1 > Add missing implementation for QMediaPlaylist::moveMedia(). > tst_qaudioinput blacklist pushSuspendResume on RHEL 7.2 > Fix unused variable warning > Blacklist qtmultimedia autotests that have been failing since RHEL 6.6 qt/qtlocation e41c3a9b345536ccee0840ac6f049173aa6a0785..761331ddc841809a4bdc6ca2f2b84c148cb9b19a: > Fix build > Update QML version to 5.7 for QtPositioning and QtLocation > Map.copyrightsVisible is a new property since 5.7 qt/qttranslations 745f8d5329d0d6d98a8577a254d2ee3e7174634e..c95337f7e974c75a88b96c168b6056a1642399bb: > Update Russian translation > Update German translations for 5.7. > make .qm targets depend on lrelease executable qt/qtqa 4704f79e9be910d9859d2649aa6a060f58c05bf8..32893be6fa2c1068df16479979acf9b3ba7f6bcd: > Fix benchmark result separation for table driven tests > Fix formatting of percentage display in the footer > purge symbian vestige qt/qtdatavis3d 8427634773505f73ce030cf68761c4719eb03e5c..2f6074fde0ec050c77f881e0d2ce265fa93a0fcc: > Prospective fix for documentation build > Skip build for missing opengl dependencies > Renamed qdocconf qt/qtdoc 619297421f5fd5f89768cc4161b4f3a7a5c3d575..65397e8c9d7a30bd8a07bfa866ded1428532b840: > Doc: Add What's new for Qt 5.7 > Move Qt Quick Controls 2 from Tech Previews to Add-Ons qt/qtserialport 84feab670cce8414ad54f4d19b46291c7fdb14cf..a11fa1dfd529948da961d3d292926a15f9b7005b: > Drop the Win CE support qt/qtpurchasing 114352e123021488e14fa81aa154195cbe1ad509..0afcd2efe2c33bbbd5d9b1edc47b0fcccb6ce8c2: > Fix crash when requerying product before previous completed > Use Android SDK detection feature instead of hardcoding > Remove debug output from Android backend > QMacInAppPurchaseTransaction: Expose native error message in errorString qt/qtquick1 5e3bd5cb28e7af95b289a617ca2f7a8892498225..26229cfa0b729313893af5674d604e8692dbb946: > QDeclarativeTextInput: update API to use setBlinkingCursorEnabled qt/qtcharts 023f3b1edeaa9b5f622ddb7781c82ca3468caeff..7bc9c012efbb987790742ee8905965344be55ea7: > Add 5.7.0 changes file qt/qtbase b3fcaea5f2b97d3f562add97aee48cbb469c875a..e64b2234e829cc47872225debcf80d6c06db18f0: > QImage::setPixelColor: warn about invalid colors > QDateTimeParser: adapt unquote() to make good use of QStringRef. > QDateTimeParser: de-duplicate calls and cache results > eglfs: Fix DRM+KMS backends > Add support for -Werror with ICC 17 on Linux > Make it an #error if we failed to detect the ARM architecture version > QEglFSKmsIntegration: use new QJsonObject::value(QLatin1String) > QImageWriter: use new QJsonObject::value(QLatin1String) > QFactoryLoader: use new QJsonObject::value(QLatin1String) > QJsonObject: add some overloads taking QLatin1String > Prospective MSVC 2013 build fix > Fix build on WinRT > QUrl: enable (N)RVO for gcc > QDateTimeParser: proper construction of QString > QWidgetTextControl: ensure we listen for changes to cursorFlashTimeChanged > Fix ANGLE glGetUniform*v functions to work properly with arrays > Doc: Highlight Quick Controls 2 - Gallery example > Be more specific what is in Core and what is not > QNX: Force use of system zlib on Windows host > QJsonValue: don't create a temporary QString on every toString() invocation > Add a QMutex::isRecursive() const noexcept > Work around ICC's bug in making std::atomic a literal type > Mark QThread::currentThreadId() as a pure function > Implement QLibrary::PreventUnloadHint for Windows > Remove includes to qdatetime_p.h that aren't necessary > Mark QTimeZone constructor nothrow. > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > compile fix for static qt with dynamic opengl > Android: Force use of system zlib on Windows host > Add device mkspec for the iMX7 SOC > QUrlQuery: use erase and std::remove_if with QList > iOS: Add text selection support from the platform plugin > iOS: set StyleHint::StartDragTime to 300 > QScoped(Array)Pointer: canonicalize swapping > QtNetwork: eradicate Q_FOREACH loops [rvalues] > Support color font rendering for freetype engine > Fix plugin name for eglfs' GBM backend > Tune fast-exit for signal activation for QML. > Fix MinGW 5.3.0 build of ANGLE > Add Qt::ImInputItemClipRectangle support to widgets > Add QInputMethod::inputItemClipRectangle() > Add ImInputItemClipRectangle > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > QDateTime: use default ctor to create invalid object > QDateTimeParser: enable RVO in format() > Don't bother asking if Linux supports a monotonic clock: it does > Decompress QResources only when needed. > Android: Bring back the useful public vars > QWidgetTextControl: only show cursor when having focus > Android: Fix style extract on Android N > Enable some tests previously disabled due to different results with HB-NG > xcb: support nested paint operations in remote scenarios > qDBusInterfaceFromMetaObject: avoid quadratic complexity. > Change some members of QFontEngineFT::Glyph to short > DBus: use QStringRef to optimize memory allocation > mkspec: Add multiarch include folder to jetson tk1 device spec > Add an early-out to QVector::operator+= and QHash::unite for empty LHS > xcb: eradicate Q_FOREACH loops [needing qAsConst()] > Optimize convert_Indexed8_to_X32 > Improve the script itemization algorithm to match Unicode 8.0 > xcb: eradicate Q_FOREACH loops [const-& returns] > xcb: eradicate Q_FOREACH loops [already const] > Optimize QXcbScreen::visualForFormat() > xcb: don't iterate over .keys() > Avoid processing bezier curves that will be clipped anyway > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > QtNetwork: use const (and const APIs) more > Fix font fallback for an overridden Common script cases > Disallow non-character Unicode codepoints in QUrl/QUrlQuery > xcb: eradicate Q_FOREACH loops [rvalues] > QXcbConnection: add some qAsConst() > QXcbIntegration: simplify a switch > QXcbConnection: mark some more methods const > QPdf: replace a hand-written qWarning with Q_UNIMPLEMENTED > QJsonObject: use reserve() to reduce memory allocations > Disable Directwrite 2 when Directwrite is disabled > iOS: Handle old exclusive build CONFIG names for simulator and device > Windows/Configure tests: Test for DirectWrite2 more extensively. > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > QLockFile: move early out earlier to avoid allocations. > qTopLevelDomain: use QStringRef more > QtGui: mark more types as primitive/movable > Android: eradicate Q_FOREACH loops [rvalues] > Android: Make SDK detection its own qmake feature > Simplify code in QSpdyProtocolHandler::parseHttpHeaders() > QtNetwork: eradicate Q_FOREACH loops [const-& returns] > QtNetwork: eradicate Q_FOREACH loops [needing qAsConst()] > QtNetwork: eradicate Q_FOREACH loops [already const] > winrt: Skip context validation in ANGLE > Update ANGLE to chromium/2651 > QWidgetTextControl: respect run-time changes to cursorFlashTime > Darwin: set SH_BlinkCursorWhenTextSelected to false on Darwin > QWidgetLineControl: respect run-time changes to cursorFlashTime > ConfigureApp: fix warning -Wsign-compare. > OSX: remove tablet->mouse event synth > Android: don't iterate over .keys() > Android: eradicate Q_FOREACH loops [needing qAsConst()] > Android: eradicate Q_FOREACH loops [already const] > QtCore: mark more types as primitive/movable > QMutexPool: avoid QVarLengthArray of QAtomicPointers > iOS: (crash fix) ensure we don't clear focus object in a text responder transition > QtWidgets: Fix qdoc warnings related to inputMethodQuery(). > Moc: use QStringBuilder more > OpenGL: use const (and const APIs) more > xcb: remove tablet->mouse event synth; harmonize handle/report methods > actually enable mocdepend > Mime type browser example: Add documentation. > QtNetwork: replace Java-style iterators > Interpret fixed CSS line-height as minimum rather than absolute qt/qtwayland 15216555593740029f3c25ee16dc4dc248a017b7..c07dc0c5cd138db2f222c6c58bc5778532cecf42: > Postpone QWaylandQuickItem size update after setting output > QML compositors: Adjust for scale factor when positioning subsurfaces > Don't send release events for uncommitted buffers > Move subsurface test application to tests/manual > QtWaylandCompositor: Add support for different EGL buffer formats > QML compositor: Scale surfaces if bufferScale is not set > QML compositor: Adjust for scale factor when handling mouse events > Update the plugins.qmltypes file > Automatically initialize the quick extension objects > Rename the quick extension macros > Compositor API: Add bufferScale property to QWaylandSurface > QWaylandQuickItem: Fix potential null-pointer dereference > Remove left over files > Update the virtual keyboard import > QML API for xdg-shell > Add window manager extension to the pure-qml example > Make window manager extension QML friendly > Add QML api for client side extension. > Move drag icon relative the cursor hotspot position > Fix test build > QML API for subsurfaces > Forward declare Wayland types in public headers. qt/qttools d36d2c3026cae67c119384f47cb2680552c81aaf..570f0f314cbe4603db34d4967b6a7dd35d174eba: > windeployqt: Adapt to new layout of Qt Quick Controls 2. > windeployqt: Adjust to changes in QtWebEngine > Merge remote-tracking branch 'origin/5.6' into 5.7 qt/qtwinextras 6d019d276a4be4e1a20eaf41a16eca64007249f3..8e816f25034287bb3f89317a631075533914102b: > Add changelog for Qt 5.7.0 release qt/qtimageformats 42b07b2ddf443d3eafd18e169f2e5ab5e36604a5..68d9cfe5256c91510552c2b16d5efdb01e77ea57: > Add changes file for 5.7 qt/qtconnectivity f8759f683cfc433c432059e1160d2ab657baaec6..caded2edf69e8a60897653ace1e10b72199c7427: > Merge remote-tracking branch 'origin/5.6' into 5.7 > Do not pin the QML plugins import version. > Remove the traces of the discontinued android-no-sdk platform qt/qtquickcontrols 2ee6ef43d681746d07c1175738184715ce0d84e4..c6713e212ef0b97c45d6466b73220567e94a05f1: > Merge remote-tracking branch 'origin/5.6' into 5.7 > Remove the traces of the discontinued android-no-sdk platform > TextArea: disable selectByMouse on iOS > iOS: Let CursorDelegate respond to cursorFlashTime from style hints > iOS: Remove text selection handling > Add support for QT_QUICK_CONTROLS_1_STYLE qt/qtxmlpatterns fb1dc19bf195c530b7f44d18cc927472b9866a46..9751d3d82eecb4f2c2a805783fbcce9ccd189fea: > tst_XmlPattern:xquerySupport - silence QSsl's debug output qt/qtactiveqt b5440b50f23982e7459a66b46ad41f176f67e308..73ee37bebbf724a3ec01b30212ed31002a682083: > Add changelog for Qt 5.7.0 release qt/qtvirtualkeyboard 9c401c0881bc92491ef128ca9288d5b7c2c7a33c..0c70872a81aab39465606ab37333caf55064482a: > Fix hunspell build for Windows targets > Fix t9write resource library build > Bump version number to 2.1 > Remove 'enterprise' from QML imports and QRC prefixes > Remove non-QML references to "enterprise" or old project structure > Merge remote-tracking branch 'origin/5.6' into 5.7 qt/qtgamepad dee527d22731963096023c298f946ef8cd25a7cc..84b87c222872eb6e49727d773177b7f5b86e9beb: > import missing .gitattributes > Fix compile > Doc: Add basic documentation qt/qtquickcontrols2 e253427f93248983d18055c5020094799a2c6b3b..8b2e819ab2246d01eb564a52aa08bdf1d55c02c2: > QQuickPopup: align position accessors with x/y accessors > Menu: remove the extra margins > Popup: sync content padding with Pane > Material: correct check indicator size > customize.qdoc: Use standalone snippets > ComboBox: restore the old popup behavior > Popup: use margins to determine whether to push inside window bounds > Material: fix SwitchDelegate press color > Menu: support dynamically added items in the same way as static ones > Material: corrected height for delegates > Use a lowercase style name as a built-in file selector > Material: fix flat button colors > Tumbler: calculate proper displacement when count <= visibleItemCount > Material: set correct ToolBar foreground color for built-in primaries > Material: use proper shade for light and dark theme > Popup: make x() and y() return the effective coordinates > Fix overlay stacking order for multiple modal popups > Material: emit paletteChanged() on background color change > Material: fix raised button color for dark theme > Material: mark internal darkerShade() function as static > Gallery: fix main page label text color > Material: remove obsolete imports of QtGraphicalEffects > tests: skip material/BoxShadow.qml and material/ElevationEffect.qml > Fix grammar in style selector documentation > Material: add implicitHeight to MenuItem > Material: Add proper elevation support > Material: made MenuItem not grow above 48 px by default > Allow Menu to grow bigger than implicitHeight of the background > Adding type information for Material and Universal style > Templates: update plugins.qmltypes > QQuickContainer: add missing null check > Fix SwipeDelegate's detailed description > Default style: fix focus visuals for remaining controls > QQuickSwitch: fix the order of checkedChanged() vs. clicked() > Fix accessibility > Improve Tumbler's delegate opacity for all styles > QQuickPopup: listen to parent item's window changes > Fix overlay stacking order > universal: fix moving direction behavior when clicking item > Merge remote-tracking branch 'origin/5.6' into 5.7 > Default style: add correct focus colors for RangeSlider > Popup: emit opened() when fully opened > Revert Tumbler::displacement to position changes > Fix TODO link in qtquickcontrols2-differences.qdoc > Avoid "implicitWidth/Height redefined" warnings > Remove TODO from Chat Tutorial documentation > Remove unnecessary TODO comments > Give Tumbler's text a focus color > Give ToolButton's text a focus color > Material: add top and bottom paddings for Menu > ComboBox: separate indicator > Align header guards: all uppercase & match with the file name > Merge remote-tracking branch 'origin/5.6' into 5.7 > Tumbler: normalize position to [-1.0..1.0] > Tumbler: rename displacement to position > Move highlighted to subclasses that actually use it > Material: fix CheckIndicator focus again > Doc: Disambiguate \l targets by providing additional parameters > Replace activeKeyFocus => visualFocus in 'Creating a Custom Style' doc > Q_QUICKTEMPLATES2_EXPORT => Q_QUICKTEMPLATES2_PRIVATE_EXPORT > Popup: separate modal and modeless background dimming > Doc: remove the calendar import from "Qt Quick Controls 2 QML Types" > Doc: re-organize and cleanup the index page > Doc: link to "Customizing Qt Quick Controls 2" from the index page > Doc: fix qdoc warnings in "Customizing Qt Quick Controls 2" > Introduce Page::title > Document how to create custom styles > Material: Set default height for one-line item delegates > Fix SwipeDelegate spacing to match other delegates > Control: rename activeKeyFocus to visualFocus > Allow attaching TextArea to a Flickable > Optimize QQuickStyleSelector > Material: revise ComboBox looks > Hide SwipeDelegate text when removing > Doc: fix base type of MenuItem > Remove "strong" focus policy from menu items created by ComboBox > Use ToolTip font from theme > Fix Q_INIT_RESOURCE() for static builds > Doc: add missing ToolButton screenshot > Material: fix CheckIndicator focus > Improve Drawer docs > ToolTip: enable font inheritance > Doc: add missing Tumbler attached properties > QQuickStyleSelector: fix relative path handling > Promote QQuickToolTip's repositioning code to QQuickPopup > QQuickStyleSelector: re-use QFileSelectorPrivate::platformSelectors() > Register the latest revisions of all template/control base classes > Doc: add "Popup Controls" group page > QQuickStyle: fix style name lookup on OSX > Make 'Usage' section of styles.qdoc easier to link to > Doc: Add \target to avoid incorrect links > Set "strong" focus policy for buttons and sliders > Move autoRepeat out of QQuickAbstractButton > Universal: notify foreground and background changes on theme change > Implement case-insensitive style name lookup > Fix .impl imports > Be consistent with spacing between sections > Move individual customization docs into a top-level "reference" section > Rename the style plugins > Rename env vars (QT_LABS_CONTROLS_XXX -> QT_QUICK_CONTROLS_XXX) > Fix Q_INIT_RESOURCE for Material & Universal style plugins > Update plugins.qmltypes > Update QQuickDialRing license headers > Fix controls/qmldir depends > Doc: cleanup remaining "labs" references > Update qtquickcontrols2.metainfo > Doc: rename Qt.labs.controls 1.0 to QtQuick.Controls 2.0 > Fix SwipeDelegate to inherit ItemDelegate > Update ItemDelegate snippet images > Move resources to :/qt-project.org/imports/QtQuick/Controls.2 > tst_styles: fix style name casing > import Qt.labs.controls 1.0 => QtQuick.Controls 2.0 > QQuickStyleSelector: don't force lowercase style name > Replace activeFocus with activeKeyFocus > Doc: rename Qt.labs.templates 1.0 to QtQuick.Templates 2.0 > import Qt.labs.templates 1.0 => QtQuick.Templates 2.0 > Add Drawer::dragMargin > Fix QQuickDrawerPrivate::positionAt() > Fix tst_popup with transitions (Material) > Tests: prepare for the upcoming import rename - part II > Update .gitignore > Fix 'Undocumented parameter 'style'' warning in QQuickStyle docs > Fix rendering of squished default Dial > Dial: make wrap default to false > Add GIFs for Dial > Improve default Dial's painting > Fix-up the use of QQuickAbstractButton::down in delegates > Chat Tutorial: update the install path > Rename qtquickcontrols.conf to qtquickcontrols2.conf > Default: use QQuickColorImageProvider > Material: rename internal constants for divider color > Popup: rename close policy flags > Merge "Merge remote-tracking branch 'origin/5.6' into 5.7" into refs/staging/5.7 > Tests: cleanup templates imports > Tests: prepare for the upcoming import rename > Popup: add opened() and closed() signals. > Material: increase size and paddings for SpinBox > Update Default style Dial to match new design specs > Add focus visuals to default ItemDelegate > tst_button: fix warnings in test_checkable > Merge QQuickPluginUtils to QQuickStylePlugin > Doc: rename remaining qtlabscontrols groups and links > Update Default style ComboBox to match new design specs qt/qtrepotools 0b1dba7456f0e2cebf0d270bbaa4b04b4883c46e..be3d47ae9560950de0908f0129703e9f7a8d68cd: > Obtain sha1s from supermodule instead of using branch tips Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From nolden at kde.org Wed May 18 07:21:43 2016 From: nolden at kde.org (Ralf Nolden) Date: Wed, 18 May 2016 07:21:43 +0200 Subject: [Development] FreeBSD / Clang / Raspberry Pi In-Reply-To: <1FC83DB6-54E4-410D-A533-73E8768D9F73@sylvaingarrigues.com> References: <1FC83DB6-54E4-410D-A533-73E8768D9F73@sylvaingarrigues.com> Message-ID: <3444973.UxJvRRmF7e@w530.nolden.freebsd> Hi Sylvain, You may want to get in contact with Oleksandr who has also done a porting: http://kernelnomicon.org/?p=598 Olelksandr is in the process of merging his additions to the dev branch while I'm doing the ports integration in the meanwhile by using patches to the freebsd ports at https://freebsd.kde.org/ and merging our ports patches to Qt. You may want to join us on #kde-freebsd so we can find the solution that we end up without any patches in ports. >From the qt perspective things like the pi are devices so for consistency that should land in the devices section (I think Oleksandr has done it that way, you may compare your patch with his one on his website). For any side effects, we should discuss whatever is the best solution here. One thing that should work out of the box is using qtcreator. Am Dienstag, 17. Mai 2016, 22:50:59 schrieb Sylvain Garrigues: > Hello, > > I have ported Qt 5.6 to FreeBSD / Raspberry Pi and would like to share my > config. I have a question though. > > I have created a « device » mkspec (mkspecs/device/freebsd-rasp-pi-clang/ to > follow the scheme) and I am using it with '-platform freebsd-clang -device > freebsd-rasp-pi-clang’ but technically *I am not cross-compiling* as either > the port is built on the Pi or it will later be on the FreeBSD packages > building infrastructures which runs QEMU arm simulators which emulate a > complete arm system (filesystem, kernel, etc). Therefore it’s always an arm > compiler producing arm binaries on a freebsd system - no cross compiling. > > So should I just create a mkspecs/freebsd-clang-rasp-pi/ in the top mkspecs > folder and just use -platform freebsd-clang-rasp-pi? (no -device option) > > I can see that using a device is triggering a cross_compile qmake feature > with configure, and it has side effects (e.g. no stripping) - hence the > question. > > Happy to hear your thoughts. > > Sylvain. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Kind regards, Ralf Nolden From sylvain at sylvaingarrigues.com Wed May 18 09:04:42 2016 From: sylvain at sylvaingarrigues.com (Sylvain Garrigues) Date: Wed, 18 May 2016 09:04:42 +0200 Subject: [Development] FreeBSD / Clang / Raspberry Pi In-Reply-To: <3444973.UxJvRRmF7e@w530.nolden.freebsd> References: <1FC83DB6-54E4-410D-A533-73E8768D9F73@sylvaingarrigues.com> <3444973.UxJvRRmF7e@w530.nolden.freebsd> Message-ID: Sure I will share with Oleksandr, my work is based on what he has already done anyway, just couldn’t wait to try to port other modules on my Pi :-) I dug into the build process and noticed what I explained about the -device and the detection of the cross_compile feature, but anyway I let you discuss the side effects later. Will join you on #kde-freebsd. Have a good day > Le 18 mai 2016 à 07:21, Ralf Nolden a écrit : > > Hi Sylvain, > > You may want to get in contact with Oleksandr who has also done a porting: > http://kernelnomicon.org/?p=598 > > Olelksandr is in the process of merging his additions to the dev branch while > I'm doing the ports integration in the meanwhile by using patches to the > freebsd ports at https://freebsd.kde.org/ and merging our ports patches to Qt. > > You may want to join us on #kde-freebsd so we can find the solution that we end > up without any patches in ports. > > From the qt perspective things like the pi are devices so for consistency that > should land in the devices section (I think Oleksandr has done it that way, > you may compare your patch with his one on his website). For any side effects, > we should discuss whatever is the best solution here. > > One thing that should work out of the box is using qtcreator. > > Am Dienstag, 17. Mai 2016, 22:50:59 schrieb Sylvain Garrigues: >> Hello, >> >> I have ported Qt 5.6 to FreeBSD / Raspberry Pi and would like to share my >> config. I have a question though. >> >> I have created a « device » mkspec (mkspecs/device/freebsd-rasp-pi-clang/ to >> follow the scheme) and I am using it with '-platform freebsd-clang -device >> freebsd-rasp-pi-clang’ but technically *I am not cross-compiling* as either >> the port is built on the Pi or it will later be on the FreeBSD packages >> building infrastructures which runs QEMU arm simulators which emulate a >> complete arm system (filesystem, kernel, etc). Therefore it’s always an arm >> compiler producing arm binaries on a freebsd system - no cross compiling. >> >> So should I just create a mkspecs/freebsd-clang-rasp-pi/ in the top mkspecs >> folder and just use -platform freebsd-clang-rasp-pi? (no -device option) >> >> I can see that using a device is triggering a cross_compile qmake feature >> with configure, and it has side effects (e.g. no stripping) - hence the >> question. >> >> Happy to hear your thoughts. >> >> Sylvain. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Kind regards, > > Ralf Nolden > From jedrzej.nowacki at qt.io Wed May 18 09:42:41 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 18 May 2016 09:42:41 +0200 Subject: [Development] =?utf-8?q?dev_CI_integration_stuck_for_3=C2=BD_days?= In-Reply-To: <20160517104917.GG24382@troll08.it.local> References: <9093003.uVVIQWAqJl@tjmaciei-mobl4> <20160517104917.GG24382@troll08.it.local> Message-ID: <2033678.fE4STqBH2z@42> Yes and I fixed them all on Friday with a "catch all" command. I have no clue how just one integration could stay locked. Cheers, Jędrek On Tuesday 17 of May 2016 12:49:17 Oswald Buddenhagen wrote: > On Tue, May 17, 2016 at 06:08:50AM +0000, Simon Hausmann wrote: > > I just looked into it and it looks like an inconsistency in the gerrit > > database. The latest builds branch points to a set of changes that are in > > staged state, while the change that is in integrating change is not in > > that branch. I've found the build branch that had the integrating change > > and rejected the change (and staged it again). > yes, fregl (or nierob?) diagnosed that there was a network outage during > the time the CI was supposed to report the result to gerrit, and the > system apparently has no queue/retry mechanism for this. so it's out of > sync now. > Somebody (TM) needs to (re-)execute the relevant commands by hand ... > > > It appears that the change was staged Friday morning and nobody noticed it > > during Friday. Then came a long weekend, with Monday off and Tuesday also > > off in Norway. > > > > Simon > > ________________________________________ > > From: Development > > on behalf of > > Thiago Macieira Sent: Monday, May 16, 2016 > > 10:42:32 PM > > To: development at qt-project.org > > Subject: [Development] dev CI integration stuck for 3½ days > > > > Will someone PLEASE look into the qtbase/dev integration? > > > > https://codereview.qt-project.org/156523 has been integrating for (at the > > time of writing this email) 84 and a half hours -- 3.5 days -- and that's > > including two full working days in Finland, one in Germany and Norway as > > today is is a bank holiday in those countries. I believe we'll break the > > record by the time someone gets around to fixing this, if we haven't yet. > > > > Let's not hope we have to wait until after tomorrow's holiday in Norway > > for it to get back to working. > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From bogdan.vatra at kdab.com Wed May 18 10:01:09 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Wed, 18 May 2016 11:01:09 +0300 Subject: [Development] Qt + GCC 6 no joy ? Message-ID: <1643034.I8z68kZl0M@zmeu> Hi, Did anyone tried Qt (5.7) with GCC 6 ? I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4 when I start QtCreator :(. It's a know issue or just me? Cheers, BogDan. From cavendish.qi at gmail.com Wed May 18 10:08:31 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 18 May 2016 10:08:31 +0200 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: <1643034.I8z68kZl0M@zmeu> References: <1643034.I8z68kZl0M@zmeu> Message-ID: https://bugreports.qt.io/browse/QTBUG-53373 ? On 18 May 2016 at 10:01, Bogdan Vatra wrote: > Hi, > > Did anyone tried Qt (5.7) with GCC 6 ? > I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4 > when I > start QtCreator :(. It's a know issue or just me? > > Cheers, > BogDan. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Wed May 18 10:08:46 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 18 May 2016 08:08:46 +0000 Subject: [Development] =?windows-1257?q?dev_CI_integration_stuck_for_3=BD_?= =?windows-1257?q?days?= In-Reply-To: <2033678.fE4STqBH2z@42> References: <9093003.uVVIQWAqJl@tjmaciei-mobl4> <20160517104917.GG24382@troll08.it.local>,<2033678.fE4STqBH2z@42> Message-ID: The best theory I can come up with at this point looks like this: Once there was a "newer" staging branch that contained changes that were still in 'STAGED' state but another change was in 'INTEGRATING' (which was in the _previous_ staging branch), the conditions for an endless "loop" were met, I think. Upon any of the CI restarts, the CI thought it would "resume" the integration of the one change that was in 'INTEGRATING' state and picked up from the latest staging branch, which had the other (two or three) changes that were still in 'STAGED' state. When the build finished (pass or fail), the staging-approve command must have failed. It failed for me when I tried to manually "reject" the changes - that's when I realized the discrepancy. However the change that was in 'INTEGRATING' state remained, because the staging branch that we tried to approve/reject did not contain that change, so nothing changed there. As the state of the 'INTEGRATING' and 'STAGED' changes didn't change, the CI didn't pick up any new integrations or try to create new staging branches. How it is possible that a new staging branch was created while another change remained in 'INTEGRATING' state is a mystery to me. Perhaps something happened in Gerrit at that moment? Perhaps there's a bug in the CI that allows for creating this "impossible" state? Simon ________________________________________ From: Development on behalf of Jędrzej Nowacki Sent: Wednesday, May 18, 2016 9:42:41 AM To: development at qt-project.org Subject: Re: [Development] dev CI integration stuck for 3½ days Yes and I fixed them all on Friday with a "catch all" command. I have no clue how just one integration could stay locked. Cheers, Jędrek On Tuesday 17 of May 2016 12:49:17 Oswald Buddenhagen wrote: > On Tue, May 17, 2016 at 06:08:50AM +0000, Simon Hausmann wrote: > > I just looked into it and it looks like an inconsistency in the gerrit > > database. The latest builds branch points to a set of changes that are in > > staged state, while the change that is in integrating change is not in > > that branch. I've found the build branch that had the integrating change > > and rejected the change (and staged it again). > yes, fregl (or nierob?) diagnosed that there was a network outage during > the time the CI was supposed to report the result to gerrit, and the > system apparently has no queue/retry mechanism for this. so it's out of > sync now. > Somebody (TM) needs to (re-)execute the relevant commands by hand ... > > > It appears that the change was staged Friday morning and nobody noticed it > > during Friday. Then came a long weekend, with Monday off and Tuesday also > > off in Norway. > > > > Simon > > ________________________________________ > > From: Development > > on behalf of > > Thiago Macieira Sent: Monday, May 16, 2016 > > 10:42:32 PM > > To: development at qt-project.org > > Subject: [Development] dev CI integration stuck for 3½ days > > > > Will someone PLEASE look into the qtbase/dev integration? > > > > https://codereview.qt-project.org/156523 has been integrating for (at the > > time of writing this email) 84 and a half hours -- 3.5 days -- and that's > > including two full working days in Finland, one in Germany and Norway as > > today is is a bank holiday in those countries. I believe we'll break the > > record by the time someone gets around to fixing this, if we haven't yet. > > > > Let's not hope we have to wait until after tomorrow's holiday in Norway > > for it to get back to working. > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From bogdan.vatra at kdab.com Wed May 18 10:12:44 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Wed, 18 May 2016 11:12:44 +0300 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: References: <1643034.I8z68kZl0M@zmeu> Message-ID: <4897120.ZZHq9xvope@zmeu> Yep, looks very "familiar"! On Wednesday 18 May 2016 10:08:31 Liang Qi wrote: > https://bugreports.qt.io/browse/QTBUG-53373 ? > > On 18 May 2016 at 10:01, Bogdan Vatra wrote: > > Hi, > > > > Did anyone tried Qt (5.7) with GCC 6 ? > > I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4 > > when I > > start QtCreator :(. It's a know issue or just me? > > > > Cheers, > > BogDan. > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From filippocucchetto at gmail.com Wed May 18 12:21:54 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Wed, 18 May 2016 12:21:54 +0200 Subject: [Development] ListView and spaces QTBUG-46488 Message-ID: Hello everyone, i would like to warn about this serious bug in QDeclarative that could hit users of ListViews with QAIM https://bugreports.qt.io/browse/QTBUG-46488 I know that Gabriel gave it a look some time ago but he seems to be quite busy right now. I also gave it a look on my own but a quick fix is a no go. Furthermore some knownledge of the internals of QtDeclarative are needed. -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From nolden at kde.org Wed May 18 13:04:54 2016 From: nolden at kde.org (Ralf Nolden) Date: Wed, 18 May 2016 13:04:54 +0200 Subject: [Development] New Qt 5.7.0 RC snapshot available In-Reply-To: References: Message-ID: <11997800.8p2vFT3UM1@w530.nolden.freebsd> Am Mittwoch, 18. Mai 2016, 04:44:45 schrieb Jani Heikkinen: Hi, thanks for the snapshot that allows us some build tests before any releases. I just hit a compile error on the deprecated qtquick1 module, latest src tarball is for 5.5.1. For qtwebkit, there's the community releases subdir: http://download.qt.io/community_releases/5.6/5.6.0/ (which does work) I suggest having a look at https://bugreports.qt.io/browse/QTBUG-49883 and do some consideration how to handle those issues. If modules are deprecated but should still work for backwards compatibility, then there should be no change at all that prevents that. Otherwise that module is "somewhat supported even if we don't like to" - which creates a really confusing situation for packagers and porters, but (at least I) can live with that as long as we get updated (tagged) release tarballs :) So, an updated tarball for qtquick1 for 5.6 would be really much appreciated (so that it works with 5.6.x and 5.7.x) Thanks :) > Hi all, > > > New Qt 5.7.0 RC snapshot available > > > Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/456/ > > Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/424/ > > Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/354/ > > src: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/latest_src/submodules/ > > /> > > -- Kind regards, Ralf Nolden From stephen.kelly at ableton.com Wed May 18 13:38:57 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Wed, 18 May 2016 13:38:57 +0200 Subject: [Development] ListView and spaces QTBUG-46488 In-Reply-To: References: Message-ID: This can also be reproduced with ListView instead of TreeView: https://bugreports.qt.io/browse/QTBUG-53263 Thanks, Stephen On 18/05/16 12:21, Filippo Cucchetto wrote: > Hello everyone, > i would like to warn about this serious bug in QDeclarative that could hit > users of ListViews with QAIM > https://bugreports.qt.io/browse/QTBUG-46488 > I know that Gabriel gave it a look some time ago but he seems to be quite > busy right now. I also gave it a look on my own but a quick fix is a > no go. Furthermore > some knownledge of the internals of QtDeclarative are needed. > > -- > Filippo Cucchetto > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed May 18 13:45:05 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 18 May 2016 13:45:05 +0200 Subject: [Development] QtCon Call for Papers extended Message-ID: <2263931.rYIyk2Z3Aq@oscar> Hi, The deadline for the QtCon call for paper was extended to the 22nd of May. https://qtcon.org/cfp ----------- This is a Call for Papers to a unique event. KDE Akademy, Qt Contributors' Summit, FSFE Summit, KDAB and VideoLAN Dev Days have come together to create QtCon 2016, Sept 1 - 4, 2016, to be held in Berlin, Germany. On Sept 1 there will be a day of Training from KDAB. The conference runs from Sept 2 - 4. There will be talks, workshops, Birds of a Feather sessions (BoFs) and meetings, contributed to by everyone, as well as the traditional social events. KDE Akademy will then continue with BoFs from Monday 5th to Thursday 8th elsewhere in Berlin. The conference will be at the bcc, in Berlin, which has the flexibility to run a diverse program of events so participants can attend presentations and meetings with a great variety of focus and interest. If you are a Qt user, you'll get the top quality talks you'd expect from a Qt conference, as well as presentations and meetings across each of the participating communities. If you normally attend the VideoLAN annual event, you will have access to everything you usually expect from that, as well as the opportunity to learn what’s new from Qt contributors, KDE and FSFE, and so on. Attendees who are not members of any of these communities are also welcome to join this unique, one-off event and take their pick from the unusually wide range of material. What we are looking for This brings a difference to the Call for Papers you might be familiar with. The reason is that we want presentations, workshop and BoFs that cater for one or more of the whole communities of KDE, Qt, VideoLAN, FSFE and the wider Free software community. The program aims to present a unified event. We are asking for talk proposals on topics relevant to this including: - Collaboration between KDE, the Qt Project and other projects that use KDE or Qt - Design and Usability - Free software in action: use cases of technology in real life; be it mobile, desktop deployments and so on. - Going multi-platform all the way: from design to distribution - Improving our soft skills and processes - Increasing our reach through efforts such as accessibility, promotion, translation and localization - Insights about C++ and QML - Learning what is new and exciting in Qt - Open Standards - Overview of what is going on in the various areas of each of the communities - Presentation of new applications; new features and functions in existing applications - Quality and testing of applications - Using KDE Frameworks 5 for Qt developers - Writing custom Qt Quick components using OpenGL Don't let this list restrict your ideas though. You can submit a proposal even if it doesn't fit the list of topics as long as it is relevant Proposal guidelines Provide the following information on the proposal form: - Title—the title of your session/presentation - Abstract—a brief summary of your presentation Description—information about your topic and its potential benefits for the audience - A short bio—including anything that qualifies you to speak on your subject - Tags—add appropriate tags to your proposal to help the committee sort through the categories of proposals We encourage you to rehearse your presentation well. If you don't have someone to test your talk on or would like help practising your presentation, you can ask the Program Committee Proposals must be submitted by May 22nd, 23:59:59 CEST. QtCon will attract people from all over the world. For this reason, all talks are in English. Please don't let this requirement stop you. Your ideas and commitment are what your audience will want to know about. - Lightning talks are 10 minutes long - Other talks are 30 or 60 minutes - Workshops, BoFs and meetings can be between 1 and 2 hours (Proposals for KDE after the weekend will be collected separately) Workshops and talks include time for Q&A. Lightning talks do not have Q&A. QtCon has a tight schedule, so beginning and ending times are enforced. If your presentation must be longer than the standard time, please provide reasons why this is so. For lightning talks, we will be collecting all of the presentations the day before the lightning track. All of the presentations will be set-up and ready to go at the start of the lightning track. QtCon is upbeat, but it is not frivolous. Help us see that you care about your topic, your presentation and your audience. Typos, sloppy or all-lowercase formatting and similar appearance oversights leave a bad impression and may count against your proposal. There's no need to overdo it. If it takes more than two paragraphs to get to the point of your topic, it's too much and should be slimmed down. The quicker you can make a good impression, the better. We are looking for originality. Having the same people talking about the same things doesn't accomplish that goal. Thus, we favor original and novel content. If you have presented on a topic elsewhere, please add a new twist, new research, or recent development, something unique. Of course, if your talk is plain awesome as is, go for that. Everyone submitting a proposal will be notified mid June, as to whether or not their proposal was accepted for the QtCon Program. Talks will be recorded and published on the Internet for free, along with a copy of the slide deck, live demo or anything else associated with the presentations. This benefits the larger Community and those who can't make it to QtCon. You will retain full ownership of your slides and other materials, we request that you make your materials available explicitly under the CC-BY license. If you have any questions please contact the Program Committee qtcon-talks at qtcon.org If you are interested, you can access our talk submission system by clicking here. https://conf.qtcon.org/en/qtcon/cfp/person From oswald.buddenhagen at qt.io Wed May 18 13:52:05 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 18 May 2016 13:52:05 +0200 Subject: [Development] =?iso-8859-1?q?dev_CI_integration_stuck_for_3=BD_da?= =?iso-8859-1?q?ys?= In-Reply-To: References: <9093003.uVVIQWAqJl@tjmaciei-mobl4> <20160517104917.GG24382@troll08.it.local> <2033678.fE4STqBH2z@42> Message-ID: <20160518115205.GD30560@troll08.it.local> On Wed, May 18, 2016 at 08:08:46AM +0000, Simon Hausmann wrote: > How it is possible that a new staging branch was created while another > change remained in 'INTEGRATING' state is a mystery to me. Perhaps > something happened in Gerrit at that moment? Perhaps there's a bug in > the CI that allows for creating this "impossible" state? > well, something weird definitely *did* happen with gerrit around that time, as it's also when it started dropping notification mails. whether/how that is related is unknown to me. generally, i wouldn't trust that the staging-related commands do all necessary sanity checks to prevent an amok-running CI from creating a bogus state. this should be thoroughly re-examined next time we forward-port the feature. From filippocucchetto at gmail.com Wed May 18 14:15:45 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Wed, 18 May 2016 14:15:45 +0200 Subject: [Development] ListView and spaces QTBUG-46488 In-Reply-To: References: Message-ID: Maybe they're two different issues because in https://bugreports.qt.io/browse/QTBUG-46488 it doesn't seem to be related to the number of items shown. But anyway these are really important bugs for those who use ListView+QAIM 2016-05-18 13:38 GMT+02:00 Stephen Kelly via Development < development at qt-project.org>: > > This can also be reproduced with ListView instead of TreeView: > > https://bugreports.qt.io/browse/QTBUG-53263 > > Thanks, > > Stephen > > > On 18/05/16 12:21, Filippo Cucchetto wrote: > > Hello everyone, > i would like to warn about this serious bug in QDeclarative that could hit > users of ListViews with QAIM > https://bugreports.qt.io/browse/QTBUG-46488 > I know that Gabriel gave it a look some time ago but he seems to be quite > busy right now. I also gave it a look on my own but a quick fix is a no > go. Furthermore > some knownledge of the internals of QtDeclarative are needed. > > -- > Filippo Cucchetto > > > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development > > > -- > Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany > Management Board: Gerhard Behles, Jan Bohl > Chair of the Supervisory Board: Uwe Struck > Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Wed May 18 17:04:24 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 18 May 2016 15:04:24 +0000 Subject: [Development] New Qt 5.7.0 RC snapshot available In-Reply-To: <11997800.8p2vFT3UM1@w530.nolden.freebsd> References: <11997800.8p2vFT3UM1@w530.nolden.freebsd> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Ralf Nolden > [...] > I suggest having a look at https://bugreports.qt.io/browse/QTBUG-49883 > and do some consideration how to handle those issues. If modules are > deprecated but should still work for backwards compatibility, then there > should be no change at all that prevents that. There's a difference between deprecated and unsupported. Deprecated means we don't advice you to start _new_ projects with it, Otherwise it has the same promises as any other module. Unsupported means it's not part of Qt anymore. > Otherwise that module is > "somewhat supported even if we don't like to" - which creates a really > confusing situation for packagers and porters, but (at least I) can live with > that as long as we get updated (tagged) release tarballs :) QtQuick1 and QtWebKit are _not_ supported anymore since Qt 5.6. What we have said is that we will provide QtWebKit source packages as courtesy on a best-effort basis. That is, also the QtWebKit source package under http://download.qt.io/community_releases/5.6/5.6.0/ is not part of Qt anymore, and not supported. Use it at your own risk. There's also no promise we can continue providing these. > So, an updated tarball for qtquick1 for 5.6 would be really much appreciated > (so that it works with 5.6.x and 5.7.x) It's the first time I hear someone asking for a tarball for QtQuick1. I see that people are still stuck with WebKit for some use cases, because the architecture, OS requirements and API of WebEngine differs. For QtQuick, it's IMO really painless to update. Also, last time I checked, there were very little Linux packages left that still require Qt Quick 1. So what's your use case? Regards Kai From nolden at kde.org Wed May 18 17:15:58 2016 From: nolden at kde.org (Ralf Nolden) Date: Wed, 18 May 2016 17:15:58 +0200 Subject: [Development] New Qt 5.7.0 RC snapshot available In-Reply-To: References: <11997800.8p2vFT3UM1@w530.nolden.freebsd> Message-ID: <7704405.rEP8PHZXCX@w530.nolden.freebsd> Am Mittwoch, 18. Mai 2016, 15:04:24 schrieb Kai Koehne: > It's the first time I hear someone asking for a tarball for QtQuick1. > > I see that people are still stuck with WebKit for some use cases, because > the architecture, OS requirements and API of WebEngine differs. For > QtQuick, it's IMO really painless to update. Also, last time I checked, > there were very little Linux packages left that still require Qt Quick 1. > So what's your use case? https://www.freshports.org/x11-toolkits/qt5-declarative/ (qt5-declarative is a misleading name for qtquick1 as the qt4 version was named declarative, however it is the qtquick1 sources packaged). We will have to check if those ports that depend on qtquick1 do really need them (where qt5 (metaport) and qtcreator can go obviously anyway) or if we can find another solution. > > Regards > > Kai > -- Kind regards, Ralf Nolden From laszlo.agocs at qt.io Wed May 18 22:36:21 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Wed, 18 May 2016 20:36:21 +0000 Subject: [Development] FreeBSD / Clang / Raspberry Pi In-Reply-To: <1FC83DB6-54E4-410D-A533-73E8768D9F73@sylvaingarrigues.com> References: <1FC83DB6-54E4-410D-A533-73E8768D9F73@sylvaingarrigues.com> Message-ID: Hello, The device specs indeed assume cross-compiling (after all it's just a shorthand for -xplatform plus some common stuff to avoid duplication in the specs for each device) but note how for instance the linux-nuc-g++ device spec is used to build for an Intel device on an Intel host using an Intel compiler and sysroot. The architecture being the same all the way is not interesting, what matters is that there is a separate compiler and sysroot. Therefore this won't be suitable in your case. Introducing freebsd-clang-rasp-pi as a plain makespec works but does not sound very appealing as it is step back to the structure of device-specific makespecs from pre-Qt5 times. One alternative, out of my head, would be to add the support next to freebsd-clang and use -device-option with some custom, freebsd-clang-specific variable to trigger the RPi/ARM specifics - by doing a conditional include() for the RPi-specific snippet (or whatever device was specified, hence this would work just fine once you need to add FreeBSD support for some other device as well). Or something along these lines. Best regards, Laszlo ________________________________________ From: Development on behalf of Sylvain Garrigues Sent: Tuesday, May 17, 2016 10:50 PM To: development at qt-project.org Subject: [Development] FreeBSD / Clang / Raspberry Pi Hello, I have ported Qt 5.6 to FreeBSD / Raspberry Pi and would like to share my config. I have a question though. I have created a « device » mkspec (mkspecs/device/freebsd-rasp-pi-clang/ to follow the scheme) and I am using it with '-platform freebsd-clang -device freebsd-rasp-pi-clang’ but technically *I am not cross-compiling* as either the port is built on the Pi or it will later be on the FreeBSD packages building infrastructures which runs QEMU arm simulators which emulate a complete arm system (filesystem, kernel, etc). Therefore it’s always an arm compiler producing arm binaries on a freebsd system - no cross compiling. So should I just create a mkspecs/freebsd-clang-rasp-pi/ in the top mkspecs folder and just use -platform freebsd-clang-rasp-pi? (no -device option) I can see that using a device is triggering a cross_compile qmake feature with configure, and it has side effects (e.g. no stripping) - hence the question. Happy to hear your thoughts. Sylvain. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From stephen.kelly at ableton.com Thu May 19 12:22:35 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Thu, 19 May 2016 12:22:35 +0200 Subject: [Development] ListView and spaces QTBUG-46488 In-Reply-To: References: Message-ID: <757a1671-506f-43d2-8449-d33d97e1c212@ableton.com> You're right, as discussed on IRC, the bugs are different. QTBUG-53263 is a regression in Qt 5.6, and QTBUG-46488 is much older than that. Sorry for the noise! On 18/05/16 14:15, Filippo Cucchetto wrote: > Maybe they're two different issues because in > https://bugreports.qt.io/browse/QTBUG-46488 > it doesn't seem to be related to the number of items shown. > But anyway these are really important bugs for those who use ListView+QAIM > > 2016-05-18 13:38 GMT+02:00 Stephen Kelly via Development > >: > > > This can also be reproduced with ListView instead of TreeView: > > https://bugreports.qt.io/browse/QTBUG-53263 > > > Thanks, > > Stephen > > > On 18/05/16 12:21, Filippo Cucchetto wrote: >> Hello everyone, >> i would like to warn about this serious bug in QDeclarative that >> could hit >> users of ListViews with QAIM >> https://bugreports.qt.io/browse/QTBUG-46488 >> I know that Gabriel gave it a look some time ago but he seems to >> be quite >> busy right now. I also gave it a look on my own but a quick fix >> is a no go. Furthermore >> some knownledge of the internals of QtDeclarative are needed. >> >> -- >> Filippo Cucchetto >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany > Management Board: Gerhard Behles, Jan Bohl > Chair of the Supervisory Board: Uwe Struck > Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > Filippo Cucchetto -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu May 19 17:59:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 19 May 2016 08:59:16 -0700 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: <1643034.I8z68kZl0M@zmeu> References: <1643034.I8z68kZl0M@zmeu> Message-ID: <1964494.0GIq51CFau@tjmaciei-mobl1> On quarta-feira, 18 de maio de 2016 11:01:09 PDT Bogdan Vatra wrote: > Hi, > > Did anyone tried Qt (5.7) with GCC 6 ? > I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4 when > I start QtCreator :(. It's a know issue or just me? I can confirm it too. And it only happens in release mode. And I can also confirm the problem does not happen when compiling with GCC 5.3.1. Backtrace with debugging symbols, but in release mode, is attached. I'll try to study the generated code to see if I spot anything. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- #0 0x00007ffff58b0faa in QV4::ExecutionEngine::newArrayObject(int) (v=..., this=) at /home/tjmaciei/obj/qt/qt5-release/qtbase/include/QtQml/5.7.0/QtQml/private/../../../../../../../../../src/qt/qt5/qtdeclarative/src/qml/jsruntime/qv4value_p.h:408 #1 0x00007ffff58b0faa in QV4::ExecutionEngine::newArrayObject(int) (this=) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/jsruntime/qv4object_p.h:389 #2 0x00007ffff58b0faa in QV4::ExecutionEngine::newArrayObject(int) (this=) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/jsruntime/qv4object_p.h:386 #3 0x00007ffff58b0faa in QV4::ExecutionEngine::newArrayObject(int) (this=) at /home/tjmaciei/obj/qt/qt5-release/qtbase/include/QtQml/5.7.0/QtQml/private/../../../../../../../../../src/qt/qt5/qtdeclarative/src/qml/memory/qv4mm_p.h:211 #4 0x00007ffff58b0faa in QV4::ExecutionEngine::newArrayObject(int) (this=0x1ee2990, count=3) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/jsruntime/qv4engine.cpp:618 #5 0x00007ffff5a08df6 in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*) (this=this at entry=0x7fffffffa790, subComponentIndex=subComponentIndex at entry=-1, parent=parent at entry=0x0, interrupt=interrupt at entry=0x0) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:192 #6 0x00007ffff5a0877e in QQmlObjectCreator::createInstance(int, QObject*, bool) (this=this at entry=0x7fffffffa9e0, index=index at entry=0, parent=parent at entry=0x0, isContextObject=isContextObject at entry=true) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1084 #7 0x00007ffff5a08c2f in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*) (this=this at entry=0x7fffffffa9e0, subComponentIndex=subComponentIndex at entry=-1, parent=parent at entry=0x0, interrupt=interrupt at entry=0x0) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:203 #8 0x00007ffff5a0877e in QQmlObjectCreator::createInstance(int, QObject*, bool) (this=this at entry=0x7fffffffbd60, index=19, parent=0x1f56d80, isContextObject=isContextObject at entry=false) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1084 #9 0x00007ffff5a0a619 in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*) (this=this at entry=0x7fffffffbd60, property=0x7fffc4041528, binding=binding at entry=0x7fffc41ecce0) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:749 #10 0x00007ffff5a0a864 in QQmlObjectCreator::setupBindings(QBitArray const&) (this=this at entry=0x7fffffffbd60, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:701 #11 0x00007ffff5a0b34b in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*, QBitArray const&) (this=this at entry=0x7fffffffbd60, index=7, index at entry=9, instance=0x1f56520, instance at entry=0x1f56d80, bindingTarget=0x1f56520, bindingTarget at entry=0x1f56d80, valueTypeProperty=valueTypeProperty at entry=0x0, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1328 #12 0x00007ffff5a083ef in QQmlObjectCreator::createInstance(int, QObject*, bool) (this=this at entry=0x7fffffffbd60, index=, parent=, isContextObject=isContextObject at entry=false) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1175 #13 0x00007ffff5a0a619 in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*) (this=this at entry=0x7fffffffbd60, property=0x7fffc4041528, binding=binding at entry=0x7fffc41eca6c) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:749 #14 0x00007ffff5a0a864 in QQmlObjectCreator::setupBindings(QBitArray const&) (this=this at entry=0x7fffffffbd60, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:701 #15 0x00007ffff5a0b34b in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*, QBitArray const&) (this=this at entry=0x7fffffffbd60, index=0, index at entry=7, instance=0x1f018a0, instance at entry=0x1f56520, bindingTarget=0x1f018a0, bindingTarget at entry=0x1f56520, valueTypeProperty=valueTypeProperty at entry=0x0, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1328 #16 0x00007ffff5a083ef in QQmlObjectCreator::createInstance(int, QObject*, bool) (this=this at entry=0x7fffffffbd60, index=, parent=, isContextObject=isContextObject at entry=false) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1175 #17 0x00007ffff5a0a619 in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*) (this=this at entry=0x7fffffffbd60, property=0x7fffc4041528, binding=binding at entry=0x7fffc41ec658) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:749 #18 0x00007ffff5a0a864 in QQmlObjectCreator::setupBindings(QBitArray const&) (this=this at entry=0x7fffffffbd60, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:701 #19 0x00007ffff5a0b34b in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*, QBitArray const&) (this=this at entry=0x7fffffffbd60, index=-1, index at entry=0, instance=0x0, instance at entry=0x1f018a0, bindingTarget=0x1f43360, bindingTarget at entry=0x1f018a0, valueTypeProperty=valueTypeProperty at entry=0x0, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1328 #20 0x00007ffff5a083ef in QQmlObjectCreator::createInstance(int, QObject*, bool) (this=this at entry=0x7fffffffbd60, index=index at entry=0, parent=parent at entry=0x0, isContextObject=isContextObject at entry=true) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1175 #21 0x00007ffff5a08c2f in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*) (this=this at entry=0x7fffffffbd60, subComponentIndex=subComponentIndex at entry=-1, parent=parent at entry=0x0, interrupt=interrupt at entry=0x0) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:203 #22 0x00007ffff5a0877e in QQmlObjectCreator::createInstance(int, QObject*, bool) (this=this at entry=0x1f2edb0, index=2, parent=0x1f2e790, isContextObject=isContextObject at entry=false) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1084 #23 0x00007ffff5a0a619 in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*) (this=this at entry=0x1f2edb0, property=0x7fffc4041528, binding=binding at entry=0x7fffc4187a1c) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:749 #24 0x00007ffff5a0a864 in QQmlObjectCreator::setupBindings(QBitArray const&) (this=this at entry=0x1f2edb0, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:701 #25 0x00007ffff5a0b34b in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*, QBitArray const&) (this=this at entry=0x1f2edb0, index=-1, index at entry=0, instance=0x0, instance at entry=0x1f2e790, bindingTarget=0x7ffff7020d90 , bindingTarget at entry=0x1f2e790, valueTypeProperty=valueTypeProperty at entry=0x0, bindingsToSkip=...) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1328 #26 0x00007ffff5a083ef in QQmlObjectCreator::createInstance(int, QObject*, bool) (this=this at entry=0x1f2edb0, index=index at entry=0, parent=parent at entry=0x0, isContextObject=isContextObject at entry=true) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:1175 #27 0x00007ffff5a08c2f in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*) (this=this at entry=0x1f2edb0, subComponentIndex=, parent=parent at entry=0x0, interrupt=interrupt at entry=0x0) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlobjectcreator.cpp:203 #28 0x00007ffff5987ed2 in QQmlComponentPrivate::beginCreate(QQmlContextData*) (this=0x1f3eea0, context=0x1f1dc50) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlcomponent.cpp:876 #29 0x00007ffff5988300 in QQmlComponent::create(QQmlContext*) (publicContext=0x1f1db90, this=0x1f3e6b0) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlcomponent.cpp:825 #30 0x00007ffff5988300 in QQmlComponent::create(QQmlContext*) (this=0x1f3e6b0, context=0x1f1db90) at /home/tjmaciei/src/qt/qt5/qtdeclarative/src/qml/qml/qqmlcomponent.cpp:785 #31 0x00007fffdd222384 in QQuickWidget::continueExecute() () at /home/tjmaciei/obj/qt/qt5-release/qtbase/lib/libQt5QuickWidgets.t.so.5 #32 0x00007fffdd222a0d in QQuickWidgetPrivate::execute() () at /home/tjmaciei/obj/qt/qt5-release/qtbase/lib/libQt5QuickWidgets.t.so.5 #33 0x00007fffd7acf1e5 in Welcome::Internal::WelcomeMode::initPlugins() () at /home/tjmaciei/obj/qt/qt-creator/lib/qtcreator/plugins/libWelcome.so #34 0x00007fffd7acf3ed in Welcome::Internal::WelcomePlugin::extensionsInitialized() () at /home/tjmaciei/obj/qt/qt-creator/lib/qtcreator/plugins/libWelcome.so #35 0x00007ffff7bba5a2 in ExtensionSystem::Internal::PluginSpecPrivate::initializeExtensions() () at /home/tjmaciei/obj/qt/qt-creator/bin/../lib/qtcreator/libExtensionSystem.so.4 #36 0x00007ffff7bb0cf1 in ExtensionSystem::Internal::PluginManagerPrivate::loadPlugin(ExtensionSystem::PluginSpec*, ExtensionSystem::PluginSpec::State) () at /home/tjmaciei/obj/qt/qt-creator/bin/../lib/qtcreator/libExtensionSystem.so.4 #37 0x00007ffff7bb27d4 in ExtensionSystem::Internal::PluginManagerPrivate::loadPlugins() () at /home/tjmaciei/obj/qt/qt-creator/bin/../lib/qtcreator/libExtensionSystem.so.4 #38 0x0000000000409b9f in main () From thiago.macieira at intel.com Thu May 19 19:58:24 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 19 May 2016 10:58:24 -0700 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: <1964494.0GIq51CFau@tjmaciei-mobl1> References: <1643034.I8z68kZl0M@zmeu> <1964494.0GIq51CFau@tjmaciei-mobl1> Message-ID: <2229586.Vk8qZPOxzT@tjmaciei-mobl1> On quinta-feira, 19 de maio de 2016 08:59:16 PDT Thiago Macieira wrote: > On quarta-feira, 18 de maio de 2016 11:01:09 PDT Bogdan Vatra wrote: > > Hi, > > > > Did anyone tried Qt (5.7) with GCC 6 ? > > I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4 > > when I start QtCreator :(. It's a know issue or just me? > > I can confirm it too. And it only happens in release mode. And I can also > confirm the problem does not happen when compiling with GCC 5.3.1. > > Backtrace with debugging symbols, but in release mode, is attached. I'll try > to study the generated code to see if I spot anything. -fno-delete-null-pointer-checks solves this problem. Of course, that doesn't explain where the issue is. I'll debug further later, after I figure out what's wrong with HiDPI -- after all, I can't debug if I can't read the text. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhunold at gmx.eu Thu May 19 21:08:48 2016 From: jhunold at gmx.eu (=?ISO-8859-1?Q?J=FCrgen?= Hunold) Date: Thu, 19 May 2016 21:08:48 +0200 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: <2229586.Vk8qZPOxzT@tjmaciei-mobl1> References: <1643034.I8z68kZl0M@zmeu> <1964494.0GIq51CFau@tjmaciei-mobl1> <2229586.Vk8qZPOxzT@tjmaciei-mobl1> Message-ID: <1678420.dAO4eVvLz6@gonne> Hi Thiago, Am Donnerstag, 19. Mai 2016, 10:58:24 CEST schrieb Thiago Macieira: > On quinta-feira, 19 de maio de 2016 08:59:16 PDT Thiago Macieira wrote: > > Backtrace with debugging symbols, but in release mode, is attached. I'll > > try to study the generated code to see if I spot anything. > > -fno-delete-null-pointer-checks solves this problem. Of course, that doesn't > explain where the issue is. I'll debug further later, after I figure out > what's wrong with HiDPI -- after all, I can't debug if I can't read the > text. What about reading the gcc release notes? From https://gcc.gnu.org/gcc-6/changes.html "Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined." I got this via https://blog.fefe.de/?ts=a9de792d (in german, unfortunately). So the rant there is for a limited audience... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold at gmx.eu ! Germany From thiago.macieira at intel.com Fri May 20 01:00:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 19 May 2016 16:00:57 -0700 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: <1678420.dAO4eVvLz6@gonne> References: <1643034.I8z68kZl0M@zmeu> <2229586.Vk8qZPOxzT@tjmaciei-mobl1> <1678420.dAO4eVvLz6@gonne> Message-ID: <14360716.TtMQkRdzOg@tjmaciei-mobl1> Em quinta-feira, 19 de maio de 2016, às 21:08:48 PDT, Jürgen Hunold escreveu: > Hi Thiago, > > Am Donnerstag, 19. Mai 2016, 10:58:24 CEST schrieb Thiago Macieira: > > On quinta-feira, 19 de maio de 2016 08:59:16 PDT Thiago Macieira wrote: > > > Backtrace with debugging symbols, but in release mode, is attached. I'll > > > try to study the generated code to see if I spot anything. > > > > -fno-delete-null-pointer-checks solves this problem. Of course, that > > doesn't explain where the issue is. I'll debug further later, after I > > figure out what's wrong with HiDPI -- after all, I can't debug if I can't > > read the text. > > What about reading the gcc release notes? > > From https://gcc.gnu.org/gcc-6/changes.html Workaround sent to 5.6.1: https://codereview.qt-project.org/159688 Unfortunately, this issue now has become third priority... in order to debug it, I need first to... * debug why Qt applications forget their device pixel ratio status when the screen is reconnected (reported as QTBUG-53500) but to do that, I first need to * fix Qt Creator to stop storming the X11 server with windows saying that something crashed (I don't think it was the application being debugged, so it must have been gdb) but in order to debug Qt Creator, I need to fix the HiDPI situation so I can read the text in Qt Creator. So I'm in a deadlock... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Fri May 20 07:08:46 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 20 May 2016 08:08:46 +0300 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: <1678420.dAO4eVvLz6@gonne> References: <1643034.I8z68kZl0M@zmeu> <1964494.0GIq51CFau@tjmaciei-mobl1> <2229586.Vk8qZPOxzT@tjmaciei-mobl1> <1678420.dAO4eVvLz6@gonne> Message-ID: Hi guys, you are talking about: * https://bugreports.qt.io/browse/QTCREATORBUG-16277 * https://bugreports.qt.io/browse/QBS-974 ? Denis 19.05.2016 22:08, Jürgen Hunold пишет: > Hi Thiago, > > Am Donnerstag, 19. Mai 2016, 10:58:24 CEST schrieb Thiago Macieira: >> On quinta-feira, 19 de maio de 2016 08:59:16 PDT Thiago Macieira wrote: >>> Backtrace with debugging symbols, but in release mode, is attached. I'll >>> try to study the generated code to see if I spot anything. >> -fno-delete-null-pointer-checks solves this problem. Of course, that doesn't >> explain where the issue is. I'll debug further later, after I figure out >> what's wrong with HiDPI -- after all, I can't debug if I can't read the >> text. > What about reading the gcc release notes? > > From https://gcc.gnu.org/gcc-6/changes.html > > "Value range propagation now assumes that the this pointer of C++ member > functions is non-null. This eliminates common null pointer checks but also > breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a > temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code > can be identified by using -fsanitize=undefined." > > I got this via https://blog.fefe.de/?ts=a9de792d (in german, unfortunately). > So the rant there is for a limited audience... > > Yours, > > Jürgen From skostysh at lyx.org Fri May 20 07:37:26 2016 From: skostysh at lyx.org (Scott Kostyshak) Date: Fri, 20 May 2016 01:37:26 -0400 Subject: [Development] Regression from 5.5.1 to 5.6.0 affecting LyX release In-Reply-To: <20160517063017.ocv3fto3zvc2mg5i@cotopaxi> References: <20160517063017.ocv3fto3zvc2mg5i@cotopaxi> Message-ID: <20160520053726.q6n4c5ihqkvytry5@cotopaxi> On Tue, May 17, 2016 at 02:30:17AM -0400, Scott Kostyshak wrote: > Dear all, > > Behavior has changed between Qt 5.5.1 and Qt 5.6.0 and I would like to > confirm that it is indeed a bug, and also ask if someone can suggest a > workaround? > > The bug report is posted here: > https://bugreports.qt.io/browse/QTBUG-53272 > > I posted on qt-interest [1], but did not get any bites and since it is > related to the development of Qt I'm asking here. > > It is affecting our LyX 2.2.0 release so any advice would be > appreciated. > > Scott > > [1] http://lists.qt-project.org/pipermail/interest/2016-May/022658.html The change in behavior was intended. Thanks to Tor Arne Vestbø for the explanation (see the bug report for details). One of our developers has come up with a fix that works on Linux/Mac/Win [1] and had the following comments regarding potential improvements to the documentation: I find that https://doc.qt.io/qt-5/qkeyevent.html#details could be understandable if they added the third paragraph of https://codereview.qt-project.org/125142. The lacking documentation probably explains this problem. Best, Scott [1] https://www.mail-archive.com/search?l=mid&q=nhgb7r%24flv%241%40ger.gmane.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From denis.shienkov at gmail.com Fri May 20 08:13:15 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 20 May 2016 09:13:15 +0300 Subject: [Development] Building and debugging Qt5 from QtC Message-ID: Hi developers, I want to know, is it possible to build/debug the qtbase's parts from the QtC? For example, when I try to build the Qt5 (with the configure/make sequence) for embedded board, I got some errors in EGLFS platform plugin. I want try to fix it, but it is very hard to do from the console :). I planns at first stage, to build the Qt without of EGLFS support, and on second stage to open the EGLFS-plugin's project from the QtC and try to fix errors. But I don't know, what of projects to open (there are three project files), and don't know what this way is right. So, my questions are: How you solves similar issues? I mean how is a working process? Do you use QtC or what? Where I can read about? :) BR, Denis From mitch.curtis at qt.io Fri May 20 11:11:25 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 20 May 2016 09:11:25 +0000 Subject: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10 Message-ID: Is anyone else able to reproduce this? I configured Qt with the following arguments (shadow build): -debug -developer-build -opensource -confirm-license -nomake tests -nomake examples -opengl desktop If I use nmake instead of jom, the only error comes from qlogging.cpp. I've attached the output of jom. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jom-output.txt URL: From sean.harmer at kdab.com Fri May 20 11:13:51 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 20 May 2016 10:13:51 +0100 Subject: [Development] Help needed: Qt 3D Android build issue Message-ID: <1581822.graGXO5Myn@titan> Hi, Trying to submit a simple patch to Qt 3D we are hitting a weird compilation error on Android CI configurations. The change is: https://codereview.qt-project.org/#/c/157592/ and the compilation errors can be seen in full at: http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfca8c02f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_OpenGLES2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt.gz but in brief they are: In file included from /opt/android/ndk/sources/cxx-stl/gnu- libstdc++/4.8/include/atomic:41:0, from /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45, from /home/qt/work/install/include/QtCore/qbasicatomic.h:53, from /home/qt/work/install/include/QtCore/qatomic.h:46, from /home/qt/work/install/include/QtCore/qglobal.h:1145, from ../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43, from ../../include/Qt3DCore/qt3dcore_global.h:1, from ../../include/Qt3DRender/../../src/render/qt3drender_global.h:43, from ../../include/Qt3DRender/qt3drender_global.h:1, from ../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/render/backend/backendnode_p.h:54, from ../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1, from backend/entity_p.h:55, from backend/entity.cpp:40: /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base.h: In member function 'virtual void Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)': /opt/android/ndk/sources/cxx-stl/gnu- libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model cannot be stronger than success memory model for '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model cannot be stronger than success memory model for '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model cannot be stronger than success memory model for '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model cannot be stronger than success memory model for '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base.h: In member function 'virtual void Qt3DRender::Render::Entity::initializeFromPeer(const QNodeCreatedChangeBasePtr&)': /opt/android/ndk/sources/cxx-stl/gnu- libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model cannot be stronger than success memory model for '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2); ^ The patch makes no direct use of atomics, only via QSharedPointer. BogDan reports that it builds fine with latest NDK. Is this a genuine error on our part or some corner case issue with the CI's installed NDK? I'm at a total loss with this one and have no idea how to investigate/fix. Any help would be greatly appreciated. :) Kind regards, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From nassian at bitshift-dynamics.de Fri May 20 11:15:11 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Fri, 20 May 2016 11:15:11 +0200 Subject: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10 In-Reply-To: References: Message-ID: <17EE0BCC-650D-44DB-B122-D350D185718E@bitshift-dynamics.de> Do you know this and did you already tried the suggested steps to fix? https://support.microsoft.com/en-us/kb/305980 Beste Grüße / Best regards, Alexander Nassian > Am 20.05.2016 um 11:11 schrieb Mitch Curtis : > > Is anyone else able to reproduce this? I configured Qt with the following arguments (shadow build): > > -debug -developer-build -opensource -confirm-license -nomake tests -nomake examples -opengl desktop > > If I use nmake instead of jom, the only error comes from qlogging.cpp. > > I've attached the output of jom. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From laszlo.agocs at qt.io Fri May 20 11:16:17 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Fri, 20 May 2016 09:16:17 +0000 Subject: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10 In-Reply-To: References: Message-ID: Yes. Same problem I complained about on IRC a few days ago. I was using VS2015 Update 1 then. Installing VS2015 Update 2 fixed it. The CIs have Update 2 installed as well. BR, Laszlo -----Original Message----- From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Mitch Curtis Sent: Friday, May 20, 2016 11:11 AM To: development at qt-project.org Subject: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10 Is anyone else able to reproduce this? I configured Qt with the following arguments (shadow build): -debug -developer-build -opensource -confirm-license -nomake tests -nomake examples -opengl desktop If I use nmake instead of jom, the only error comes from qlogging.cpp. I've attached the output of jom. From mitch.curtis at qt.io Fri May 20 11:23:19 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 20 May 2016 09:23:19 +0000 Subject: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10 In-Reply-To: References: Message-ID: A-ha, thanks. :) > -----Original Message----- > From: Laszlo Agocs > Sent: Friday, 20 May 2016 11:16 AM > To: Mitch Curtis ; development at qt-project.org > Subject: RE: [Development] Internal compiler error when building dev > branch of qtbase with MSVC2015 on Windows 10 > > Yes. Same problem I complained about on IRC a few days ago. I was using > VS2015 Update 1 then. Installing VS2015 Update 2 fixed it. The CIs have > Update 2 installed as well. > > BR, > Laszlo > > -----Original Message----- > From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt- > project.org] On Behalf Of Mitch Curtis > Sent: Friday, May 20, 2016 11:11 AM > To: development at qt-project.org > Subject: [Development] Internal compiler error when building dev branch of > qtbase with MSVC2015 on Windows 10 > > Is anyone else able to reproduce this? I configured Qt with the following > arguments (shadow build): > > -debug -developer-build -opensource -confirm-license -nomake tests -nomake > examples -opengl desktop > > If I use nmake instead of jom, the only error comes from qlogging.cpp. > > I've attached the output of jom. From mitch.curtis at qt.io Fri May 20 11:24:00 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 20 May 2016 09:24:00 +0000 Subject: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10 In-Reply-To: <17EE0BCC-650D-44DB-B122-D350D185718E@bitshift-dynamics.de> References: <17EE0BCC-650D-44DB-B122-D350D185718E@bitshift-dynamics.de> Message-ID: No, I didn’t see that. Thanks. :) From: Alexander Nassian [mailto:nassian at bitshift-dynamics.de] Sent: Friday, 20 May 2016 11:15 AM To: Mitch Curtis Cc: development at qt-project.org Subject: Re: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10 Do you know this and did you already tried the suggested steps to fix? https://support.microsoft.com/en-us/kb/305980 Beste Grüße / Best regards, Alexander Nassian Am 20.05.2016 um 11:11 schrieb Mitch Curtis >: Is anyone else able to reproduce this? I configured Qt with the following arguments (shadow build): -debug -developer-build -opensource -confirm-license -nomake tests -nomake examples -opengl desktop If I use nmake instead of jom, the only error comes from qlogging.cpp. I've attached the output of jom. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri May 20 14:48:11 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 20 May 2016 14:48:11 +0200 Subject: [Development] BC/SC reminder: noexcept and constexpr are part of a function's contract! Message-ID: <201605201448.12793.marc.mutz@kdab.com> Hi, Just a reminder that you _cannot_ remove noexcept (Q_DECL_NOTHROW/Q_DECL_NOEXCEPT) nor constexpr (Q_DECL_CONSTEXPR/Q_DECL_RELAXED_CONSTEXPR) from functions that are under SC constraints. Adding them is ok, but removing or downgrading them from NOTHROW to NOEXCEPT or from CONSTEXPR to RELAXED_CONSTEXPR is binary- and source- incompatible, resp. Please pay attention when patches attempt to remove or downgrade these macros, and don't add the macros lightly. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From Simon.Hausmann at qt.io Fri May 20 14:49:52 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 20 May 2016 12:49:52 +0000 Subject: [Development] Nominating Frank Meerkoetter for Approver status Message-ID: Hi, I would like to nominate Frank for approver status. He has done a fair bit of surgery in the QML engine and also seems to be active on qtopcua/serialbus. I appreciate his input on my patches and I trust him to responsibly review. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at qt.io Fri May 20 14:58:31 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Fri, 20 May 2016 12:58:31 +0000 Subject: [Development] Nominating Frank Meerkoetter for Approver status Message-ID: <8EC72ABF-CF77-4B1F-994A-5404DAE59DFC@qt.io> +1 Cheers, Lars From: Development > on behalf of Simon Hausmann > Date: Friday 20 May 2016 at 14:49 To: Qt development mailing list > Subject: [Development] Nominating Frank Meerkoetter for Approver status Hi, I would like to nominate Frank for approver status. He has done a fair bit of surgery in the QML engine and also seems to be active on qtopcua/serialbus. I appreciate his input on my patches and I trust him to responsibly review. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin+qt at viroteck.net Fri May 20 15:00:53 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 20 May 2016 15:00:53 +0200 Subject: [Development] Nominating Frank Meerkoetter for Approver status In-Reply-To: References: Message-ID: <1463749253.3943722.613709761.18C4F382@webmail.messagingengine.com> +1 :) On Fri, May 20, 2016, at 02:49 PM, Simon Hausmann wrote: > Hi, > > > I would like to nominate Frank for approver status. He has done a fair > bit of surgery in the QML engine and also seems to be active on > qtopcua/serialbus. > > > I appreciate his input on my patches and I trust him to responsibly > review. > > > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Fri May 20 15:09:06 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 20 May 2016 13:09:06 +0000 Subject: [Development] Nominating Frank Meerkoetter for Approver status In-Reply-To: <1463749253.3943722.613709761.18C4F382@webmail.messagingengine.com> References: <1463749253.3943722.613709761.18C4F382@webmail.messagingengine.com> Message-ID: <2D4245F6-94F9-4870-8740-91F14C80BC53@qt.io> +1 > On 20 May 2016, at 15:00, Robin Burchell wrote: > > +1 :) > > On Fri, May 20, 2016, at 02:49 PM, Simon Hausmann wrote: >> Hi, >> >> >> I would like to nominate Frank for approver status. He has done a fair >> bit of surgery in the QML engine and also seems to be active on >> qtopcua/serialbus. >> >> >> I appreciate his input on my patches and I trust him to responsibly >> review. >> >> >> >> Simon >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andre.hartmann at iseg-hv.de Fri May 20 15:26:13 2016 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 20 May 2016 15:26:13 +0200 Subject: [Development] Nominating Frank Meerkoetter for Approver status In-Reply-To: <2D4245F6-94F9-4870-8740-91F14C80BC53@qt.io> References: <1463749253.3943722.613709761.18C4F382@webmail.messagingengine.com> <2D4245F6-94F9-4870-8740-91F14C80BC53@qt.io> Message-ID: <573F1075.7020209@iseg-hv.de> +1 Am 20.05.2016 um 15:09 schrieb Shawn Rutledge: > +1 > >> On 20 May 2016, at 15:00, Robin Burchell wrote: >> >> +1 :) >> >> On Fri, May 20, 2016, at 02:49 PM, Simon Hausmann wrote: >>> Hi, >>> >>> >>> I would like to nominate Frank for approver status. He has done a fair >>> bit of surgery in the QML engine and also seems to be active on >>> qtopcua/serialbus. >>> >>> >>> I appreciate his input on my patches and I trust him to responsibly >>> review. >>> >>> >>> >>> Simon >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From joerg.bornemann at qt.io Fri May 20 15:32:38 2016 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Fri, 20 May 2016 15:32:38 +0200 Subject: [Development] Building and debugging Qt5 from QtC In-Reply-To: References: Message-ID: On 20/05/2016 08:13, Denis Shienkov wrote: > I want to know, is it possible to build/debug the qtbase's parts from > the QtC? Sure! I usually do something like this: - initially configure and build Qt on the console - add this Qt build in Qt Creator's build settings (Qt Version and Kit) - load qtbase.pro (or any other Qt module) in Qt Creator with the Kit corresponding to that Qt - disable the qmake step in the project's build settings Qt Creator picks up the right build directory, and you can happily code, build and debug your Qt module. BR, Joerg From thiago.macieira at intel.com Fri May 20 16:40:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 May 2016 07:40:19 -0700 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: References: <1643034.I8z68kZl0M@zmeu> <1678420.dAO4eVvLz6@gonne> Message-ID: <7872267.m2hCRLdYnV@tjmaciei-mobl1> Em sexta-feira, 20 de maio de 2016, às 08:08:46 PDT, Denis Shienkov escreveu: > Hi guys, > > you are talking about: > > * https://bugreports.qt.io/browse/QTCREATORBUG-16277 > > * https://bugreports.qt.io/browse/QBS-974 > > ? I'm not because I don't use QBS. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri May 20 16:42:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 May 2016 07:42:27 -0700 Subject: [Development] Building and debugging Qt5 from QtC In-Reply-To: References: Message-ID: <13309482.VI0JHYkKaI@tjmaciei-mobl1> Em sexta-feira, 20 de maio de 2016, às 15:32:38 PDT, Joerg Bornemann escreveu: > - load qtbase.pro (or any other Qt module) in Qt Creator with the Kit > corresponding to that Qt You may want to select src/src.pro or a closer .pro to what you want. No point in waiting for everything to be re-checked by make before starting to debug. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan at kdab.com Fri May 20 17:16:19 2016 From: bogdan at kdab.com (BogDan Vatra) Date: Fri, 20 May 2016 18:16:19 +0300 Subject: [Development] Qt + GCC 6 no joy ? In-Reply-To: <7872267.m2hCRLdYnV@tjmaciei-mobl1> References: <1643034.I8z68kZl0M@zmeu> <7872267.m2hCRLdYnV@tjmaciei-mobl1> Message-ID: <1909980.1Ep3tA6Mch@debian> On Friday 20 May 2016 07:40:19 Thiago Macieira wrote: > Em sexta-feira, 20 de maio de 2016, às 08:08:46 PDT, Denis Shienkov escreveu: > > Hi guys, > > > > you are talking about: > > > > * https://bugreports.qt.io/browse/QTCREATORBUG-16277 > > > > * https://bugreports.qt.io/browse/QBS-974 > > > > ? > > I'm not because I don't use QBS. Did you tried the one from QtSDK? Every time when the compiled one fails me I go back to the official one ;-). Cheers, BogDan. From tres.finocchiaro at gmail.com Fri May 20 18:20:47 2016 From: tres.finocchiaro at gmail.com (Tres Finocchiaro) Date: Fri, 20 May 2016 12:20:47 -0400 Subject: [Development] High CPU with QToolBar win32 Message-ID: Hi, Are there any known issues with QToolBar Qt5 win32? We've (LMMS) a downstream bug and I'm trying to isolate the cause. https://github.com/LMMS/lmms/issues/2767 - It only happens with Qt5 - It only happens with QToolBar - We have the QToolBar in a QMdiSubwindow/QWidget, not the main window. - It's not reproducible with QtCreator, at least when using the default UI creator and the main window's toolbar. - We use a win32 build of Qt5 from a self-maintained PPA, so if a particular issue was addressed upstream we may not have it yet, but I couldn't find a particular bug that mentioned this. Disclaimer, slight amateur debugging these things. :) -Tres - Tres.Finocchiaro at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Fri May 20 19:39:26 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 20 May 2016 19:39:26 +0200 Subject: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing In-Reply-To: <20160513113630.GA6600@troll08.it.local> References: <20160513113630.GA6600@troll08.it.local> Message-ID: <20160520173926.GA4249@troll08.it.local> 5.7.0 is fully (*) branched now. staging is limited to the release team. as usual, i'm taking retargeting requests for tardy changes. (*) actually, it's not. webengine is still integrating something since half a day. On Fri, May 13, 2016 at 01:36:30PM +0200, Oswald Buddenhagen wrote: > The 5.7.0 branch is now available. Please start using it for changes > targeting the Qt 5.7.0 release. > > We will merge the 5.7 branch to 5.7.0 a last time on May 19th, so > there should be enough time to finalize ongoing changes in 5.7, and > start using 5.7.0 for new changes. > > Changes done on 5.7.0 are forward-merged to 5.7 and dev - as usual. > Don't cherry-pick in either direction if at all avoidable - as usual. > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From sean.harmer at kdab.com Fri May 20 20:49:11 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 20 May 2016 19:49:11 +0100 Subject: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing In-Reply-To: <20160520173926.GA4249@troll08.it.local> References: <20160513113630.GA6600@troll08.it.local> <20160520173926.GA4249@troll08.it.local> Message-ID: <6d6f0323-e3b4-a79c-72c3-de0354d6aee6@kdab.com> Hi Ossi, apologies I have a set of changes now integrating that have been fighting with the CI for a few days which now look to be going through. Should I do another 5.7 -> 5.7.0 merge after they land? They need to get in to fix some P0 issues in Qt 3D. Cheers, Sean On 20/05/2016 18:39, Oswald Buddenhagen wrote: > 5.7.0 is fully (*) branched now. staging is limited to the release team. > > as usual, i'm taking retargeting requests for tardy changes. > > (*) actually, it's not. webengine is still integrating something since > half a day. > > On Fri, May 13, 2016 at 01:36:30PM +0200, Oswald Buddenhagen wrote: >> The 5.7.0 branch is now available. Please start using it for changes >> targeting the Qt 5.7.0 release. >> >> We will merge the 5.7 branch to 5.7.0 a last time on May 19th, so >> there should be enough time to finalize ongoing changes in 5.7, and >> start using 5.7.0 for new changes. >> >> Changes done on 5.7.0 are forward-merged to 5.7 and dev - as usual. >> Don't cherry-pick in either direction if at all avoidable - as usual. >> _______________________________________________ >> Releasing mailing list >> Releasing at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/releasing > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri May 20 23:23:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 May 2016 14:23:51 -0700 Subject: [Development] [Releasing] New Qt 5.7.0 RC snapshot available In-Reply-To: References: <11997800.8p2vFT3UM1@w530.nolden.freebsd> Message-ID: <1770391.zVJQJHIuHz@tjmaciei-mobl1> Em quarta-feira, 18 de maio de 2016, às 15:04:24 PDT, Kai Koehne escreveu: > > So, an updated tarball for qtquick1 for 5.6 would be really much > > appreciated (so that it works with 5.6.x and 5.7.x) > > It's the first time I hear someone asking for a tarball for QtQuick1. We WILL NOT provide a QtQuick1 tarball for 5.7. This was advised during the Qt 5.5.0 release, over a year ago: ==== - The QtWebKit and QtQuick1 modules and support for the QML 1 language are deprecated and Qt 5.5 will be the last release to include them. Starting with Qt 5.6, the source code for those modules will not be included in Qt's packaging. Compiling the 5.5 release of QtWebKit modules along with Qt 5.6 or future versions should work. QtQuick1 is not guaranteed to work in future versions after Qt 5.6. - The QtScript module is deprecated and will be removed from Qt's packaging starting with version 5.7. The 5.5 and 5.6 releases of QtScript should continue to work along with Qt 5.7 and future versions. ==== That's because QtQuick1 uses Qt internals quite extensively. There's no guarantee that it will even compile, much less work. Yes, this will be a pain for Linux distributions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nolden at kde.org Fri May 20 23:44:38 2016 From: nolden at kde.org (Ralf Nolden) Date: Fri, 20 May 2016 23:44:38 +0200 Subject: [Development] [Releasing] New Qt 5.7.0 RC snapshot available In-Reply-To: <1770391.zVJQJHIuHz@tjmaciei-mobl1> References: <1770391.zVJQJHIuHz@tjmaciei-mobl1> Message-ID: <4154742.oj8n8qu7D0@w530.nolden.freebsd> Am Freitag, 20. Mai 2016, 14:23:51 schrieb Thiago Macieira: > Em quarta-feira, 18 de maio de 2016, às 15:04:24 PDT, Kai Koehne escreveu: > > > So, an updated tarball for qtquick1 for 5.6 would be really much > > > appreciated (so that it works with 5.6.x and 5.7.x) > > > > It's the first time I hear someone asking for a tarball for QtQuick1. > > We WILL NOT provide a QtQuick1 tarball for 5.7. Never mind, I've changed the FreeBSD port according to Simon's advice on IRC to use the branch, so at least my problem is solved :) > This was advised during the > Qt 5.5.0 release, over a year ago: > > ==== > - The QtWebKit and QtQuick1 modules and support for the QML 1 language > are deprecated and Qt 5.5 will be the last release to include > them. Starting with Qt 5.6, the source code for those modules will > not be included in Qt's packaging. Compiling the 5.5 release of > QtWebKit modules along with Qt 5.6 or future versions should > work. QtQuick1 is not guaranteed to work in future versions after > Qt 5.6. > > - The QtScript module is deprecated and will be removed from Qt's > packaging starting with version 5.7. The 5.5 and 5.6 releases of > QtScript should continue to work along with Qt 5.7 and future > versions. > ==== > > That's because QtQuick1 uses Qt internals quite extensively. There's no > guarantee that it will even compile, much less work. > > Yes, this will be a pain for Linux distributions. -- Kind regards, Ralf Nolden From sean.harmer at kdab.com Sat May 21 13:10:16 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sat, 21 May 2016 12:10:16 +0100 Subject: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing In-Reply-To: <6d6f0323-e3b4-a79c-72c3-de0354d6aee6@kdab.com> References: <20160513113630.GA6600@troll08.it.local> <20160520173926.GA4249@troll08.it.local> <6d6f0323-e3b4-a79c-72c3-de0354d6aee6@kdab.com> Message-ID: <1484125.kRQ2TglBSv@titan> On Friday 20 May 2016 19:49:11 Sean Harmer wrote: > Hi Ossi, > > apologies I have a set of changes now integrating that have been > fighting with the CI for a few days which now look to be going through. > Should I do another 5.7 -> 5.7.0 merge after they land? They need to get > in to fix some P0 issues in Qt 3D. Thanks for doing the merge and sorry once again. Could you retarget these to 5.7.0 please? : https://codereview.qt-project.org/#/c/159582/ https://codereview.qt-project.org/#/c/159583/ https://codereview.qt-project.org/#/c/159638/ https://codereview.qt-project.org/#/c/159639/ https://codereview.qt-project.org/#/c/159756/ https://codereview.qt-project.org/#/c/159757/ https://codereview.qt-project.org/#/c/157592/ https://codereview.qt-project.org/#/c/159835/ Many thanks! Sean > > Cheers, > > Sean > > On 20/05/2016 18:39, Oswald Buddenhagen wrote: > > 5.7.0 is fully (*) branched now. staging is limited to the release team. > > > > as usual, i'm taking retargeting requests for tardy changes. > > > > (*) actually, it's not. webengine is still integrating something since > > half a day. > > > > On Fri, May 13, 2016 at 01:36:30PM +0200, Oswald Buddenhagen wrote: > >> The 5.7.0 branch is now available. Please start using it for changes > >> targeting the Qt 5.7.0 release. > >> > >> We will merge the 5.7 branch to 5.7.0 a last time on May 19th, so > >> there should be enough time to finalize ongoing changes in 5.7, and > >> start using 5.7.0 for new changes. > >> > >> Changes done on 5.7.0 are forward-merged to 5.7 and dev - as usual. > >> Don't cherry-pick in either direction if at all avoidable - as usual. > >> _______________________________________________ > >> Releasing mailing list > >> Releasing at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/releasing > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From sean.harmer at kdab.com Sat May 21 13:12:08 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sat, 21 May 2016 12:12:08 +0100 Subject: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing In-Reply-To: <1484125.kRQ2TglBSv@titan> References: <20160513113630.GA6600@troll08.it.local> <6d6f0323-e3b4-a79c-72c3-de0354d6aee6@kdab.com> <1484125.kRQ2TglBSv@titan> Message-ID: <2101201.UOJLOpKZo4@titan> On Saturday 21 May 2016 12:10:16 Sean Harmer wrote: > On Friday 20 May 2016 19:49:11 Sean Harmer wrote: > > Hi Ossi, > > > > apologies I have a set of changes now integrating that have been > > fighting with the CI for a few days which now look to be going through. > > Should I do another 5.7 -> 5.7.0 merge after they land? They need to get > > in to fix some P0 issues in Qt 3D. > > Thanks for doing the merge and sorry once again. > > Could you retarget these to 5.7.0 please? : > > https://codereview.qt-project.org/#/c/159582/ > https://codereview.qt-project.org/#/c/159583/ > https://codereview.qt-project.org/#/c/159638/ > https://codereview.qt-project.org/#/c/159639/ > https://codereview.qt-project.org/#/c/159756/ > https://codereview.qt-project.org/#/c/159757/ > https://codereview.qt-project.org/#/c/157592/ > https://codereview.qt-project.org/#/c/159835/ And this one too please: https://codereview.qt-project.org/#/c/159649/ Cheers, Sean From nolden at kde.org Sat May 21 13:41:55 2016 From: nolden at kde.org (Ralf Nolden) Date: Sat, 21 May 2016 13:41:55 +0200 Subject: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing In-Reply-To: <2101201.UOJLOpKZo4@titan> References: <20160513113630.GA6600@troll08.it.local> <1484125.kRQ2TglBSv@titan> <2101201.UOJLOpKZo4@titan> Message-ID: <2222614.ls9B6docro@w530.nolden.freebsd> Am Samstag, 21. Mai 2016, 12:12:08 schrieb Sean Harmer: > > Thanks for doing the merge and sorry once again. > > > > Could you retarget these to 5.7.0 please? : > > > > https://codereview.qt-project.org/#/c/159582/ > > https://codereview.qt-project.org/#/c/159583/ > > https://codereview.qt-project.org/#/c/159638/ > > https://codereview.qt-project.org/#/c/159639/ > > https://codereview.qt-project.org/#/c/159756/ > > https://codereview.qt-project.org/#/c/159757/ > > https://codereview.qt-project.org/#/c/157592/ > > https://codereview.qt-project.org/#/c/159835/ > > And this one too please: > > https://codereview.qt-project.org/#/c/159649/ I don't want to raise more workload, however, I would like to have https://codereview.qt-project.org/#/c/159318/ merged into 5.6.1 and 5.7.0 if at all possible. Without the patch, no BSD system is actually able to execute any Qt binaries (platform plugins fail to load) and the build doesn't produce compile errors so the cause is not easily detectable. That's the only patch really badly needed from our side. Sorry for being late with this, I tried to get things moving ahead of branching but got delayed. -- Kind regards, Ralf Nolden From denis.shienkov at gmail.com Mon May 23 07:11:32 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 23 May 2016 08:11:32 +0300 Subject: [Development] Building and debugging Qt5 from QtC In-Reply-To: <13309482.VI0JHYkKaI@tjmaciei-mobl1> References: <13309482.VI0JHYkKaI@tjmaciei-mobl1> Message-ID: <799594ae-7179-3de4-da40-10d88274daa2@gmail.com> Many thanks to all, I will check. BR, Denis 20.05.2016 17:42, Thiago Macieira пишет: > Em sexta-feira, 20 de maio de 2016, às 15:32:38 PDT, Joerg Bornemann escreveu: >> - load qtbase.pro (or any other Qt module) in Qt Creator with the Kit >> corresponding to that Qt > You may want to select src/src.pro or a closer .pro to what you want. No point > in waiting for everything to be re-checked by make before starting to debug. > From alexander.blasche at qt.io Mon May 23 07:50:56 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Mon, 23 May 2016 05:50:56 +0000 Subject: [Development] Nominating Frank Meerkoetter for Approver status In-Reply-To: References: Message-ID: >I would like to nominate Frank for approver status. He has done a fair bit of surgery in the QML >engine and also seems to be active on qtopcua/serialbus. +1 -- Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Mon May 23 10:10:52 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 23 May 2016 10:10:52 +0200 Subject: [Development] widget rendering issues on OS X Message-ID: <2264640.6TJaE32amQ@patux> Hello, FYI: I'm cross-posting a link to a KDE bug report I just filed, about rendering issues with certain kinds of widgets on OS X. These occur only with the "macintosh" widget style, also when I use that style in combination with the XCB qpa plugin. That does suggest the issue might be somewhere in Qt's "macintosh" widget drawing routines. A screenshot is attached to the bug report. https://bugs.kde.org/show_bug.cgi?id=363423 Cheers, R. From milian.wolff at kdab.com Mon May 23 11:17:29 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 23 May 2016 11:17:29 +0200 Subject: [Development] Nominating Frank Meerkoetter for Approver status In-Reply-To: References: Message-ID: <12956670.kUn06RPl6Y@milian-kdab2> On Friday, May 20, 2016 12:49:52 PM CEST Simon Hausmann wrote: > Hi, > > > I would like to nominate Frank for approver status. He has done a fair bit > of surgery in the QML engine and also seems to be active on > qtopcua/serialbus. > > > I appreciate his input on my patches and I trust him to responsibly review. +1, he also helped me a lot on the WebChannel front. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From milian.wolff at kdab.com Mon May 23 11:18:33 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 23 May 2016 11:18:33 +0200 Subject: [Development] High CPU with QToolBar win32 In-Reply-To: References: Message-ID: <1725337.28yZje9JEE@milian-kdab2> On Friday, May 20, 2016 12:20:47 PM CEST Tres Finocchiaro wrote: > Hi, > > Are there any known issues with QToolBar Qt5 win32? > > We've (LMMS) a downstream bug and I'm trying to isolate the cause. > > https://github.com/LMMS/lmms/issues/2767 > > > - It only happens with Qt5 > - It only happens with QToolBar > - We have the QToolBar in a QMdiSubwindow/QWidget, not the main > window. > - It's not reproducible with QtCreator, at least when using the default > UI creator and the main window's toolbar. > - We use a win32 build of Qt5 from a self-maintained PPA, so if a > particular issue was addressed upstream we may not have it yet, but I > couldn't find a particular bug that mentioned this. > > Disclaimer, slight amateur debugging these things. :) If this is a performance issue, then please use a profiler to figure out where time is being spent. Visual Studio nowadays has a simple but usable sampling profiler built-in. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From michael.bruning at qt.io Mon May 23 11:20:32 2016 From: michael.bruning at qt.io (=?UTF-8?Q?Michael_Br=c3=bcning?=) Date: Mon, 23 May 2016 11:20:32 +0200 Subject: [Development] Nominating Frank Meerkoetter for Approver status In-Reply-To: References: Message-ID: <5742CB60.2060102@qt.io> On 05/20/2016 02:49 PM, Simon Hausmann wrote: > > Hi, > > > I would like to nominate Frank for approver status. He has done a fair > bit of surgery in the QML engine and also seems to be active on > qtopcua/serialbus. > > > I appreciate his input on my patches and I trust him to responsibly > review. > +1 from me as well. -- Cheers, Michael > > > Simon > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Michael Brüning Senior Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin michael.bruning at qt.io +49 171 764 0871 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Mon May 23 12:15:29 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 23 May 2016 12:15:29 +0200 Subject: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing In-Reply-To: <2222614.ls9B6docro@w530.nolden.freebsd> References: <20160513113630.GA6600@troll08.it.local> <1484125.kRQ2TglBSv@titan> <2101201.UOJLOpKZo4@titan> <2222614.ls9B6docro@w530.nolden.freebsd> Message-ID: <20160523101529.GA3251@troll08.it.local> On Sat, May 21, 2016 at 01:41:55PM +0200, Ralf Nolden wrote: > I don't want to raise more workload, however, I would like to have > > https://codereview.qt-project.org/#/c/159318/ > > merged into 5.6.1 and 5.7.0 if at all possible. > nope. we don't cherry-pick except in exceptional cases. > Without the patch, no BSD system is actually able to execute any Qt > binaries > that's too bad, but no bsd system is officially part of the supported platforms (unless you count apple as bsd ...), so any issues related to it cannot be release critical by definition. From sean.harmer at kdab.com Mon May 23 13:54:16 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 23 May 2016 12:54:16 +0100 Subject: [Development] Help needed: Qt 3D Android build issue In-Reply-To: <1581822.graGXO5Myn@titan> References: <1581822.graGXO5Myn@titan> Message-ID: <10768524.8n3z2liUFB@cartman> Bump, is anybody able to help here please? Thanks, Sean On Friday 20 May 2016 10:13:51 Sean Harmer wrote: > Hi, > > Trying to submit a simple patch to Qt 3D we are hitting a weird compilation > error on Android CI configurations. The change is: > > https://codereview.qt-project.org/#/c/157592/ > > and the compilation errors can be seen in full at: > > http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfca8c0 > 2f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_OpenGLES > 2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt.gz > > but in brief they are: > > In file included from /opt/android/ndk/sources/cxx-stl/gnu- > libstdc++/4.8/include/atomic:41:0, > from > /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45, from > /home/qt/work/install/include/QtCore/qbasicatomic.h:53, from > /home/qt/work/install/include/QtCore/qatomic.h:46, from > /home/qt/work/install/include/QtCore/qglobal.h:1145, from > ../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43, > from ../../include/Qt3DCore/qt3dcore_global.h:1, > from > ../../include/Qt3DRender/../../src/render/qt3drender_global.h:43, > from ../../include/Qt3DRender/qt3drender_global.h:1, > from > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/render/ > backend/backendnode_p.h:54, from > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1, > from backend/entity_p.h:55, > from backend/entity.cpp:40: > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base. > h: In member function 'virtual void > Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)': > /opt/android/ndk/sources/cxx-stl/gnu- > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model > cannot be stronger than success memory model for > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model > cannot be stronger than success memory model for > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model > cannot be stronger than success memory model for > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model > cannot be stronger than success memory model for > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > &__i1, __i2, 0, __m1, __m2); ^ > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base > .h: In member function 'virtual void > Qt3DRender::Render::Entity::initializeFromPeer(const > QNodeCreatedChangeBasePtr&)': > /opt/android/ndk/sources/cxx-stl/gnu- > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model > cannot be stronger than success memory model for > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > &__i1, __i2, 0, __m1, __m2); ^ > > The patch makes no direct use of atomics, only via QSharedPointer. BogDan > reports that it builds fine with latest NDK. > > Is this a genuine error on our part or some corner case issue with the CI's > installed NDK? > > I'm at a total loss with this one and have no idea how to investigate/fix. > > Any help would be greatly appreciated. :) > > Kind regards, > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From annulen at yandex.ru Mon May 23 18:11:26 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 23 May 2016 19:11:26 +0300 Subject: [Development] Move assignment without move constructors Message-ID: <492121464019886@web23g.yandex.ru> Hello, I've stumbled upon QPixmap having operator=(QPixmap&&) but missing QPixmap(QPixmap&&), however it seems like there are a lot of Qt classes in the same situation, for example: QDir QFileInfo QProcessEnvironment QStorageInfo QUrlQuery QMimeType QCollatorSortKey QCommandLineOption QContiguousCache QDateTime QLocale QRegExp QRegularExpression, QRegularExpressionMatch, QRegularExpressionMatchIterator QTimeZone ... Is there any good reason for these classes to not have move constructor, or is it just an unfortunate omission? -- Regards, Konstantin From giuseppe.dangelo at kdab.com Mon May 23 18:25:14 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 23 May 2016 18:25:14 +0200 Subject: [Development] Move assignment without move constructors In-Reply-To: <492121464019886@web23g.yandex.ru> References: <492121464019886@web23g.yandex.ru> Message-ID: <57432EEA.1010908@kdab.com> Il 23/05/2016 18:11, Konstantin Tokarev ha scritto: > Hello, > > I've stumbled upon QPixmap having operator=(QPixmap&&) but missing QPixmap(QPixmap&&), however it seems like there are a lot of Qt classes in the same situation, for example: > [snip] > Is there any good reason for these classes to not have move constructor, or is it just an unfortunate omission? Because the implementation of a move constructor for those classes requires the private class to be defined in the public header, but all those classes are pimpl'd, so by definition you don't have that private class available. Cf. the "Move ctors for q_declare_shared types" thread we had some time ago, and https://codereview.qt-project.org/#/c/115213/ . Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Mon May 23 18:46:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 23 May 2016 09:46:55 -0700 Subject: [Development] Move assignment without move constructors In-Reply-To: <57432EEA.1010908@kdab.com> References: <492121464019886@web23g.yandex.ru> <57432EEA.1010908@kdab.com> Message-ID: <2425645.1RhnshoX4J@tjmaciei-mobl1> On segunda-feira, 23 de maio de 2016 18:25:14 PDT Giuseppe D'Angelo wrote: > > Is there any good reason for these classes to not have move constructor, > > or is it just an unfortunate omission? > Because the implementation of a move constructor for those classes > requires the private class to be defined in the public header, but all > those classes are pimpl'd, so by definition you don't have that private > class available. We couldn't implement them before Qt 5.7, but we can now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon May 23 19:50:18 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 23 May 2016 20:50:18 +0300 Subject: [Development] Move assignment without move constructors In-Reply-To: <57432EEA.1010908@kdab.com> References: <492121464019886@web23g.yandex.ru> <57432EEA.1010908@kdab.com> Message-ID: <749761464025818@web23g.yandex.ru> 23.05.2016, 19:25, "Giuseppe D'Angelo" : > Il 23/05/2016 18:11, Konstantin Tokarev ha scritto: >>  Hello, >> >>  I've stumbled upon QPixmap having operator=(QPixmap&&) but missing QPixmap(QPixmap&&), however it seems like there are a lot of Qt classes in the same situation, for example: > > [snip] > >>  Is there any good reason for these classes to not have move constructor, or is it just an unfortunate omission? > > Because the implementation of a move constructor for those classes > requires the private class to be defined in the public header, but all > those classes are pimpl'd, so by definition you don't have that private > class available. Copy constructors are not defined in headers, so don't see any reason for move constructors to be inline. And if those move constructors are defined in .cpp files, it should not be needed to include private headers into public. > > Cf. the "Move ctors for q_declare_shared types" thread we had some time > ago, and https://codereview.qt-project.org/#/c/115213/ . > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - The Qt Experts > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From kde at carewolf.com Mon May 23 20:33:56 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 23 May 2016 20:33:56 +0200 Subject: [Development] Move assignment without move constructors In-Reply-To: <749761464025818@web23g.yandex.ru> References: <492121464019886@web23g.yandex.ru> <57432EEA.1010908@kdab.com> <749761464025818@web23g.yandex.ru> Message-ID: <201605232033.56579.kde@carewolf.com> On Monday 23 May 2016, Konstantin Tokarev wrote: > 23.05.2016, 19:25, "Giuseppe D'Angelo" : > > Il 23/05/2016 18:11, Konstantin Tokarev ha scritto: > >> Hello, > > > >> I've stumbled upon QPixmap having operator=(QPixmap&&) but missing QPixmap(QPixmap&&), however it seems like there are a lot of Qt classes in the same situation, for example: > > [snip] > > > >> Is there any good reason for these classes to not have move > >> constructor, or is it just an unfortunate omission? > > > > Because the implementation of a move constructor for those classes > > requires the private class to be defined in the public header, but all > > those classes are pimpl'd, so by definition you don't have that private > > class available. > > Copy constructors are not defined in headers, so don't see any reason for > move constructors to be inline. And if those move constructors are defined > in .cpp files, it should not be needed to include private headers into > public. > The problem is/was that C++11 support was optional before Qt 5.7, and that an application could use C++11 for itself but use a Qt version compiled without C++11. This meant they had to be binary compatible, and therefore any C++11 specific methods had to be defined inline in the Qt headers. As Thiago said, this should be something we could finally solve now in 5.7 or 5.8. Regards `Allan From giuseppe.dangelo at kdab.com Mon May 23 20:40:36 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 23 May 2016 20:40:36 +0200 Subject: [Development] Move assignment without move constructors In-Reply-To: <749761464025818@web23g.yandex.ru> References: <492121464019886@web23g.yandex.ru> <57432EEA.1010908@kdab.com> <749761464025818@web23g.yandex.ru> Message-ID: <57434EA4.2000605@kdab.com> Il 23/05/2016 19:50, Konstantin Tokarev ha scritto: > > > 23.05.2016, 19:25, "Giuseppe D'Angelo" : >> Il 23/05/2016 18:11, Konstantin Tokarev ha scritto: >>> Hello, >>> >>> I've stumbled upon QPixmap having operator=(QPixmap&&) but missing QPixmap(QPixmap&&), however it seems like there are a lot of Qt classes in the same situation, for example: >> >> [snip] >> >>> Is there any good reason for these classes to not have move constructor, or is it just an unfortunate omission? >> >> Because the implementation of a move constructor for those classes >> requires the private class to be defined in the public header, but all >> those classes are pimpl'd, so by definition you don't have that private >> class available. > > Copy constructors are not defined in headers, so don't see any reason for > move constructors to be inline. And if those move constructors are defined in > .cpp files, it should not be needed to include private headers into public. Unfortunately, that was not the case before 5.7, as we 1) could not require C++11; 2) Qt claimed binary compatibility between any combination of application compiled with/without C++11 x Qt compiled with/without C++11. The problem was that an application compiled with C++11 against a C++11 Qt would use the move operations _exported_ by Qt, but then the same application could not run against a C++98 build of Qt (which would not export them). (*) For this reason, some C++11-only bits of Qt (such the move assignment) was implemented as an inline function in the header, which then causes the problem with the private class not being defined at that point. Since 5.7 Qt started requiring C++11, so we can implement move constructors too (out of line); I think we require move operations to be fully working, otherwise we go back to the pre-5.7 status, but I can't find the feature whitelist document right now. Any takers for the task? :) (*) I'm personally against this kind of "stretched" definitions of binary compatibility, but that's just my personal opinion... -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Mon May 23 22:45:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 23 May 2016 13:45:28 -0700 Subject: [Development] Move assignment without move constructors In-Reply-To: <57434EA4.2000605@kdab.com> References: <492121464019886@web23g.yandex.ru> <749761464025818@web23g.yandex.ru> <57434EA4.2000605@kdab.com> Message-ID: <4521110.ffJzUDPOJK@tjmaciei-mobl1> Em segunda-feira, 23 de maio de 2016, às 20:40:36 PDT, Giuseppe D'Angelo escreveu: > Any takers for the task? I've already added it for QDateTime: https://codereview.qt-project.org/159085 It's part of the short date time work. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Tue May 24 11:23:20 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 24 May 2016 09:23:20 +0000 Subject: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing In-Reply-To: <20160523101529.GA3251@troll08.it.local> References: <20160513113630.GA6600@troll08.it.local> <1484125.kRQ2TglBSv@titan> <2101201.UOJLOpKZo4@titan> <2222614.ls9B6docro@w530.nolden.freebsd> <20160523101529.GA3251@troll08.it.local> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Oswald > Buddenhagen > Sent: maanantaina 23. toukokuuta 2016 13.15 > To: development at qt-project.org > Subject: Re: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching > ongoing > > On Sat, May 21, 2016 at 01:41:55PM +0200, Ralf Nolden wrote: > > I don't want to raise more workload, however, I would like to have > > > > https://codereview.qt-project.org/#/c/159318/ > > > > merged into 5.6.1 and 5.7.0 if at all possible. > > > nope. we don't cherry-pick except in exceptional cases. > Now that we have branched, it is important to target the changes one desires to have in Qt 5.7.0 into the 5.7.0 branch (together with the release team). Changes merged into 5.7 branch will be part of 5.7.1 (and Qt 5.8.0 eventually). Similarly, anything needed in Qt 5.6.1 release has to go into the 5.6.1 branch (together with the release team, and getting very late now to make any changes). Things merged now into 5.6 will be released in Qt 5.6.2, 5.7.1 and 5.8.0 as we are always merging bug fixes upwards. And remember that we are close to the release, no nice-to-have fixes can go in - otherwise we have too high risk of something unexpected happening and miss the planned release time. Yours, Tuukka > > Without the patch, no BSD system is actually able to execute any Qt > > binaries > > > that's too bad, but no bsd system is officially part of the supported platforms > (unless you count apple as bsd ...), so any issues related to it cannot be > release critical by definition. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue May 24 12:50:13 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 24 May 2016 10:50:13 +0000 Subject: [Development] Qt 5.7.0 change files In-Reply-To: References: Message-ID: I and Antti have now done initial change files for every qt submodule (if not already available). Maintaitainers: Please take those over & modify files properly and add missing data. We just ran Create_changelog.pl ../ v5.6.0...HEAD + added some default data there so most probably those need some actions (at least +2) from you br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Tue May 24 14:39:36 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 24 May 2016 14:39:36 +0200 Subject: [Development] Qt 5.7.0 change files In-Reply-To: References: Message-ID: <5059032.Cz5StnbgTp@oscar> On Dienstag, 24. Mai 2016 10:50:13 CEST Jani Heikkinen wrote: > I and Antti have now done initial change files for every qt submodule (if > not already available). Maintaitainers: Please take those over & modify > files properly and add missing data. Where can we find them? (so we can manually add missing entries) > We just ran > > Create_changelog.pl ../ v5.6.0...HEAD Does this includes all the changes that are meant for 5.6.x? Are they supposed to be in the 5.7.0 ChangeLog? -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From jani.heikkinen at qt.io Tue May 24 16:39:21 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 24 May 2016 14:39:21 +0000 Subject: [Development] Qt 5.7.0 change files In-Reply-To: <5059032.Cz5StnbgTp@oscar> References: <5059032.Cz5StnbgTp@oscar> Message-ID: There are WIP changes for those in codereview, in '5.7.0' branch Br, Jani >>-----Original Message----- >>From: Olivier Goffart [mailto:olivier at woboq.com] >>Sent: 24. toukokuuta 2016 15:40 >>To: development at qt-project.org >>Cc: Jani Heikkinen >>Subject: Re: [Development] Qt 5.7.0 change files >> >>On Dienstag, 24. Mai 2016 10:50:13 CEST Jani Heikkinen wrote: >>> I and Antti have now done initial change files for every qt submodule (if >>> not already available). Maintaitainers: Please take those over & modify >>> files properly and add missing data. >> >>Where can we find them? (so we can manually add missing entries) >> >>> We just ran >>> >>> Create_changelog.pl ../ v5.6.0...HEAD >> >>Does this includes all the changes that are meant for 5.6.x? Are they supposed >>to be in the 5.7.0 ChangeLog? >> >>-- >>Olivier >> >>Woboq - Qt services and support - https://woboq.com - >>https://code.woboq.org From denis.shienkov at gmail.com Tue May 24 16:40:27 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 24 May 2016 17:40:27 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? Message-ID: Hi all. I have the Toradex (Apalis T30) embedded board: https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 which has: http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 Linux Image, with the GStreamer 0.10. Also I have compiled Qt 5.6 and installed it to the board. When I try to play any *.MP4 video file from the QML Video item: http://doc.qt.io/qt-5/qml-qtmultimedia-video.html I see, that my video has very-very lags, and I see (with htop utility) that CPU loading is ~300% ( three cores running on ~100%). But, when I try to play the video, using the 'nvgstplayer' utility, I see that CPU loading is ~46% and all fine. Seems, the QML player loads the SW codecs instead of HW codecs... Is there are any way to say to QML player to use a HW codecs? Or, maybe, I need to fix a sources of QtMM (where I need to change it?) Or, maybe, is there are another way to do this? Otherwise, is just a **HELL** and there is no sense in QML QtMultimedia at all (But I need QML for anumations). And I do not know, how to fix it (I'm not expert in GStreamer). PS: I have tried the 'gst-launch' pipelines instead of 'nvgstplayer', as described here: http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 but it crashes with sigsegv.... BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Tue May 24 17:05:35 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 24 May 2016 17:05:35 +0200 Subject: [Development] QApplication::setWindowIconFromTheme()? Message-ID: <8555878.8D97XiqgWb@portia.local> Hello, I'm seeing lots of cross-platform code that does things like qApp->setWindowIcon(QIcon::fromTheme(QStringLiteral("foo"))) which works fine on platforms where fromTheme() has actual icon themes in its search path. On platforms where the application icon is set statically (OS X, MS Windows) and where applications do not have icon theme seach paths by default, this will more often than not lead to a runtime disposal of the application icon. On OS X, such applications show up with a generic icon in the Dock and app switcher. Would it be possible to discuss the addition of a convenience method as shown below? void QApplication::setWindowIconFromTheme(QString &name) { setWindowIcon(QIcon::fromTheme(name, windowIcon())); } R From thiago.macieira at intel.com Tue May 24 20:21:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 24 May 2016 11:21:58 -0700 Subject: [Development] Qt 5.7.0 change files In-Reply-To: References: Message-ID: <4138355.8VW0fGo4h2@tjmaciei-mobl1> Em terça-feira, 24 de maio de 2016, às 10:50:13 PDT, Jani Heikkinen escreveu: > I and Antti have now done initial change files for every qt submodule (if > not already available). Maintaitainers: Please take those over & modify > files properly and add missing data. We just ran > > Create_changelog.pl ../ v5.6.0...HEAD Do we plan on releasing v5.7.0 before v5.6.1 or not? If so, then the above is fine. If we release v5.6.1 first, please use the 5.6.1 branch on the left of .. > + added some default data there so most probably those need some actions (at > least +2) from you -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andrew.den.exter at qinetic.com.au Wed May 25 03:44:21 2016 From: andrew.den.exter at qinetic.com.au (Andrew den Exter) Date: Wed, 25 May 2016 11:44:21 +1000 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: References: Message-ID: The short answer is some amount of platform adaptation will be required to enable hardware acceleration on your board. Looking at the page you linked to; that adaptation might be achieved by creating an implementation of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes EGL surfaces associated with the x-nv-yuv buffers produced by the accelerated codec. Or you might also need to create your own video node by implementing QSGVideoNodeFactoryPlugin or something more invasive may be required, it really depends on how the vendor implemented their gstreamer plugins The reason hardware acceleration doesn't just work is that hardware vendors have traditionally had to create extensions to gstreamer in order to implement their hardware accelerated plugins, and these extensions tend to require a vendor specific video sink to work. If all you care about is rendering to the full dimensions of a native window then autovideosink will generally resolve to that vendor specific video sink and that's why the standard example command line examples tend to work. But when it comes to something more complicated like compositing into an opengl scene or even as simple as rendering to a sub rect of a window then you're into the realm of vendor extensions and without a port to your specific hardware it probably won't work. Gstreamer 1.0+ goes some way to addressing these issues, but even within the standard packages there still seems to be multiple APIs for codecs which produce EGL surfaces and none of them have been utilized in QtMultimedia yet. Andrew On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov wrote: > Hi all. > > I have the Toradex (Apalis T30) embedded board: > > https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 > > which has: > > http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 > > Linux Image, with the GStreamer 0.10. > > Also I have compiled Qt 5.6 and installed it to the board. > > When I try to play any *.MP4 video file from the QML Video item: > http://doc.qt.io/qt-5/qml-qtmultimedia-video.html > > I see, that my video has very-very lags, and I see (with htop utility) > that CPU loading is ~300% ( > three cores running on ~100%). > > But, when I try to play the video, using the 'nvgstplayer' utility, I see > that CPU loading is ~46% and all fine. Seems, the QML player loads the SW > codecs instead of HW codecs... > > Is there are any way to say to QML player to use a HW codecs? Or, maybe, I > need to fix a sources of QtMM (where I need to change it?) Or, maybe, is > there are another way to do this? > > Otherwise, is just a **HELL** and there is no sense in QML QtMultimedia at > all (But I need QML for anumations). And I do not know, how to fix it (I'm > not expert in GStreamer). > > PS: I have tried the 'gst-launch' pipelines instead of 'nvgstplayer', as > described here: > http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 > but it crashes with sigsegv.... > > BR, > Denis > > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Wed May 25 07:30:40 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 25 May 2016 08:30:40 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: References: Message-ID: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> > Gstreamer 1.0+ goes some way to addressing these issues.... The Apalis T30 board has GPU from the NVidia. So, when I use 'gst-inspect' I see some of 'nv' sinks. So, as I understand, the easy ways to do it are: 1) I should try to use GStreamer 1.0 (instead of 0.10) "as is" with QtMM (rebuild QtMM with this GStreamer), at first stage. 2) I need try to change QtMM sources and try to set the specific vendor-video sinks there, at second stage... (in case the first stage does not work). Is it? BTW: As I remember, I saw some environment variable which allows to setup custom video sink... I need to see sources of QtMM... if I'm not mistaked.. maybe it will help... > but even within the standard packages there still seems to be multiple APIs for codecs which produce EGL surfaces and none of them have been utilized in QtMultimedia yet Could you please provide an examples of this API which is not adopted in QtMM? BR, Denis /// / 25.05.2016 4:44, Andrew den Exter пишет: > The short answer is some amount of platform adaptation will be > required to enable hardware acceleration on your board. Looking at > the page you linked to; that adaptation might be achieved by creating > an implementation of QGstBufferPoolPlugin (gstreamer 0.10 only) which > exposes EGL surfaces associated with the x-nv-yuv buffers produced by > the accelerated codec. Or you might also need to create your own > video node by implementing QSGVideoNodeFactoryPlugin or something more > invasive may be required, it really depends on how the vendor > implemented their gstreamer plugins > > The reason hardware acceleration doesn't just work is that hardware > vendors have traditionally had to create extensions to gstreamer in > order to implement their hardware accelerated plugins, and these > extensions tend to require a vendor specific video sink to work. If > all you care about is rendering to the full dimensions of a native > window then autovideosink will generally resolve to that vendor > specific video sink and that's why the standard example command line > examples tend to work. But when it comes to something more > complicated like compositing into an opengl scene or even as simple as > rendering to a sub rect of a window then you're into the realm of > vendor extensions and without a port to your specific hardware it > probably won't work. Gstreamer 1.0+ goes some way to addressing these > issues, but even within the standard packages there still seems to be > multiple APIs for codecs which produce EGL surfaces and none of them > have been utilized in QtMultimedia yet. > > > Andrew > > > On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov > > wrote: > > Hi all. > > I have the Toradex (Apalis T30) embedded board: > https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 > > which has: > http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 > > Linux Image, with the GStreamer 0.10. > > Also I have compiled Qt 5.6 and installed it to the board. > > When I try to play any *.MP4 video file from the QML Video item: > http://doc.qt.io/qt-5/qml-qtmultimedia-video.html > > I see, that my video has very-very lags, and I see (with htop > utility) that CPU loading is ~300% ( > three cores running on ~100%). > > But, when I try to play the video, using the 'nvgstplayer' > utility, I see that CPU loading is ~46% and all fine. Seems, the > QML player loads the SW codecs instead of HW codecs... > > Is there are any way to say to QML player to use a HW codecs? Or, > maybe, I need to fix a sources of QtMM (where I need to change > it?) Or, maybe, is there are another way to do this? > > Otherwise, is just a **HELL** and there is no sense in QML > QtMultimedia at all (But I need QML for anumations). And I do not > know, how to fix it (I'm not expert in GStreamer). > > PS: I have tried the 'gst-launch' pipelines instead of > 'nvgstplayer', as described here: > http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 > but it crashes with sigsegv.... > > BR, > Denis > > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Wed May 25 13:35:51 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 25 May 2016 14:35:51 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> References: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> Message-ID: > BTW: As I remember, I saw some environment variable which allows to setup custom video sink... I need to see sources of QtMM... if I'm not mistaked.. maybe it will help... I have found this env variables: * QT_GSTREAMER_WIDGET_VIDEOSINK * QT_GSTREAMER_WINDOW_VIDEOSINK and try to use it: $export QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink $export QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink $./my-qml-video-player but, this does not help... BR, Denis 2016-05-25 8:30 GMT+03:00 Denis Shienkov : > > Gstreamer 1.0+ goes some way to addressing these issues.... > > The Apalis T30 board has GPU from the NVidia. So, when I use 'gst-inspect' > I see some of 'nv' sinks. > So, as I understand, the easy ways to do it are: > > 1) I should try to use GStreamer 1.0 (instead of 0.10) "as is" with QtMM > (rebuild QtMM with this GStreamer), at first stage. > > 2) I need try to change QtMM sources and try to set the specific > vendor-video sinks there, at second stage... (in case the first stage does > not work). > > Is it? > > BTW: As I remember, I saw some environment variable which allows to setup > custom video sink... I need to see sources of QtMM... if I'm not mistaked.. > maybe it will help... > > > but even within the standard packages there still seems to be multiple > APIs for codecs which produce EGL surfaces and none of them have been > utilized in QtMultimedia yet > > Could you please provide an examples of this API which is not adopted in > QtMM? > > > > BR, > Denis > > > 25.05.2016 4:44, Andrew den Exter пишет: > > The short answer is some amount of platform adaptation will be required to > enable hardware acceleration on your board. Looking at the page you linked > to; that adaptation might be achieved by creating an implementation > of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes EGL surfaces > associated with the x-nv-yuv buffers produced by the accelerated codec. > Or you might also need to create your own video node by implementing QSGVideoNodeFactoryPlugin or > something more invasive may be required, it really depends on how the > vendor implemented their gstreamer plugins > > The reason hardware acceleration doesn't just work is that hardware > vendors have traditionally had to create extensions to gstreamer in order > to implement their hardware accelerated plugins, and these extensions tend > to require a vendor specific video sink to work. If all you care about is > rendering to the full dimensions of a native window then autovideosink will > generally resolve to that vendor specific video sink and that's why the > standard example command line examples tend to work. But when it comes to > something more complicated like compositing into an opengl scene or even as > simple as rendering to a sub rect of a window then you're into the realm of > vendor extensions and without a port to your specific hardware it probably > won't work. Gstreamer 1.0+ goes some way to addressing these issues, but > even within the standard packages there still seems to be multiple APIs for > codecs which produce EGL surfaces and none of them have been utilized in > QtMultimedia yet. > > > Andrew > > > On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov > wrote: > >> Hi all. >> >> I have the Toradex (Apalis T30) embedded board: >> >> https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 >> >> which has: >> >> http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 >> >> Linux Image, with the GStreamer 0.10. >> >> Also I have compiled Qt 5.6 and installed it to the board. >> >> When I try to play any *.MP4 video file from the QML Video item: >> http://doc.qt.io/qt-5/qml-qtmultimedia-video.html >> >> I see, that my video has very-very lags, and I see (with htop utility) >> that CPU loading is ~300% ( >> three cores running on ~100%). >> >> But, when I try to play the video, using the 'nvgstplayer' utility, I see >> that CPU loading is ~46% and all fine. Seems, the QML player loads the SW >> codecs instead of HW codecs... >> >> Is there are any way to say to QML player to use a HW codecs? Or, maybe, >> I need to fix a sources of QtMM (where I need to change it?) Or, maybe, is >> there are another way to do this? >> >> Otherwise, is just a **HELL** and there is no sense in QML QtMultimedia >> at all (But I need QML for anumations). And I do not know, how to fix it >> (I'm not expert in GStreamer). >> >> PS: I have tried the 'gst-launch' pipelines instead of 'nvgstplayer', as >> described here: >> http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 >> but it crashes with sigsegv.... >> >> BR, >> Denis >> >> >> >> >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Wed May 25 14:07:58 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 25 May 2016 15:07:58 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: References: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> Message-ID: Now, I have recompiled the QtMM plugin (with default gstreamer 0.10), but with adding of debug macro DEBUG_PLAYBIN. Then I got following log: https://paste.kde.org/p6ztesnsq Where I do not see any mentions about the selected gst sinks.. I see only this: {quote} Set video output: QGstreamerVideoRenderer(0x153fe0) Current sink: fakesink0 0x13e590 pending: 0x0 new sink: fakesink0 0x13e590 Video sink has not changed, skip video output reconfiguration Video sink has chaged, reload video output void QGstreamerPlayerSession::setVideoRenderer(QObject*) Set video output: QGstreamerVideoRenderer(0x153fe0) Current sink: fakesink0 0x13e590 pending: 0x0 new sink: qvideosurfacegstsink0 0x1bc470 Reconfigure video output The pipeline has not started yet, pending state: QMediaPlayer::StoppedState Video sink has chaged, reload video output void QGstreamerPlayerSession::setVideoRenderer(QObject*) Set video output: QGstreamerVideoRenderer(0x153fe0) Current sink: qvideosurfacegstsink0 0x1bc470 pending: 0x0 new sink: qvideosurfacegstsink0 0x1bc470 Video sink has not changed, skip video output reconfiguration {quote} what is it 'fakesink', 'qvideosurfacegstsink0' ? where is any of desired: {quote} root at apalis-t30:~/Downloads# gst-inspect | grep sink | grep nv omx: nv_omx_audiosink: OpenMAX IL audiosink element omx: nv_gstbin_videosink: OpenMAX IL videosink element omx: nv_omx_videosink: OpenMAX IL videosink element omx: nv_omx_hdmi_videosink: OpenMAX IL hdmi videosink element omx: nv_omx_overlaysink: OpenMAX IL overlaysink element omx: nv_gl_eglimagesink: OpenMAX IL videosink element nvxvimagesink: nvxvimagesink: Video sink root at apalis-t30:~/Downloads# {quote} sinks? I do not understand nothing.. o_O How I can see the selected sink name? 2016-05-25 14:35 GMT+03:00 Denis Shienkov : > > BTW: As I remember, I saw some environment variable which allows to > setup custom video sink... I need to see sources of QtMM... if I'm not > mistaked.. > maybe it will help... > > I have found this env variables: > > * QT_GSTREAMER_WIDGET_VIDEOSINK > * QT_GSTREAMER_WINDOW_VIDEOSINK > > and try to use it: > > $export QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink > $export QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink > $./my-qml-video-player > > but, this does not help... > > BR, > Denis > > > > 2016-05-25 8:30 GMT+03:00 Denis Shienkov : > >> > Gstreamer 1.0+ goes some way to addressing these issues.... >> >> The Apalis T30 board has GPU from the NVidia. So, when I use >> 'gst-inspect' I see some of 'nv' sinks. >> So, as I understand, the easy ways to do it are: >> >> 1) I should try to use GStreamer 1.0 (instead of 0.10) "as is" with QtMM >> (rebuild QtMM with this GStreamer), at first stage. >> >> 2) I need try to change QtMM sources and try to set the specific >> vendor-video sinks there, at second stage... (in case the first stage does >> not work). >> >> Is it? >> >> BTW: As I remember, I saw some environment variable which allows to setup >> custom video sink... I need to see sources of QtMM... if I'm not mistaked.. >> maybe it will help... >> >> > but even within the standard packages there still seems to be multiple >> APIs for codecs which produce EGL surfaces and none of them have been >> utilized in QtMultimedia yet >> >> Could you please provide an examples of this API which is not adopted in >> QtMM? >> >> >> >> BR, >> Denis >> >> >> 25.05.2016 4:44, Andrew den Exter пишет: >> >> The short answer is some amount of platform adaptation will be required >> to enable hardware acceleration on your board. Looking at the page you >> linked to; that adaptation might be achieved by creating an implementation >> of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes EGL surfaces >> associated with the x-nv-yuv buffers produced by the accelerated codec. >> Or you might also need to create your own video node by implementing QSGVideoNodeFactoryPlugin or >> something more invasive may be required, it really depends on how the >> vendor implemented their gstreamer plugins >> >> The reason hardware acceleration doesn't just work is that hardware >> vendors have traditionally had to create extensions to gstreamer in order >> to implement their hardware accelerated plugins, and these extensions tend >> to require a vendor specific video sink to work. If all you care about is >> rendering to the full dimensions of a native window then autovideosink will >> generally resolve to that vendor specific video sink and that's why the >> standard example command line examples tend to work. But when it comes to >> something more complicated like compositing into an opengl scene or even as >> simple as rendering to a sub rect of a window then you're into the realm of >> vendor extensions and without a port to your specific hardware it probably >> won't work. Gstreamer 1.0+ goes some way to addressing these issues, but >> even within the standard packages there still seems to be multiple APIs for >> codecs which produce EGL surfaces and none of them have been utilized in >> QtMultimedia yet. >> >> >> Andrew >> >> >> On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov < >> denis.shienkov at gmail.com> wrote: >> >>> Hi all. >>> >>> I have the Toradex (Apalis T30) embedded board: >>> >>> https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 >>> >>> which has: >>> >>> http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 >>> >>> Linux Image, with the GStreamer 0.10. >>> >>> Also I have compiled Qt 5.6 and installed it to the board. >>> >>> When I try to play any *.MP4 video file from the QML Video item: >>> http://doc.qt.io/qt-5/qml-qtmultimedia-video.html >>> >>> I see, that my video has very-very lags, and I see (with htop utility) >>> that CPU loading is ~300% ( >>> three cores running on ~100%). >>> >>> But, when I try to play the video, using the 'nvgstplayer' utility, I >>> see that CPU loading is ~46% and all fine. Seems, the QML player loads the >>> SW codecs instead of HW codecs... >>> >>> Is there are any way to say to QML player to use a HW codecs? Or, maybe, >>> I need to fix a sources of QtMM (where I need to change it?) Or, maybe, is >>> there are another way to do this? >>> >>> Otherwise, is just a **HELL** and there is no sense in QML QtMultimedia >>> at all (But I need QML for anumations). And I do not know, how to fix it >>> (I'm not expert in GStreamer). >>> >>> PS: I have tried the 'gst-launch' pipelines instead of 'nvgstplayer', as >>> described here: >>> http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 >>> but it crashes with sigsegv.... >>> >>> BR, >>> Denis >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Wed May 25 15:53:10 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 25 May 2016 16:53:10 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: References: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> Message-ID: The solution from: https://devtalk.nvidia.com/default/topic/894891/jetson-tk1/gstreamer-1-0-and-qt5-video-playback/ with adding the: {code} qDebug() << "Setting videosink to " << videoSinkString; qputenv("QT_GSTREAMER_WINDOW_VIDEOSINK", videoSinkString.toUtf8()); {code} to the main.cpp, where videoSinkString is nv_omx_hdmi_videosink, does not work too... WTF? 2016-05-25 15:07 GMT+03:00 Denis Shienkov : > Now, I have recompiled the QtMM plugin (with default gstreamer 0.10), but > with adding of debug macro DEBUG_PLAYBIN. > Then I got following log: https://paste.kde.org/p6ztesnsq > > Where I do not see any mentions about the selected gst sinks.. I see only > this: > > {quote} > Set video output: QGstreamerVideoRenderer(0x153fe0) > Current sink: fakesink0 0x13e590 pending: 0x0 new sink: fakesink0 0x13e590 > Video sink has not changed, skip video output reconfiguration > Video sink has chaged, reload video output > void QGstreamerPlayerSession::setVideoRenderer(QObject*) > Set video output: QGstreamerVideoRenderer(0x153fe0) > Current sink: fakesink0 0x13e590 pending: 0x0 new sink: > qvideosurfacegstsink0 0x1bc470 > Reconfigure video output > The pipeline has not started yet, pending state: QMediaPlayer::StoppedState > Video sink has chaged, reload video output > void QGstreamerPlayerSession::setVideoRenderer(QObject*) > Set video output: QGstreamerVideoRenderer(0x153fe0) > Current sink: qvideosurfacegstsink0 0x1bc470 pending: 0x0 new sink: > qvideosurfacegstsink0 0x1bc470 > Video sink has not changed, skip video output reconfiguration > {quote} > > what is it 'fakesink', 'qvideosurfacegstsink0' ? where is any of desired: > > {quote} > root at apalis-t30:~/Downloads# gst-inspect | grep sink | grep nv > omx: nv_omx_audiosink: OpenMAX IL audiosink element > omx: nv_gstbin_videosink: OpenMAX IL videosink element > omx: nv_omx_videosink: OpenMAX IL videosink element > omx: nv_omx_hdmi_videosink: OpenMAX IL hdmi videosink element > omx: nv_omx_overlaysink: OpenMAX IL overlaysink element > omx: nv_gl_eglimagesink: OpenMAX IL videosink element > nvxvimagesink: nvxvimagesink: Video sink > root at apalis-t30:~/Downloads# > {quote} > > sinks? I do not understand nothing.. o_O How I can see the selected sink > name? > > > > > 2016-05-25 14:35 GMT+03:00 Denis Shienkov : > >> > BTW: As I remember, I saw some environment variable which allows to >> setup custom video sink... I need to see sources of QtMM... if I'm not >> mistaked.. >> maybe it will help... >> >> I have found this env variables: >> >> * QT_GSTREAMER_WIDGET_VIDEOSINK >> * QT_GSTREAMER_WINDOW_VIDEOSINK >> >> and try to use it: >> >> $export QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink >> $export QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink >> $./my-qml-video-player >> >> but, this does not help... >> >> BR, >> Denis >> >> >> >> 2016-05-25 8:30 GMT+03:00 Denis Shienkov : >> >>> > Gstreamer 1.0+ goes some way to addressing these issues.... >>> >>> The Apalis T30 board has GPU from the NVidia. So, when I use >>> 'gst-inspect' I see some of 'nv' sinks. >>> So, as I understand, the easy ways to do it are: >>> >>> 1) I should try to use GStreamer 1.0 (instead of 0.10) "as is" with QtMM >>> (rebuild QtMM with this GStreamer), at first stage. >>> >>> 2) I need try to change QtMM sources and try to set the specific >>> vendor-video sinks there, at second stage... (in case the first stage does >>> not work). >>> >>> Is it? >>> >>> BTW: As I remember, I saw some environment variable which allows to >>> setup custom video sink... I need to see sources of QtMM... if I'm not >>> mistaked.. >>> maybe it will help... >>> >>> > but even within the standard packages there still seems to be multiple >>> APIs for codecs which produce EGL surfaces and none of them have been >>> utilized in QtMultimedia yet >>> >>> Could you please provide an examples of this API which is not adopted in >>> QtMM? >>> >>> >>> >>> BR, >>> Denis >>> >>> >>> 25.05.2016 4:44, Andrew den Exter пишет: >>> >>> The short answer is some amount of platform adaptation will be required >>> to enable hardware acceleration on your board. Looking at the page you >>> linked to; that adaptation might be achieved by creating an implementation >>> of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes EGL surfaces >>> associated with the x-nv-yuv buffers produced by the accelerated >>> codec. Or you might also need to create your own video node by >>> implementing QSGVideoNodeFactoryPlugin or something more invasive may >>> be required, it really depends on how the vendor implemented their >>> gstreamer plugins >>> >>> The reason hardware acceleration doesn't just work is that hardware >>> vendors have traditionally had to create extensions to gstreamer in order >>> to implement their hardware accelerated plugins, and these extensions tend >>> to require a vendor specific video sink to work. If all you care about is >>> rendering to the full dimensions of a native window then autovideosink will >>> generally resolve to that vendor specific video sink and that's why the >>> standard example command line examples tend to work. But when it comes to >>> something more complicated like compositing into an opengl scene or even as >>> simple as rendering to a sub rect of a window then you're into the realm of >>> vendor extensions and without a port to your specific hardware it probably >>> won't work. Gstreamer 1.0+ goes some way to addressing these issues, but >>> even within the standard packages there still seems to be multiple APIs for >>> codecs which produce EGL surfaces and none of them have been utilized in >>> QtMultimedia yet. >>> >>> >>> Andrew >>> >>> >>> On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov < >>> denis.shienkov at gmail.com> wrote: >>> >>>> Hi all. >>>> >>>> I have the Toradex (Apalis T30) embedded board: >>>> >>>> https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 >>>> >>>> which has: >>>> >>>> http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 >>>> >>>> Linux Image, with the GStreamer 0.10. >>>> >>>> Also I have compiled Qt 5.6 and installed it to the board. >>>> >>>> When I try to play any *.MP4 video file from the QML Video item: >>>> http://doc.qt.io/qt-5/qml-qtmultimedia-video.html >>>> >>>> I see, that my video has very-very lags, and I see (with htop utility) >>>> that CPU loading is ~300% ( >>>> three cores running on ~100%). >>>> >>>> But, when I try to play the video, using the 'nvgstplayer' utility, I >>>> see that CPU loading is ~46% and all fine. Seems, the QML player loads the >>>> SW codecs instead of HW codecs... >>>> >>>> Is there are any way to say to QML player to use a HW codecs? Or, >>>> maybe, I need to fix a sources of QtMM (where I need to change it?) Or, >>>> maybe, is there are another way to do this? >>>> >>>> Otherwise, is just a **HELL** and there is no sense in QML QtMultimedia >>>> at all (But I need QML for anumations). And I do not know, how to fix it >>>> (I'm not expert in GStreamer). >>>> >>>> PS: I have tried the 'gst-launch' pipelines instead of 'nvgstplayer', >>>> as described here: >>>> http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 >>>> but it crashes with sigsegv.... >>>> >>>> BR, >>>> Denis >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at raven-worx.net Wed May 25 16:11:00 2016 From: info at raven-worx.net (raven-worx Software) Date: Wed, 25 May 2016 16:11:00 +0200 Subject: [Development] QtWebkit to vcxproj Message-ID: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> Hi, i am trying to create a vcxproj-Project of the QtWebKit module. For that i call "qmake -tp vc -r" This results in error "Project ERROR: Strict subdir dependencies can only be used with subdirs template" (https://bugreports.qt.io/browse/QTBUG-50099) I can get rid of this error by commenting all lines which call addStrictSubdirOrderBetween() in the affected .pro files. So far so good. I now have a solution which contains and successfully builds most QtWebKit projects. The only projects i still have issues with are WTF, WebCore and JavaScriptCore. WTF ---------------------- Now when i call "qmake -tp vc WTF.pro" it returns without any output and it seems like it finished successfully. But no project is created and it silently fails. Now when i call "qmake -tp vc WTF.pro -o WTF.vcxproj" instead i get several messages like: "qtwebkit/Source/WTF/WTF.pri:16: 'use?' is not a recognized test function" messages WebCore --------------------- calling "qmake -tp vc WebCore.pro -o WebCore.vcxproj" results in: Info: creating cache file C:\Qt\Qt-5.x-git\qtwebkit\Source\WebCore\WebCore.vcxproj\.qmake.cache Running configure tests... Checking for fontconfig... QDir::mkpath: Empty or null file name C:/Qt/Qt-5.x-git/qtbase/mkspecs/features/configure.prf:68: Cannot create directory . Project ERROR: Aborting. So my question is how can i create "Qt-ified" webkit core projects? regards. From denis.shienkov at gmail.com Wed May 25 16:12:17 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 25 May 2016 17:12:17 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: References: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> Message-ID: Now, I have added this output: {code} qDebug() << "*** TEST Best sink name" << elementName << ", m_videoSink:" << m_videoSink; {code} to the ctor of QGStreamerVideoOverlay in file /src/gsttools/qgstreamervideooverlay.cpp, and now I see this output: {quote} root at apalis-t30:~/Downloads# ./video-player welcome.avi QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed Unable to query physical screen size, defaulting to 100 dpi. To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). Setting videosink to "nv_omx_hdmi_videosink" NvxLiteH264DecoderInit : Opening TVMR H264 block NvxLiteH264DecoderInit : Opening TVMR H264 block *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8 *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0 NvMMLiteOpen : Block : BlockType = 260 ++++++ NvAvpOpen +++++++ NvMMLiteBlockCreate : Block : BlockType = 260 ++++++++++++ TVMRFrameDelivery +++++++++++++++ BeginSequence 1920x720 pnvsi->nDecodeBuffers = 3 Display Resolution : (1920x720) Display Aspect Ratio : (1920x720) cbBeginSequence at 433: SurfaceLayout = 2 pStreamInfo->NumOfSurfaces = 7, MaxDPB = 24, InteraceStream = 0, InterlaceEnabled = 0 Allocating new output: 1920x720 (x 9) Warning: "A lot of buffers are being dropped." Warning: "A lot of buffers are being dropped." Warning: "A lot of buffers are being dropped." Warning: "A lot of buffers are being dropped." ^Croot at apalis-t30:~/Downloads# {quote} where are: {quote} *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8 *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0 {quote} BUT: Nothing changes, the CPU loading ~300% as before... So, seems, the problem is *NOT IN VIDEO-SINK* selection... So, now, I am confused.. WTF? WTF? WTF? :( BR, Denis 2016-05-25 16:53 GMT+03:00 Denis Shienkov : > The solution from: > > https://devtalk.nvidia.com/default/topic/894891/jetson-tk1/gstreamer-1-0-and-qt5-video-playback/ > > with adding the: > > {code} > qDebug() << "Setting videosink to " << videoSinkString; > qputenv("QT_GSTREAMER_WINDOW_VIDEOSINK", videoSinkString.toUtf8()); > {code} > > to the main.cpp, where videoSinkString is nv_omx_hdmi_videosink, does not > work too... > > WTF? > > > > 2016-05-25 15:07 GMT+03:00 Denis Shienkov : > >> Now, I have recompiled the QtMM plugin (with default gstreamer 0.10), but >> with adding of debug macro DEBUG_PLAYBIN. >> Then I got following log: https://paste.kde.org/p6ztesnsq >> >> Where I do not see any mentions about the selected gst sinks.. I see only >> this: >> >> {quote} >> Set video output: QGstreamerVideoRenderer(0x153fe0) >> Current sink: fakesink0 0x13e590 pending: 0x0 new sink: fakesink0 >> 0x13e590 >> Video sink has not changed, skip video output reconfiguration >> Video sink has chaged, reload video output >> void QGstreamerPlayerSession::setVideoRenderer(QObject*) >> Set video output: QGstreamerVideoRenderer(0x153fe0) >> Current sink: fakesink0 0x13e590 pending: 0x0 new sink: >> qvideosurfacegstsink0 0x1bc470 >> Reconfigure video output >> The pipeline has not started yet, pending state: >> QMediaPlayer::StoppedState >> Video sink has chaged, reload video output >> void QGstreamerPlayerSession::setVideoRenderer(QObject*) >> Set video output: QGstreamerVideoRenderer(0x153fe0) >> Current sink: qvideosurfacegstsink0 0x1bc470 pending: 0x0 new sink: >> qvideosurfacegstsink0 0x1bc470 >> Video sink has not changed, skip video output reconfiguration >> {quote} >> >> what is it 'fakesink', 'qvideosurfacegstsink0' ? where is any of desired: >> >> {quote} >> root at apalis-t30:~/Downloads# gst-inspect | grep sink | grep nv >> omx: nv_omx_audiosink: OpenMAX IL audiosink element >> omx: nv_gstbin_videosink: OpenMAX IL videosink element >> omx: nv_omx_videosink: OpenMAX IL videosink element >> omx: nv_omx_hdmi_videosink: OpenMAX IL hdmi videosink element >> omx: nv_omx_overlaysink: OpenMAX IL overlaysink element >> omx: nv_gl_eglimagesink: OpenMAX IL videosink element >> nvxvimagesink: nvxvimagesink: Video sink >> root at apalis-t30:~/Downloads# >> {quote} >> >> sinks? I do not understand nothing.. o_O How I can see the selected sink >> name? >> >> >> >> >> 2016-05-25 14:35 GMT+03:00 Denis Shienkov : >> >>> > BTW: As I remember, I saw some environment variable which allows to >>> setup custom video sink... I need to see sources of QtMM... if I'm not >>> mistaked.. >>> maybe it will help... >>> >>> I have found this env variables: >>> >>> * QT_GSTREAMER_WIDGET_VIDEOSINK >>> * QT_GSTREAMER_WINDOW_VIDEOSINK >>> >>> and try to use it: >>> >>> $export QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink >>> $export QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink >>> $./my-qml-video-player >>> >>> but, this does not help... >>> >>> BR, >>> Denis >>> >>> >>> >>> 2016-05-25 8:30 GMT+03:00 Denis Shienkov : >>> >>>> > Gstreamer 1.0+ goes some way to addressing these issues.... >>>> >>>> The Apalis T30 board has GPU from the NVidia. So, when I use >>>> 'gst-inspect' I see some of 'nv' sinks. >>>> So, as I understand, the easy ways to do it are: >>>> >>>> 1) I should try to use GStreamer 1.0 (instead of 0.10) "as is" with >>>> QtMM (rebuild QtMM with this GStreamer), at first stage. >>>> >>>> 2) I need try to change QtMM sources and try to set the specific >>>> vendor-video sinks there, at second stage... (in case the first stage does >>>> not work). >>>> >>>> Is it? >>>> >>>> BTW: As I remember, I saw some environment variable which allows to >>>> setup custom video sink... I need to see sources of QtMM... if I'm not >>>> mistaked.. >>>> maybe it will help... >>>> >>>> > but even within the standard packages there still seems to be >>>> multiple APIs for codecs which produce EGL surfaces and none of them have >>>> been utilized in QtMultimedia yet >>>> >>>> Could you please provide an examples of this API which is not adopted >>>> in QtMM? >>>> >>>> >>>> >>>> BR, >>>> Denis >>>> >>>> >>>> 25.05.2016 4:44, Andrew den Exter пишет: >>>> >>>> The short answer is some amount of platform adaptation will be required >>>> to enable hardware acceleration on your board. Looking at the page you >>>> linked to; that adaptation might be achieved by creating an implementation >>>> of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes EGL surfaces >>>> associated with the x-nv-yuv buffers produced by the accelerated >>>> codec. Or you might also need to create your own video node by >>>> implementing QSGVideoNodeFactoryPlugin or something more invasive may >>>> be required, it really depends on how the vendor implemented their >>>> gstreamer plugins >>>> >>>> The reason hardware acceleration doesn't just work is that hardware >>>> vendors have traditionally had to create extensions to gstreamer in order >>>> to implement their hardware accelerated plugins, and these extensions tend >>>> to require a vendor specific video sink to work. If all you care about is >>>> rendering to the full dimensions of a native window then autovideosink will >>>> generally resolve to that vendor specific video sink and that's why the >>>> standard example command line examples tend to work. But when it comes to >>>> something more complicated like compositing into an opengl scene or even as >>>> simple as rendering to a sub rect of a window then you're into the realm of >>>> vendor extensions and without a port to your specific hardware it probably >>>> won't work. Gstreamer 1.0+ goes some way to addressing these issues, but >>>> even within the standard packages there still seems to be multiple APIs for >>>> codecs which produce EGL surfaces and none of them have been utilized in >>>> QtMultimedia yet. >>>> >>>> >>>> Andrew >>>> >>>> >>>> On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov < >>>> denis.shienkov at gmail.com> wrote: >>>> >>>>> Hi all. >>>>> >>>>> I have the Toradex (Apalis T30) embedded board: >>>>> >>>>> https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 >>>>> >>>>> which has: >>>>> >>>>> http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 >>>>> >>>>> Linux Image, with the GStreamer 0.10. >>>>> >>>>> Also I have compiled Qt 5.6 and installed it to the board. >>>>> >>>>> When I try to play any *.MP4 video file from the QML Video item: >>>>> http://doc.qt.io/qt-5/qml-qtmultimedia-video.html >>>>> >>>>> I see, that my video has very-very lags, and I see (with htop utility) >>>>> that CPU loading is ~300% ( >>>>> three cores running on ~100%). >>>>> >>>>> But, when I try to play the video, using the 'nvgstplayer' utility, I >>>>> see that CPU loading is ~46% and all fine. Seems, the QML player loads the >>>>> SW codecs instead of HW codecs... >>>>> >>>>> Is there are any way to say to QML player to use a HW codecs? Or, >>>>> maybe, I need to fix a sources of QtMM (where I need to change it?) Or, >>>>> maybe, is there are another way to do this? >>>>> >>>>> Otherwise, is just a **HELL** and there is no sense in QML >>>>> QtMultimedia at all (But I need QML for anumations). And I do not know, how >>>>> to fix it (I'm not expert in GStreamer). >>>>> >>>>> PS: I have tried the 'gst-launch' pipelines instead of 'nvgstplayer', >>>>> as described here: >>>>> http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 >>>>> but it crashes with sigsegv.... >>>>> >>>>> BR, >>>>> Denis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Wed May 25 16:15:36 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 25 May 2016 14:15:36 +0000 Subject: [Development] QtWebkit to vcxproj In-Reply-To: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> References: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of raven-worx Software > Sent: Wednesday, May 25, 2016 4:11 PM > To: development at qt-project.org > Subject: [Development] QtWebkit to vcxproj > > Hi, > > i am trying to create a vcxproj-Project of the QtWebKit module. Which begs the question: Why? I'm not claiming it's not possible. But building Qt itself within Visual Studio Is not common, let alone Qt WebKit. Kai From info at raven-worx.net Wed May 25 16:24:30 2016 From: info at raven-worx.net (raven-worx Software) Date: Wed, 25 May 2016 16:24:30 +0200 Subject: [Development] QtWebkit to vcxproj In-Reply-To: References: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> Message-ID: <20160525162430.17874dk4xq33nqn2@login-7.hoststar.at> > Which begs the question: Why? > > I'm not claiming it's not possible. But building Qt itself within > Visual Studio > Is not common, let alone Qt WebKit. > > Kai to integrate it into our "development ecosystem" and use the advantages of Visual Studio environment (visual debugging, central property sheets, central compiler optimizations, etc) A lot of tiny things which add up. From Jake.Petroules at qt.io Wed May 25 20:17:13 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 25 May 2016 18:17:13 +0000 Subject: [Development] Supported platforms for Qt 5.8 Message-ID: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> Hi all, Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and iOS 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per Qt release for the past 3 releases, but after that I think we should slow to dropping one release for each release we add (so, once annually or about once every two Qt minor releases). 10.10 and 8.0 were larger releases that began a new "generation" so I think that gives us a better baseline to start with before slowing to an annual upgrade cycle. -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain.pokrzywka at gmail.com Wed May 25 21:42:31 2016 From: romain.pokrzywka at gmail.com (Romain Pokrzywka) Date: Wed, 25 May 2016 12:42:31 -0700 Subject: [Development] D-Bus minimum version for Qt 5.6 Message-ID: Hi, I'm writing this both as a question to the QtDBus maintainers and as a PSA for people using QtDBus and possibly experiencing instability after upgrading to Qt 5.6. I'm afraid some important piece of information may have been left out for users who are not building their own dbus libraries or running the latest linux distros: that using QtDBus in 5.6.0 or later requires you to use at least dbus 1.8.0 to be stable. I've started experiencing random crashes inside malloc()/free() after upgrading to almost-tip-of 5.6.1 (qtbase hash http://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.6.1&id=adf85c09b46eaf55dab362e17e3b0828fb509750), specifically for processes that are exposing dbus services and objects. These crashes were during normal execution in totally random and seemingly innocent places, like when allocating the QArrayData for a QString (which I could confirm had valid content), or creating a QList node, etc, and complaining that malloc() had detected a memory corruption. But it always occurred either in the QDBusConnectionManager thread, or when processing a dbus method call for one of the exposed objects. I've tried running my processes under valgrind/memcheck, running clang analysis tools, etc., and couldn't find anything wrong with my code or the QtDBus code. All the instability disappeared if I reverted to Qt 5.5 using the same code, and it would also become unreproducible as I tried adding more debugging output or running it under valgrind or gdb. So this was a pretty clear sign of some sort of threading issue or race condition somewhere. I eventually tracked it down to the version of dbus used: our system runs on Ubuntu 12.04 LTS, using the package-provided libdbus which is version 1.4.8. Looking at the documentation about threading support, there's a very clear warning in the docs for dbus_threads_init_default(): Since D-Bus 1.7 it is safe to call this function from any thread, any number of times (but it must be called before any other libdbus API is used). In D-Bus 1.6 or older, this function must be called in the main thread before any other thread starts. As a result, it is not sufficient to call this function in a library or plugin, unless the library or plugin imposes a similar requirement on its callers. ( https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#ga33b6cf3b8f1e41bad5508f84758818a7 ) There's also several threads on the dbus ml archives mentionning that versions under 1.5.10 are completely unsafe to use in a multi-threaded environment, for example: https://lists.freedesktop.org/archives/dbus/2012-May/015126.html So I think the problem with QtDBus in 5.6 is that now all connection handling always happens in a background thread (QDBusConnectionManager), so even if your application runs all in a single thread, there's still going to be multi-threading by QtDBus itself. And to make things worse, QtDBus does exactly what the dbus documentation warns not to do for versions before 1.7: it calls dbus_threads_init_default() in a thread that is not the main thread (it's called at the beginning of the QDBusConnectionManager thread). Note that we've also seen similar crashes with dbus 1.6.18, which is the version that Ubuntu 14.04 ships, even though they're much harder to reproduce. Since then I've added dbus 1.10.8 into our dependencies built from source instead of the using the system one, and so far I haven't experienced instability anymore. So I wonder if anybody else has experienced something similar. Maybe there's something specific to our platform and/or code that makes this more prominent, but in any case it does look like the change of implementation in QtDBus with 5.6 is incompatible with dbus <1.7 according to the dbus docs themselves. Am I correct? If so, I think the bare minimum would be to have this mentionned prominently somewhere in the documentation. I've also noticed that qtbase/configure has a MIN_DBUS_1_VERSION variable that is currently set to 1.2, maybe this should be bumped to 1.8 as well. I'm also curious how widespread this issue could be, especially for embedded platforms where it's less likely that the OS and dependencies get updated often. And given that 12.04 LTS is still supported until 2017 it's not unreasonable to expect customers to still be using it. Thanks for your feedback, Romain Pokrzywka -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed May 25 22:33:11 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 25 May 2016 22:33:11 +0200 Subject: [Development] Move assignment without move constructors In-Reply-To: <4521110.ffJzUDPOJK@tjmaciei-mobl1> References: <492121464019886@web23g.yandex.ru> <57434EA4.2000605@kdab.com> <4521110.ffJzUDPOJK@tjmaciei-mobl1> Message-ID: <201605252233.13712.marc.mutz@kdab.com> On Monday 23 May 2016 22:45:28 Thiago Macieira wrote: > Em segunda-feira, 23 de maio de 2016, às 20:40:36 PDT, Giuseppe D'Angelo > > escreveu: > > Any takers for the task? > > I've already added it for QDateTime: > https://codereview.qt-project.org/159085 > > It's part of the short date time work. I'd really prefer move special member functions to be inline, for performance reasons. If someone now goes in and adds them as out-of-line, we'll've killed inline move ctors until at least Qt 6. Actually, I'd prefer copy ctors to be inline, too, because they're all just QAtomicInt::ref(), and nothing worth hidin, and the compiler has a much better idea of what's going on if it doesn't hit out-of-line functions all the time. But that's something for Qt 6. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Thu May 26 08:32:21 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 26 May 2016 08:32:21 +0200 Subject: [Development] Help needed: Qt 3D Android build issue In-Reply-To: <10768524.8n3z2liUFB@cartman> References: <1581822.graGXO5Myn@titan> <10768524.8n3z2liUFB@cartman> Message-ID: <201605260832.23579.marc.mutz@kdab.com> Hi, In QAtomic, we use compare_exchange_strong with a single memory_order argument. The failure mode is therefore calculated by libctdc++, the relevant code in atomic_base.h has not changed from 4.8.0 to 6.1.0, and appears to do the correct thing. It does use signed bitmasking operations with enums that have values with the high bit set (on 32-bit platforms), so theoretically there can be a miscompile there. A workaround for Qt might be to pass an explicit failure mode, which would avoid aforementioned code in libstdc++. If the failure is reproducible, then someone with access to the configuration could try the attached patch. Thanks, Marc On Monday 23 May 2016 13:54:16 Sean Harmer wrote: > Bump, is anybody able to help here please? > > Thanks, > > Sean > > On Friday 20 May 2016 10:13:51 Sean Harmer wrote: > > Hi, > > > > Trying to submit a simple patch to Qt 3D we are hitting a weird > > compilation error on Android CI configurations. The change is: > > > > https://codereview.qt-project.org/#/c/157592/ > > > > and the compilation errors can be seen in full at: > > > > http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfca > > 8c0 > > 2f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_Open > > GLES > > 2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt. > > gz > > > > but in brief they are: > > > > In file included from /opt/android/ndk/sources/cxx-stl/gnu- > > libstdc++/4.8/include/atomic:41:0, > > > > from > > > > /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45, from > > /home/qt/work/install/include/QtCore/qbasicatomic.h:53, from > > /home/qt/work/install/include/QtCore/qatomic.h:46, from > > /home/qt/work/install/include/QtCore/qglobal.h:1145, from > > ../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43, > > > > from ../../include/Qt3DCore/qt3dcore_global.h:1, > > from > > > > ../../include/Qt3DRender/../../src/render/qt3drender_global.h:43, > > > > from ../../include/Qt3DRender/qt3drender_global.h:1, > > from > > > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/rend > > er/ backend/backendnode_p.h:54, from > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1, > > > > from backend/entity_p.h:55, > > > > from backend/entity.cpp:40: > > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_ba > > se. h: In member function 'virtual void > > Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)': > > /opt/android/ndk/sources/cxx-stl/gnu- > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > model cannot be stronger than success memory model for > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > model cannot be stronger than success memory model for > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > model cannot be stronger than success memory model for > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > model cannot be stronger than success memory model for > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > &__i1, __i2, 0, __m1, __m2); ^ > > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_ba > > se .h: In member function 'virtual void > > Qt3DRender::Render::Entity::initializeFromPeer(const > > QNodeCreatedChangeBasePtr&)': > > /opt/android/ndk/sources/cxx-stl/gnu- > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > model cannot be stronger than success memory model for > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > &__i1, __i2, 0, __m1, __m2); ^ > > > > The patch makes no direct use of atomics, only via QSharedPointer. BogDan > > reports that it builds fine with latest NDK. > > > > Is this a genuine error on our part or some corner case issue with the > > CI's installed NDK? > > > > I'm at a total loss with this one and have no idea how to > > investigate/fix. > > > > Any help would be greatly appreciated. :) > > > > Kind regards, > > > > Sean > > -- > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > > Klarälvdalens Datakonsult AB, a KDAB Group company > > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > > KDAB - Qt Experts - Platform-independent software solutions > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-QAtomic-pass-explicit-failure-mode-to-std-atomic-com.patch Type: text/x-patch Size: 3189 bytes Desc: not available URL: From denis.shienkov at gmail.com Thu May 26 11:01:13 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 26 May 2016 12:01:13 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: References: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> Message-ID: UPD: Seems the problem is ***NOT IN QtMM***.. For example, when I have compiled an usual cpp-based QMediaPlayer example, and to set there: {quote} root at apalis-t30:~/Downloads# export QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink root at apalis-t30:~/Downloads# export QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink {quote} then CPU loas ~50%, I is good! So, seems, the problem is in QML && OpenGL!!! It is very-very sad....:( BR, Denis 2016-05-25 17:12 GMT+03:00 Denis Shienkov : > Now, I have added this output: > > {code} > qDebug() << "*** TEST Best sink name" << elementName << ", m_videoSink:" > << m_videoSink; > {code} > > to the ctor of QGStreamerVideoOverlay in file > /src/gsttools/qgstreamervideooverlay.cpp, > and now I see this output: > > {quote} > root at apalis-t30:~/Downloads# ./video-player welcome.avi > QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open > failed > QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open > failed > Unable to query physical screen size, defaulting to 100 dpi. > To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and > QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). > Setting videosink to "nv_omx_hdmi_videosink" > NvxLiteH264DecoderInit : Opening TVMR H264 block > NvxLiteH264DecoderInit : Opening TVMR H264 block > *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8 > *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0 > NvMMLiteOpen : Block : BlockType = 260 > ++++++ NvAvpOpen +++++++ > NvMMLiteBlockCreate : Block : BlockType = 260 > ++++++++++++ TVMRFrameDelivery +++++++++++++++ > BeginSequence 1920x720 > pnvsi->nDecodeBuffers = 3 > Display Resolution : (1920x720) > Display Aspect Ratio : (1920x720) > cbBeginSequence at 433: SurfaceLayout = 2 > pStreamInfo->NumOfSurfaces = 7, MaxDPB = 24, InteraceStream = 0, > InterlaceEnabled = 0 > Allocating new output: 1920x720 (x 9) > Warning: "A lot of buffers are being dropped." > Warning: "A lot of buffers are being dropped." > Warning: "A lot of buffers are being dropped." > Warning: "A lot of buffers are being dropped." > ^Croot at apalis-t30:~/Downloads# > {quote} > > where are: > > {quote} > *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8 > *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0 > {quote} > > BUT: Nothing changes, the CPU loading ~300% as before... So, seems, the > problem is *NOT IN VIDEO-SINK* selection... > > So, now, I am confused.. WTF? WTF? WTF? :( > > BR, > Denis > > > > 2016-05-25 16:53 GMT+03:00 Denis Shienkov : > >> The solution from: >> >> https://devtalk.nvidia.com/default/topic/894891/jetson-tk1/gstreamer-1-0-and-qt5-video-playback/ >> >> with adding the: >> >> {code} >> qDebug() << "Setting videosink to " << videoSinkString; >> qputenv("QT_GSTREAMER_WINDOW_VIDEOSINK", >> videoSinkString.toUtf8()); >> {code} >> >> to the main.cpp, where videoSinkString is nv_omx_hdmi_videosink, does not >> work too... >> >> WTF? >> >> >> >> 2016-05-25 15:07 GMT+03:00 Denis Shienkov : >> >>> Now, I have recompiled the QtMM plugin (with default gstreamer 0.10), >>> but with adding of debug macro DEBUG_PLAYBIN. >>> Then I got following log: https://paste.kde.org/p6ztesnsq >>> >>> Where I do not see any mentions about the selected gst sinks.. I see >>> only this: >>> >>> {quote} >>> Set video output: QGstreamerVideoRenderer(0x153fe0) >>> Current sink: fakesink0 0x13e590 pending: 0x0 new sink: fakesink0 >>> 0x13e590 >>> Video sink has not changed, skip video output reconfiguration >>> Video sink has chaged, reload video output >>> void QGstreamerPlayerSession::setVideoRenderer(QObject*) >>> Set video output: QGstreamerVideoRenderer(0x153fe0) >>> Current sink: fakesink0 0x13e590 pending: 0x0 new sink: >>> qvideosurfacegstsink0 0x1bc470 >>> Reconfigure video output >>> The pipeline has not started yet, pending state: >>> QMediaPlayer::StoppedState >>> Video sink has chaged, reload video output >>> void QGstreamerPlayerSession::setVideoRenderer(QObject*) >>> Set video output: QGstreamerVideoRenderer(0x153fe0) >>> Current sink: qvideosurfacegstsink0 0x1bc470 pending: 0x0 new sink: >>> qvideosurfacegstsink0 0x1bc470 >>> Video sink has not changed, skip video output reconfiguration >>> {quote} >>> >>> what is it 'fakesink', 'qvideosurfacegstsink0' ? where is any of desired: >>> >>> {quote} >>> root at apalis-t30:~/Downloads# gst-inspect | grep sink | grep nv >>> omx: nv_omx_audiosink: OpenMAX IL audiosink element >>> omx: nv_gstbin_videosink: OpenMAX IL videosink element >>> omx: nv_omx_videosink: OpenMAX IL videosink element >>> omx: nv_omx_hdmi_videosink: OpenMAX IL hdmi videosink element >>> omx: nv_omx_overlaysink: OpenMAX IL overlaysink element >>> omx: nv_gl_eglimagesink: OpenMAX IL videosink element >>> nvxvimagesink: nvxvimagesink: Video sink >>> root at apalis-t30:~/Downloads# >>> {quote} >>> >>> sinks? I do not understand nothing.. o_O How I can see the selected sink >>> name? >>> >>> >>> >>> >>> 2016-05-25 14:35 GMT+03:00 Denis Shienkov : >>> >>>> > BTW: As I remember, I saw some environment variable which allows to >>>> setup custom video sink... I need to see sources of QtMM... if I'm not >>>> mistaked.. >>>> maybe it will help... >>>> >>>> I have found this env variables: >>>> >>>> * QT_GSTREAMER_WIDGET_VIDEOSINK >>>> * QT_GSTREAMER_WINDOW_VIDEOSINK >>>> >>>> and try to use it: >>>> >>>> $export QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink >>>> $export QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink >>>> $./my-qml-video-player >>>> >>>> but, this does not help... >>>> >>>> BR, >>>> Denis >>>> >>>> >>>> >>>> 2016-05-25 8:30 GMT+03:00 Denis Shienkov : >>>> >>>>> > Gstreamer 1.0+ goes some way to addressing these issues.... >>>>> >>>>> The Apalis T30 board has GPU from the NVidia. So, when I use >>>>> 'gst-inspect' I see some of 'nv' sinks. >>>>> So, as I understand, the easy ways to do it are: >>>>> >>>>> 1) I should try to use GStreamer 1.0 (instead of 0.10) "as is" with >>>>> QtMM (rebuild QtMM with this GStreamer), at first stage. >>>>> >>>>> 2) I need try to change QtMM sources and try to set the specific >>>>> vendor-video sinks there, at second stage... (in case the first stage does >>>>> not work). >>>>> >>>>> Is it? >>>>> >>>>> BTW: As I remember, I saw some environment variable which allows to >>>>> setup custom video sink... I need to see sources of QtMM... if I'm not >>>>> mistaked.. >>>>> maybe it will help... >>>>> >>>>> > but even within the standard packages there still seems to be >>>>> multiple APIs for codecs which produce EGL surfaces and none of them have >>>>> been utilized in QtMultimedia yet >>>>> >>>>> Could you please provide an examples of this API which is not adopted >>>>> in QtMM? >>>>> >>>>> >>>>> >>>>> BR, >>>>> Denis >>>>> >>>>> >>>>> 25.05.2016 4:44, Andrew den Exter пишет: >>>>> >>>>> The short answer is some amount of platform adaptation will be >>>>> required to enable hardware acceleration on your board. Looking at the >>>>> page you linked to; that adaptation might be achieved by creating an >>>>> implementation of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes >>>>> EGL surfaces associated with the x-nv-yuv buffers produced by the >>>>> accelerated codec. Or you might also need to create your own video node by >>>>> implementing QSGVideoNodeFactoryPlugin or something more invasive may >>>>> be required, it really depends on how the vendor implemented their >>>>> gstreamer plugins >>>>> >>>>> The reason hardware acceleration doesn't just work is that hardware >>>>> vendors have traditionally had to create extensions to gstreamer in order >>>>> to implement their hardware accelerated plugins, and these extensions tend >>>>> to require a vendor specific video sink to work. If all you care about is >>>>> rendering to the full dimensions of a native window then autovideosink will >>>>> generally resolve to that vendor specific video sink and that's why the >>>>> standard example command line examples tend to work. But when it comes to >>>>> something more complicated like compositing into an opengl scene or even as >>>>> simple as rendering to a sub rect of a window then you're into the realm of >>>>> vendor extensions and without a port to your specific hardware it probably >>>>> won't work. Gstreamer 1.0+ goes some way to addressing these issues, but >>>>> even within the standard packages there still seems to be multiple APIs for >>>>> codecs which produce EGL surfaces and none of them have been utilized in >>>>> QtMultimedia yet. >>>>> >>>>> >>>>> Andrew >>>>> >>>>> >>>>> On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov < >>>>> denis.shienkov at gmail.com> wrote: >>>>> >>>>>> Hi all. >>>>>> >>>>>> I have the Toradex (Apalis T30) embedded board: >>>>>> >>>>>> https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 >>>>>> >>>>>> which has: >>>>>> >>>>>> http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 >>>>>> >>>>>> Linux Image, with the GStreamer 0.10. >>>>>> >>>>>> Also I have compiled Qt 5.6 and installed it to the board. >>>>>> >>>>>> When I try to play any *.MP4 video file from the QML Video item: >>>>>> http://doc.qt.io/qt-5/qml-qtmultimedia-video.html >>>>>> >>>>>> I see, that my video has very-very lags, and I see (with htop >>>>>> utility) that CPU loading is ~300% ( >>>>>> three cores running on ~100%). >>>>>> >>>>>> But, when I try to play the video, using the 'nvgstplayer' utility, I >>>>>> see that CPU loading is ~46% and all fine. Seems, the QML player loads the >>>>>> SW codecs instead of HW codecs... >>>>>> >>>>>> Is there are any way to say to QML player to use a HW codecs? Or, >>>>>> maybe, I need to fix a sources of QtMM (where I need to change it?) Or, >>>>>> maybe, is there are another way to do this? >>>>>> >>>>>> Otherwise, is just a **HELL** and there is no sense in QML >>>>>> QtMultimedia at all (But I need QML for anumations). And I do not know, how >>>>>> to fix it (I'm not expert in GStreamer). >>>>>> >>>>>> PS: I have tried the 'gst-launch' pipelines instead of 'nvgstplayer', >>>>>> as described here: >>>>>> http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 >>>>>> but it crashes with sigsegv.... >>>>>> >>>>>> BR, >>>>>> Denis >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Thu May 26 11:39:33 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 26 May 2016 09:39:33 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> References: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> Message-ID: Sounds good to me in principle, especially since we very likely have again next generation of both iOS and OS X to support in Qt 5.8. Especially in iOS users tend to upgrade to new versions quite quickly (and then see if their devices still can run that or not). Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jake Petroules Sent: keskiviikkona 25. toukokuuta 2016 21.17 To: development at qt-project.org Subject: [Development] Supported platforms for Qt 5.8 Hi all, Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and iOS 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per Qt release for the past 3 releases, but after that I think we should slow to dropping one release for each release we add (so, once annually or about once every two Qt minor releases). 10.10 and 8.0 were larger releases that began a new "generation" so I think that gives us a better baseline to start with before slowing to an annual upgrade cycle. -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Thu May 26 11:39:42 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 26 May 2016 11:39:42 +0200 Subject: [Development] Qt 5.7.0 change files In-Reply-To: <4138355.8VW0fGo4h2@tjmaciei-mobl1> References: <4138355.8VW0fGo4h2@tjmaciei-mobl1> Message-ID: <20160526093942.GC19180@troll08.it.local> On Tue, May 24, 2016 at 11:21:58AM -0700, Thiago Macieira wrote: > Em terça-feira, 24 de maio de 2016, às 10:50:13 PDT, Jani Heikkinen escreveu: > > I and Antti have now done initial change files for every qt submodule (if > > not already available). Maintaitainers: Please take those over & modify > > files properly and add missing data. We just ran > > > > Create_changelog.pl ../ v5.6.0...HEAD > > Do we plan on releasing v5.7.0 before v5.6.1 or not? > > If so, then the above is fine. If we release v5.6.1 first, please use the 5.6.1 > branch on the left of .. > no, 5.6.1 has lower priority. anyway, this raises an interesting question about the 5.6.2 and 5.7.1 (and later) changelogs. we won't get around duplicating content unless we actually sync up releases, which is unrealistic for resource reasons. > > + added some default data there so most probably those need some actions (at > > least +2) from you > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Thu May 26 11:42:15 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 26 May 2016 09:42:15 +0000 Subject: [Development] Qt 5.7.0 change files In-Reply-To: <4138355.8VW0fGo4h2@tjmaciei-mobl1> References: <4138355.8VW0fGo4h2@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Sent: tiistaina 24. toukokuuta 2016 21.22 > To: development at qt-project.org > Subject: Re: [Development] Qt 5.7.0 change files > > Em terça-feira, 24 de maio de 2016, às 10:50:13 PDT, Jani Heikkinen escreveu: > > I and Antti have now done initial change files for every qt submodule > > (if not already available). Maintaitainers: Please take those over & > > modify files properly and add missing data. We just ran > > > > Create_changelog.pl ../ v5.6.0...HEAD > > Do we plan on releasing v5.7.0 before v5.6.1 or not? > > If so, then the above is fine. If we release v5.6.1 first, please use the 5.6.1 > branch on the left of .. > If all goes well Qt 5.6.1 should come out before Qt 5.7.0 final. -- Tuukka > > + added some default data there so most probably those need some > > + actions (at > > least +2) from you > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tomek.bury at gmail.com Thu May 26 11:45:16 2016 From: tomek.bury at gmail.com (Tomek Bury) Date: Thu, 26 May 2016 09:45:16 +0000 Subject: [Development] QtWayland synchronisation between GL and compositor Message-ID: Hi all, Is there any mechanism that that synchronises wl_buffer release by the compositor to the GL driver's pipeline? I can't figure out how this synchronisation is supposed to work. My initial thought was that the sequence of actions will be something like this. The client sends a new frame to the compositor, in response the compositor would: * create EGL image from wl_buffer * create GL texture from the EGL image * draw client's buffer somewhere * CREATE SYNC OBJECT * destroy texture * destry image * swap buffers and perhaps in a different thread: * WAIT ON SYNC OBJECT * release wl_buffer back to the client But I can't see any sync objects created or waited on. Simply depending on eglSwapBuffers() can't work, especially for a tripple-buffered compositor. Let's say GL driver uses buffers called A, B and C in the compositor process. Buffer A is visible now, B is already finished in terms of GL API calls and the compositor has just finished issuing draw commands to buffer C and calls eglSwapBuffers(). In response the GL/EGL driver has to wait until hardware completes all drawing associated with buffer B, hide A ,show B and start using A as a new back buffer. Buffer C can still be in the making. Releasing client's wl_buffer only because eglSwapBuffers() was called by the compositor will create a race between compositor's GL driver completing frame C in a background and client's GL driver reusing it's buffer. What am I missing? Cheers, Tomek -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Thu May 26 11:46:38 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 26 May 2016 11:46:38 +0200 Subject: [Development] QtWebkit to vcxproj In-Reply-To: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> References: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> Message-ID: <20160526094638.GD19180@troll08.it.local> On Wed, May 25, 2016 at 04:11:00PM +0200, raven-worx Software wrote: > i am trying to create a vcxproj-Project of the QtWebKit module. > there is no hope whatsoever to get that working. note that vcxproj support for the build of qt as a whole has been dropped a while ago, which is reflected by incomplete projects being generated. you may be able to use them successfully for debugging, but there is no way to use them for actually building qt reliably. From denis.shienkov at gmail.com Thu May 26 11:58:10 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 26 May 2016 12:58:10 +0300 Subject: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux? In-Reply-To: References: <17463c34-0601-9e05-7cce-2276b4f21655@gmail.com> Message-ID: I have created a BUG: https://bugreports.qt.io/browse/QTBUG-53646 2016-05-26 12:01 GMT+03:00 Denis Shienkov : > UPD: Seems the problem is ***NOT IN QtMM***.. > > For example, when I have compiled an usual cpp-based QMediaPlayer example, > and to set there: > > {quote} > root at apalis-t30:~/Downloads# export > QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink > root at apalis-t30:~/Downloads# export > QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink > {quote} > > then CPU loas ~50%, I is good! > > So, seems, the problem is in QML && OpenGL!!! It is very-very sad....:( > > BR, > Denis > > > 2016-05-25 17:12 GMT+03:00 Denis Shienkov : > >> Now, I have added this output: >> >> {code} >> qDebug() << "*** TEST Best sink name" << elementName << ", m_videoSink:" >> << m_videoSink; >> {code} >> >> to the ctor of QGStreamerVideoOverlay in file >> /src/gsttools/qgstreamervideooverlay.cpp, >> and now I see this output: >> >> {quote} >> root at apalis-t30:~/Downloads# ./video-player welcome.avi >> QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open >> failed >> QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open >> failed >> Unable to query physical screen size, defaulting to 100 dpi. >> To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and >> QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). >> Setting videosink to "nv_omx_hdmi_videosink" >> NvxLiteH264DecoderInit : Opening TVMR H264 block >> NvxLiteH264DecoderInit : Opening TVMR H264 block >> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8 >> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0 >> NvMMLiteOpen : Block : BlockType = 260 >> ++++++ NvAvpOpen +++++++ >> NvMMLiteBlockCreate : Block : BlockType = 260 >> ++++++++++++ TVMRFrameDelivery +++++++++++++++ >> BeginSequence 1920x720 >> pnvsi->nDecodeBuffers = 3 >> Display Resolution : (1920x720) >> Display Aspect Ratio : (1920x720) >> cbBeginSequence at 433: SurfaceLayout = 2 >> pStreamInfo->NumOfSurfaces = 7, MaxDPB = 24, InteraceStream = 0, >> InterlaceEnabled = 0 >> Allocating new output: 1920x720 (x 9) >> Warning: "A lot of buffers are being dropped." >> Warning: "A lot of buffers are being dropped." >> Warning: "A lot of buffers are being dropped." >> Warning: "A lot of buffers are being dropped." >> ^Croot at apalis-t30:~/Downloads# >> {quote} >> >> where are: >> >> {quote} >> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8 >> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0 >> {quote} >> >> BUT: Nothing changes, the CPU loading ~300% as before... So, seems, the >> problem is *NOT IN VIDEO-SINK* selection... >> >> So, now, I am confused.. WTF? WTF? WTF? :( >> >> BR, >> Denis >> >> >> >> 2016-05-25 16:53 GMT+03:00 Denis Shienkov : >> >>> The solution from: >>> >>> https://devtalk.nvidia.com/default/topic/894891/jetson-tk1/gstreamer-1-0-and-qt5-video-playback/ >>> >>> with adding the: >>> >>> {code} >>> qDebug() << "Setting videosink to " << videoSinkString; >>> qputenv("QT_GSTREAMER_WINDOW_VIDEOSINK", >>> videoSinkString.toUtf8()); >>> {code} >>> >>> to the main.cpp, where videoSinkString is nv_omx_hdmi_videosink, does >>> not work too... >>> >>> WTF? >>> >>> >>> >>> 2016-05-25 15:07 GMT+03:00 Denis Shienkov : >>> >>>> Now, I have recompiled the QtMM plugin (with default gstreamer 0.10), >>>> but with adding of debug macro DEBUG_PLAYBIN. >>>> Then I got following log: https://paste.kde.org/p6ztesnsq >>>> >>>> Where I do not see any mentions about the selected gst sinks.. I see >>>> only this: >>>> >>>> {quote} >>>> Set video output: QGstreamerVideoRenderer(0x153fe0) >>>> Current sink: fakesink0 0x13e590 pending: 0x0 new sink: fakesink0 >>>> 0x13e590 >>>> Video sink has not changed, skip video output reconfiguration >>>> Video sink has chaged, reload video output >>>> void QGstreamerPlayerSession::setVideoRenderer(QObject*) >>>> Set video output: QGstreamerVideoRenderer(0x153fe0) >>>> Current sink: fakesink0 0x13e590 pending: 0x0 new sink: >>>> qvideosurfacegstsink0 0x1bc470 >>>> Reconfigure video output >>>> The pipeline has not started yet, pending state: >>>> QMediaPlayer::StoppedState >>>> Video sink has chaged, reload video output >>>> void QGstreamerPlayerSession::setVideoRenderer(QObject*) >>>> Set video output: QGstreamerVideoRenderer(0x153fe0) >>>> Current sink: qvideosurfacegstsink0 0x1bc470 pending: 0x0 new sink: >>>> qvideosurfacegstsink0 0x1bc470 >>>> Video sink has not changed, skip video output reconfiguration >>>> {quote} >>>> >>>> what is it 'fakesink', 'qvideosurfacegstsink0' ? where is any of >>>> desired: >>>> >>>> {quote} >>>> root at apalis-t30:~/Downloads# gst-inspect | grep sink | grep nv >>>> omx: nv_omx_audiosink: OpenMAX IL audiosink element >>>> omx: nv_gstbin_videosink: OpenMAX IL videosink element >>>> omx: nv_omx_videosink: OpenMAX IL videosink element >>>> omx: nv_omx_hdmi_videosink: OpenMAX IL hdmi videosink element >>>> omx: nv_omx_overlaysink: OpenMAX IL overlaysink element >>>> omx: nv_gl_eglimagesink: OpenMAX IL videosink element >>>> nvxvimagesink: nvxvimagesink: Video sink >>>> root at apalis-t30:~/Downloads# >>>> {quote} >>>> >>>> sinks? I do not understand nothing.. o_O How I can see the selected >>>> sink name? >>>> >>>> >>>> >>>> >>>> 2016-05-25 14:35 GMT+03:00 Denis Shienkov : >>>> >>>>> > BTW: As I remember, I saw some environment variable which allows to >>>>> setup custom video sink... I need to see sources of QtMM... if I'm not >>>>> mistaked.. >>>>> maybe it will help... >>>>> >>>>> I have found this env variables: >>>>> >>>>> * QT_GSTREAMER_WIDGET_VIDEOSINK >>>>> * QT_GSTREAMER_WINDOW_VIDEOSINK >>>>> >>>>> and try to use it: >>>>> >>>>> $export QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink >>>>> $export QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink >>>>> $./my-qml-video-player >>>>> >>>>> but, this does not help... >>>>> >>>>> BR, >>>>> Denis >>>>> >>>>> >>>>> >>>>> 2016-05-25 8:30 GMT+03:00 Denis Shienkov : >>>>> >>>>>> > Gstreamer 1.0+ goes some way to addressing these issues.... >>>>>> >>>>>> The Apalis T30 board has GPU from the NVidia. So, when I use >>>>>> 'gst-inspect' I see some of 'nv' sinks. >>>>>> So, as I understand, the easy ways to do it are: >>>>>> >>>>>> 1) I should try to use GStreamer 1.0 (instead of 0.10) "as is" with >>>>>> QtMM (rebuild QtMM with this GStreamer), at first stage. >>>>>> >>>>>> 2) I need try to change QtMM sources and try to set the specific >>>>>> vendor-video sinks there, at second stage... (in case the first stage does >>>>>> not work). >>>>>> >>>>>> Is it? >>>>>> >>>>>> BTW: As I remember, I saw some environment variable which allows to >>>>>> setup custom video sink... I need to see sources of QtMM... if I'm not >>>>>> mistaked.. >>>>>> maybe it will help... >>>>>> >>>>>> > but even within the standard packages there still seems to be >>>>>> multiple APIs for codecs which produce EGL surfaces and none of them have >>>>>> been utilized in QtMultimedia yet >>>>>> >>>>>> Could you please provide an examples of this API which is not adopted >>>>>> in QtMM? >>>>>> >>>>>> >>>>>> >>>>>> BR, >>>>>> Denis >>>>>> >>>>>> >>>>>> 25.05.2016 4:44, Andrew den Exter пишет: >>>>>> >>>>>> The short answer is some amount of platform adaptation will be >>>>>> required to enable hardware acceleration on your board. Looking at the >>>>>> page you linked to; that adaptation might be achieved by creating an >>>>>> implementation of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes >>>>>> EGL surfaces associated with the x-nv-yuv buffers produced by the >>>>>> accelerated codec. Or you might also need to create your own video node by >>>>>> implementing QSGVideoNodeFactoryPlugin or something more invasive >>>>>> may be required, it really depends on how the vendor implemented their >>>>>> gstreamer plugins >>>>>> >>>>>> The reason hardware acceleration doesn't just work is that hardware >>>>>> vendors have traditionally had to create extensions to gstreamer in order >>>>>> to implement their hardware accelerated plugins, and these extensions tend >>>>>> to require a vendor specific video sink to work. If all you care about is >>>>>> rendering to the full dimensions of a native window then autovideosink will >>>>>> generally resolve to that vendor specific video sink and that's why the >>>>>> standard example command line examples tend to work. But when it comes to >>>>>> something more complicated like compositing into an opengl scene or even as >>>>>> simple as rendering to a sub rect of a window then you're into the realm of >>>>>> vendor extensions and without a port to your specific hardware it probably >>>>>> won't work. Gstreamer 1.0+ goes some way to addressing these issues, but >>>>>> even within the standard packages there still seems to be multiple APIs for >>>>>> codecs which produce EGL surfaces and none of them have been utilized in >>>>>> QtMultimedia yet. >>>>>> >>>>>> >>>>>> Andrew >>>>>> >>>>>> >>>>>> On Wed, May 25, 2016 at 12:40 AM, Denis Shienkov < >>>>>> denis.shienkov at gmail.com> wrote: >>>>>> >>>>>>> Hi all. >>>>>>> >>>>>>> I have the Toradex (Apalis T30) embedded board: >>>>>>> >>>>>>> https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3 >>>>>>> >>>>>>> which has: >>>>>>> >>>>>>> http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_T30_LinuxImageV2.6Beta1_20160331.tar.bz2 >>>>>>> >>>>>>> Linux Image, with the GStreamer 0.10. >>>>>>> >>>>>>> Also I have compiled Qt 5.6 and installed it to the board. >>>>>>> >>>>>>> When I try to play any *.MP4 video file from the QML Video item: >>>>>>> http://doc.qt.io/qt-5/qml-qtmultimedia-video.html >>>>>>> >>>>>>> I see, that my video has very-very lags, and I see (with htop >>>>>>> utility) that CPU loading is ~300% ( >>>>>>> three cores running on ~100%). >>>>>>> >>>>>>> But, when I try to play the video, using the 'nvgstplayer' utility, >>>>>>> I see that CPU loading is ~46% and all fine. Seems, the QML player loads >>>>>>> the SW codecs instead of HW codecs... >>>>>>> >>>>>>> Is there are any way to say to QML player to use a HW codecs? Or, >>>>>>> maybe, I need to fix a sources of QtMM (where I need to change it?) Or, >>>>>>> maybe, is there are another way to do this? >>>>>>> >>>>>>> Otherwise, is just a **HELL** and there is no sense in QML >>>>>>> QtMultimedia at all (But I need QML for anumations). And I do not know, how >>>>>>> to fix it (I'm not expert in GStreamer). >>>>>>> >>>>>>> PS: I have tried the 'gst-launch' pipelines instead of >>>>>>> 'nvgstplayer', as described here: >>>>>>> >>>>>>> http://developer.toradex.com/knowledge-base/video-playback-%28linux%29 >>>>>>> but it crashes with sigsegv.... >>>>>>> >>>>>>> BR, >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Development mailing list >>>>>>> Development at qt-project.org >>>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at sletta.org Thu May 26 12:39:32 2016 From: gunnar at sletta.org (Gunnar Sletta) Date: Thu, 26 May 2016 12:39:32 +0200 Subject: [Development] QtWayland synchronisation between GL and compositor In-Reply-To: References: Message-ID: <4FBD3D5D-89FD-4FF1-AA23-E726D1B1D082@sletta.org> Hi Tomek, You're not really missing anything :) In the case of an asynchronous swapBuffers, there is a slight chance the wl_buffer release on the next draw pass will be premature, because there is nothing the qtwayland module that catches when the GPU is done with a frame. In stack that I'm familiar with, the Sailfish OS compositor, we've tackled this either by making sure the GPU completes the copy into its framebuffer during swap (which is the case for the Jolla Phone), or by sitting on the buffer until the GPU is actually done with it and only sending wl_release back to the client once the GPU is actually done (which is the case for the cancelled Jolla Tablet). If the compositor is a QtQuick compositor running on the render thread, sitting on the wl_release for that extra time make for an especially fun coding exercise :) On the client side, the EGL library will make sure that the client is blocked when rendering kicks in (some time after the first GL draw call, but typically during the client's eglSwapBuffers) if there are no wl_buffers available for rendering, so there is no writes to buffers currently in use on the compositor side there. cheers, Gunnar > On 26 May 2016, at 11:45, Tomek Bury wrote: > > Hi all, > > Is there any mechanism that that synchronises wl_buffer release by the compositor to the GL driver's pipeline? > > I can't figure out how this synchronisation is supposed to work. My initial thought was that the sequence of actions will be something like this. The client sends a new frame to the compositor, in response the compositor would: > > * create EGL image from wl_buffer > * create GL texture from the EGL image > * draw client's buffer somewhere > * CREATE SYNC OBJECT > * destroy texture > * destry image > * swap buffers > > and perhaps in a different thread: > * WAIT ON SYNC OBJECT > * release wl_buffer back to the client > > But I can't see any sync objects created or waited on. > > Simply depending on eglSwapBuffers() can't work, especially for a tripple-buffered compositor. Let's say GL driver uses buffers called A, B and C in the compositor process. Buffer A is visible now, B is already finished in terms of GL API calls and the compositor has just finished issuing draw commands to buffer C and calls eglSwapBuffers(). In response the GL/EGL driver has to wait until hardware completes all drawing associated with buffer B, hide A ,show B and start using A as a new back buffer. Buffer C can still be in the making. > > Releasing client's wl_buffer only because eglSwapBuffers() was called by the compositor will create a race between compositor's GL driver completing frame C in a background and client's GL driver reusing it's buffer. What am I missing? > > Cheers, > Tomek > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From sean.harmer at kdab.com Thu May 26 14:00:44 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 26 May 2016 13:00:44 +0100 Subject: [Development] Help needed: Qt 3D Android build issue In-Reply-To: <201605260832.23579.marc.mutz@kdab.com> References: <1581822.graGXO5Myn@titan> <10768524.8n3z2liUFB@cartman> <201605260832.23579.marc.mutz@kdab.com> Message-ID: <2089571.91Rdrn5KjH@cartman> Hi Marc, On Thursday 26 May 2016 08:32:21 Marc Mutz wrote: > Hi, > > In QAtomic, we use compare_exchange_strong with a single memory_order > argument. The failure mode is therefore calculated by libctdc++, the > relevant code in atomic_base.h has not changed from 4.8.0 to 6.1.0, and > appears to do the correct thing. It does use signed bitmasking operations > with enums that have values with the high bit set (on 32-bit platforms), so > theoretically there can be a miscompile there. > > A workaround for Qt might be to pass an explicit failure mode, which would > avoid aforementioned code in libstdc++. > > If the failure is reproducible, then someone with access to the > configuration could try the attached patch. Thanks for the patch. The issue was worked around by upgrading the Android CI nodes to use gcc 4.9 rather than 4.8. If anybody else if using 4.8 then they can try this patch. Cheers, Sean > > Thanks, > Marc > > On Monday 23 May 2016 13:54:16 Sean Harmer wrote: > > Bump, is anybody able to help here please? > > > > Thanks, > > > > Sean > > > > On Friday 20 May 2016 10:13:51 Sean Harmer wrote: > > > Hi, > > > > > > Trying to submit a simple patch to Qt 3D we are hitting a weird > > > compilation error on Android CI configurations. The change is: > > > > > > https://codereview.qt-project.org/#/c/157592/ > > > > > > and the compilation errors can be seen in full at: > > > > > > http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfc > > > a > > > 8c0 > > > 2f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_Open > > > GLES > > > 2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt. > > > gz > > > > > > but in brief they are: > > > > > > In file included from /opt/android/ndk/sources/cxx-stl/gnu- > > > libstdc++/4.8/include/atomic:41:0, > > > > > > from > > > > > > /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45, from > > > /home/qt/work/install/include/QtCore/qbasicatomic.h:53, from > > > /home/qt/work/install/include/QtCore/qatomic.h:46, from > > > /home/qt/work/install/include/QtCore/qglobal.h:1145, from > > > ../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43, > > > > > > from ../../include/Qt3DCore/qt3dcore_global.h:1, > > > from > > > > > > ../../include/Qt3DRender/../../src/render/qt3drender_global.h:43, > > > > > > from ../../include/Qt3DRender/qt3drender_global.h:1, > > > from > > > > > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/ren > > > d > > > er/ backend/backendnode_p.h:54, from > > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1, > > > > > > from backend/entity_p.h:55, > > > > > > from backend/entity.cpp:40: > > > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_b > > > a > > > se. h: In member function 'virtual void > > > Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)': > > > /opt/android/ndk/sources/cxx-stl/gnu- > > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > > model cannot be stronger than success memory model for > > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > > model cannot be stronger than success memory model for > > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > > model cannot be stronger than success memory model for > > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu- > > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > > model cannot be stronger than success memory model for > > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > > &__i1, __i2, 0, __m1, __m2); ^ > > > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_b > > > a > > > se .h: In member function 'virtual void > > > Qt3DRender::Render::Entity::initializeFromPeer(const > > > QNodeCreatedChangeBasePtr&)': > > > /opt/android/ndk/sources/cxx-stl/gnu- > > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory > > > model cannot be stronger than success memory model for > > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i, > > > &__i1, __i2, 0, __m1, __m2); ^ > > > > > > The patch makes no direct use of atomics, only via QSharedPointer. > > > BogDan > > > reports that it builds fine with latest NDK. > > > > > > Is this a genuine error on our part or some corner case issue with the > > > CI's installed NDK? > > > > > > I'm at a total loss with this one and have no idea how to > > > investigate/fix. > > > > > > Any help would be greatly appreciated. :) > > > > > > Kind regards, > > > > > > Sean > > > -- > > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > > > Klarälvdalens Datakonsult AB, a KDAB Group company > > > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > > > KDAB - Qt Experts - Platform-independent software solutions > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From thiago.macieira at intel.com Thu May 26 18:44:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 26 May 2016 09:44:00 -0700 Subject: [Development] Should the system proxies default setting be switched to true? In-Reply-To: References: Message-ID: <2174963.DZVZcuxqxV@tjmaciei-mobl1> See https://bugreports.qt.io/browse/QTBUG-53649 Em sexta-feira, 13 de maio de 2016, às 09:11:35 PDT, Andy Shaw escreveu: > Since there does not seem to be any general objections, I have submitted a > patch for this - https://codereview.qt-project.org/159120 - this is for > 5.8. If anyone does see an issue then please say so in the comments, I will > give it a bit of time before merging once it gets its +2 in order to give > it a chance to be tried out in case someone hits a problem. > > Andy > ________________________________________ > Fra: Simon Hausmann > Sendt: 12. mai 2016 10:01:35 > Til: Andy Shaw; Kai Koehne; development at qt-project.org > Emne: Re: [Development] Should the system proxies default setting be > switched to true? > > Right, it begs the question: If a third-party application like Chrome can > use system proxy settings by default, why can't or don't we? :) > > > Simon > ________________________________________ > From: Development > on behalf of Andy Shaw Sent: Thursday, May 12, 2016 > 9:54:41 AM > To: Kai Koehne; development at qt-project.org > Subject: Re: [Development] Should the system proxies default setting be > switched to true? > > There is an issue but this comes from the Windows side and is also > documented by Microsoft as being a problem I believe on their side. But > this should only be experienced the first time it needs to do this though, > whereas before it would do this all the time. However, I would personally > expect that if this is happening for a user, it will not be happening for > just Qt either. > > Andy > ________________________________________ > Fra: Kai Koehne > Sendt: 12. mai 2016 08:41:21 > Til: Andy Shaw; development at qt-project.org > Emne: RE: [Development] Should the system proxies default setting be > switched to true? > > +1 for switching to using the system proxy settings by default. > > I'm still a bit wary about the 'Windows issue' though. To cite our > documentation [1]: > > "On Windows platforms, this function may take several seconds to execute > depending on the configuration of the user's system." > > Was that the problem with Windows versions configured for automatically > querying for PAC files, but never getting any response? > > Regards > > Kai > > [1]: http://doc.qt.io/qt-5/qnetworkproxyfactory.html#systemProxyForQuery > > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Andy Shaw > > Sent: Wednesday, May 11, 2016 3:51 PM > > To: development at qt-project.org > > Subject: [Development] Should the system proxies default setting be > > switched to true? > > > > For some time now we have had the means to configure Qt to use system > > proxies so that they are on by default or to turn it on via > > QNetworkProxyFactory. However, this is off by default so it is becoming a > > reoccurrence that people don't realise that it is not using the system > > proxies until later on. Potentially not until after a product has been > > released. > > > > > > The reasoning that this was not done before was due to the fact that there > > was a problem on Windows with it taking too long in some cases to get the > > information. However this seems to be solved for the most part and > > expected in some cases due to the fact that it is down to the system, but > > it is just an initial start up check in this case. > > > > > > That said, does anyone see any problems with switching it so that we can > > now have it turned on by default from Qt 5.8? Naturally the configure > > option would stay so people can still turn it off if they wish. > > > > For reference the original thread about this can be found: > > http://lists.qt-project.org/pipermail/development/2012-> > > > October/007037.html > > > > > > Andy > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From swarit.wipra at gmail.com Fri May 27 06:41:01 2016 From: swarit.wipra at gmail.com (swarit wipra) Date: Fri, 27 May 2016 10:11:01 +0530 Subject: [Development] Regarding issues related to Qt3D Message-ID: Hi, I am getting following error, when running Qt 3d app. 05-19 19:26:06.857 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't find surface 2 05-19 19:26:06.869 221 628 D AudioFlinger: mixer(0xab962fb0) throttle end: throttle time(3) 05-19 19:26:06.877 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't find surface 2 05-19 19:26:47.118 221 628 D audio_hw_primary: out_set_parameters: enter: usecase(0: playback) kvpairs: routing=2 out->devices(2) adev->mode(0) 05-19 19:26:47.169 17339 17434 E libEGL : call to OpenGL ES API with no current context (logged once per thread) 05-19 19:26:47.248 17339 17339 I System.out: ClimateServiceIFClient : onPause 05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): ClimateHmiIF : NotifyOnPause --- 0xf7452b34 05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): UIClimateNotification : NotifyOnPause --- 0xf7452b34 05-19 19:26:47.290 17339 17405 W art : Native thread exiting without having called DetachCurrentThread (maybe it's going to use a pthread_key_create destructor?): Thread[10,tid=17405,Native,Thread*=0xab7c3548,peer=0x12d330a0,"QtThread"] Please guide me to fix it. Best Regards Swarit -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at raven-worx.net Fri May 27 08:47:01 2016 From: info at raven-worx.net (raven-worx Software) Date: Fri, 27 May 2016 08:47:01 +0200 Subject: [Development] QtWebkit to vcxproj In-Reply-To: References: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> Message-ID: <20160527084701.14486jy6n082aoo5@login-7.hoststar.at> Oswald Buddenhagen wrote: > note that vcxproj support for the build of qt as a whole has been > dropped a while ago, which is reflected by incomplete projects being > generated. you may be able to use them successfully for debugging, but > there is no way to use them for actually building qt reliably. i know. I had do to some fixing in the generated projects to make them compile. But those generated vcxproj files were essential to get started with. Now i have a Qt5 (almost all major modules) converted and compiling adn even running. QtWebkit conversion also looks good so far. Only WTF, JavaScriptCore and WebCore modules are missing. The webkit sources already come with vcxproj files of these 3 modules. Can i take those instead directly? Meaning are those just core modules of Webkit? Or do they need some special Qt configuration? From annulen at yandex.ru Fri May 27 11:41:16 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 27 May 2016 12:41:16 +0300 Subject: [Development] QtWebkit to vcxproj In-Reply-To: <20160527084701.14486jy6n082aoo5@login-7.hoststar.at> References: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> <20160527084701.14486jy6n082aoo5@login-7.hoststar.at> Message-ID: <3147591464342076@web25g.yandex.ru> 27.05.2016, 09:47, "raven-worx Software" : > Oswald Buddenhagen wrote: > >>  note that vcxproj support for the build of qt as a whole has been >>  dropped a while ago, which is reflected by incomplete projects being >>  generated. you may be able to use them successfully for debugging, but >>  there is no way to use them for actually building qt reliably. > > i know. I had do to some fixing in the generated projects to make them > compile. But those generated vcxproj files were essential to get > started with. > > Now i have a Qt5 (almost all major modules) converted and compiling > adn even running. > QtWebkit conversion also looks good so far. Only WTF, JavaScriptCore > and WebCore modules are missing. > > The webkit sources already come with vcxproj files of these 3 modules. > Can i take those instead directly? Meaning are those just core modules > of Webkit? Or do they need some special Qt configuration? These vcxproj have absolutely nothing to do with QtWebKit. They are meant for building AppleWin and WinCairo ports. -- Regards, Konstantin From tomek.bury at gmail.com Fri May 27 11:47:38 2016 From: tomek.bury at gmail.com (Tomek Bury) Date: Fri, 27 May 2016 09:47:38 +0000 Subject: [Development] QtWayland synchronisation between GL and compositor In-Reply-To: <4FBD3D5D-89FD-4FF1-AA23-E726D1B1D082@sletta.org> References: <4FBD3D5D-89FD-4FF1-AA23-E726D1B1D082@sletta.org> Message-ID: Hi Gunnar, Thanks for your replay. I've spend quite some time on #wayland IRC channel yesterday discussing this matter. It turns out that the compositor implementation assumes implicit synchronisation. The "submit" operation assumes that whatever dependencies were present on the client side are carried over to the server side. This way there's no need for an explicit CPU-GPU synchronisation on either side. Of course in order to do that one needs some sort of cross-process synchronisation either implicitly provided by the driver or via some sort of sync objects that can safely travel between client and server hidden in the Wayland platform implementation. The "release" operation is trickier and it's based on a specific implementation detail. Here's the wording from the spec ( https://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image_external.txt ): Sampling an external texture which has been modified since it was bound will return samples which may correspond to image values either before, during, or after the modification. Binding (or re-binding if already bound) an external texture by calling BindTexture after all modifications are complete guarantees that sampling done in future draw calls will return values corresponding to the values in the buffer at or after the time that BindTexture is called. Now, spec says "at or after" while Weston (and QtWayland as far as I can tell) assume that it's always "at" and never "after". If the driver honours that assumption it's safe to release the buffer to the client without waiting for the GL pipeline to finish drawing. Of course GL drivers are not required to honour that assumption and it's perfectly valid for the client to start updating the released buffer while compositor still uses it. The biggest problem is that there's no cross process synchronisation available in GL/EGL so the Wayland would have to take a performance hit if it wanted to be perfectly compliant with the GL spec. So technically it is a bug, but cost of fixing it is to high. The explicit synchronisation is in the works for quite some time now but don't hold your breath. Cheers, Tomek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From h4nn35.work at gmail.com Fri May 27 11:53:05 2016 From: h4nn35.work at gmail.com (Johannes Pointner) Date: Fri, 27 May 2016 11:53:05 +0200 Subject: [Development] Touch issues with Qt5.6/Qt5.7 beta and weston Message-ID: Hello, I have posted this question before in the interest mailinglist but didn't get any feedback. Therefore I thought maybe it would better fit here: I have a setup with weston (wayland(egl vivante) 1.9, weston(desktopshell) 1.9 and libinput 1.14 , yocto krogoth, but I also tried wayland 1.10, weston 1.10 and libinput 1.2.4) on an i.MX6 and have some issues regarding the touchscreen. The first one is that If I touch a combobox the combobox choices show in a popup but I can't "touch" any selection or more specifically I can't touch anything any more. But If I have a keyboard or a mouse connected I can use them to select a choice. After doing this with the keyboard/mouse I can use this comobox with my touchscreen without an issue, but only this combobox. For every other combobox I have to repeat this procedure. The second one is that without a keyboard connected I can't get the activeWindow (qApp->activeWindow) which has focus. But If I connect a keyboard this works. Does someone has experienced a similar behavior or has an idea what I'm doing wrong? Thx in advance, Hannes From thiago.macieira at intel.com Fri May 27 18:04:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 27 May 2016 13:04:51 -0300 Subject: [Development] QtWebkit to vcxproj In-Reply-To: <20160527084701.14486jy6n082aoo5@login-7.hoststar.at> References: <20160525161100.829949175ru0cvhw@login-7.hoststar.at> <20160527084701.14486jy6n082aoo5@login-7.hoststar.at> Message-ID: <2430396.yPXiCglTfS@tjmaciei-mobl1> Em sexta-feira, 27 de maio de 2016, às 08:47:01 BRT, raven-worx Software escreveu: > QtWebkit conversion also looks good so far. Only WTF, JavaScriptCore > and WebCore modules are missing. In other words, most of WebKit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Fri May 27 18:10:57 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 27 May 2016 16:10:57 +0000 Subject: [Development] Header review for 5.7.0 (vs 5.6.1) In-Reply-To: References: Message-ID: Following up on the earlier header review, comparing 5.6 to 5.7, I've now prepared a review of 5.7.0 vs 5.6.1, following some moderate refinements to the scripts. Hopefully various "not yet merged" changes are now in 5.7.0 to fix blemishes noticed in the earlier review: https://codereview.qt-project.org/160661 – qtbase https://codereview.qt-project.org/160662 – qtdeclarative https://codereview.qt-project.org/160663 – qtactiveqt https://codereview.qt-project.org/160664 – qtmultimedia https://codereview.qt-project.org/160665 – qttools https://codereview.qt-project.org/160666 – qtlocation https://codereview.qt-project.org/160667 – qtconnectivity https://codereview.qt-project.org/160668 – qtwayland https://codereview.qt-project.org/160669 – qt3d (which no-one reviewed last time) https://codereview.qt-project.org/160670 – qtquickcontrols https://codereview.qt-project.org/160671 – qtserialport https://codereview.qt-project.org/160672 – qtx11extras https://codereview.qt-project.org/160673 – qtandroidextras https://codereview.qt-project.org/160674 – qtwebsockets https://codereview.qt-project.org/160675 – qtwebengine https://codereview.qt-project.org/160676 – qtcanvas3d https://codereview.qt-project.org/160677 – qtquickcontrols2 The git show output of all of these taken together comes to a little under 29k lines; the boring diff (that's been elided here; I eye-balled it to check it really was boring) totalled about 150k lines. If there are any parts of these reviews that are boring and that can be characterised straightforwardly (i.e. such that a dumb script can implement them reliably), please do mention them on the bug report [0] or point out in the code review [1] how to implement them. [0] https://bugreports.qt.io/browse/QTQAINFRA-973 [1] https://codereview.qt-project.org/157299 Please take a look at the modules you care about and point out anything that's going to cause problems for the usual compatibility constraints, Eddy. From corentin.jabot at gmail.com Sat May 28 11:42:15 2016 From: corentin.jabot at gmail.com (Corentin) Date: Sat, 28 May 2016 09:42:15 +0000 Subject: [Development] The missing pieces of QJSEngine Message-ID: Hello. I'm once again trying to cut dependencies on Qt Script. QJSEngine still lacks some features to do so. - The ability to call a function from JS to C++. I found a work in that direction. https://codereview.qt-project.org/#/c/108871/2 . I am told the api was probably abandoned over threading consideration. - The ability to construct a QObject from JS. QtScript had newQMetaObject for that. I have see a lot of people requesting the ability to call a c++ function from JS. One classic usage I have in mind is the implementation of the PAC standard[1] As for creating QObject from JS, there are tons of use cases. It is my understanding that QBS depends on this feature a lot. I don't think that QJSEngine can really pretend to be a replacement for QScriptEngine without those features So, I have a few questions - Is anyone working on these features ? - If not, is there an interest for these api ? [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko/Proxy_Auto-Configuration_(PAC)_file Regards, Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nassian at bitshift-dynamics.de Sat May 28 11:47:38 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Sat, 28 May 2016 11:47:38 +0200 Subject: [Development] The missing pieces of QJSEngine In-Reply-To: References: Message-ID: <9922F874-D2D2-4953-8A5A-A44C98DDB753@bitshift-dynamics.de> What’s the point with calling C++ code from JS? We are doing this all the day - via signal/slots and registered types. Beste Grüße / Best regards, Alexander Nassian > Am 28.05.2016 um 11:42 schrieb Corentin : > > Hello. > I'm once again trying to cut dependencies on Qt Script. > > QJSEngine still lacks some features to do so. > > The ability to call a function from JS to C++. I found a work in that direction. https://codereview.qt-project.org/#/c/108871/2 . I am told the api was probably abandoned over threading consideration. > The ability to construct a QObject from JS. QtScript had newQMetaObject for that. > I have see a lot of people requesting the ability to call a c++ function from JS. One classic usage I have in mind is the implementation of the PAC standard[1] > > As for creating QObject from JS, there are tons of use cases. It is my understanding that QBS > depends on this feature a lot. > > > I don't think that QJSEngine can really pretend to be a replacement for QScriptEngine without those features > > > So, I have a few questions > Is anyone working on these features ? > If not, is there an interest for these api ? > > > [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko/Proxy_Auto-Configuration_(PAC)_file > > Regards, > Corentin > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun May 29 18:05:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 29 May 2016 13:05:07 -0300 Subject: [Development] Announcing moc_combine Message-ID: <2097120.WNQMIhggTj@tjmaciei-mobl1> I've just pushed a feature[1] to moc that makes it process multiple headers at the same time, producing only one output file, and a second feature[2] that "precompiles" a header. Since moc is single-threaded, this often means more wall-clock time than the previous case, but it's always less CPU time: CPU time (s) Moc – before 11,56 Moc – after 4,33 If you add that to the time to compile the moc output and to link, there's a definite gain. Debug Release Release + LTO Compile – before 30,05 23,71 22,35 Compile – after 5,85 6,28 5,36 Link – before 31,27 24,15 110,57 Link – after 7,04 6,52 92,21 For the full build, the change in wall-clock (seconds, 2-core * 2 HT CPU) is small, but visible: Release Release + LTO Before 68,813 77,736 After 66,426 61,084 (note: the "before" numbers are *after* I removed the #includes, so they're slighty higher than the QtCore before all my changes) This feature is optional. You can enable it for your module by doing: CONFIG += moc_combine BUT (and of course there's a "but") You can only enable it if you rid your module of Q_PRIVATE_SLOT first. Since this feature produces a single moc output for all headers, you can't have #include at the end of your files [exception: if you have only one such #include]. To get rid of the Q_PRIVATE_SLOTs, you can use the QObjectPrivate::connect overload that takes a QObjectPrivate pointer as third parameter. We can divide the porting in three groups: 1) easy/trivial: - simple connect() statements (even supports Qt::UniqueConnection, provided that you're connecting PMFs [note: there might be bugs!!]) - simple disconnect() statements where the four parameters match the same four of the connect() - QMetaObject::invokeMethod becoming QTimer::singleShot of 0 seconds examples: [3] and [4] 2) doable: - when there are disconnect()s that aren't trivial, in which case you need to retain the QMetaObject::Connection result of the connect() call example: [5] 3) hard: - when you need to do a major refactoring of the internals because it depended on QMetaMethod or something similar (see [6]) - when the front-end API requires modification too [1] https://codereview.qt-project.org/160755 [2] https://codereview.qt-project.org/160756 [3] https://codereview.qt-project.org/160752 [4] https://codereview.qt-project.org/160753 [5] https://codereview.qt-project.org/#/c/160751/1/src/corelib/animation/ qanimationgroup_p.h [6] https://codereview.qt-project.org/160758 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tony.sarajarvi at qt.io Sun May 29 18:58:07 2016 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sun, 29 May 2016 16:58:07 +0000 Subject: [Development] CI problems being solved Message-ID: Hi all! The CI is suffering from technical problems in the world of virtualization. I'm working on it and hopefully will get it back online within the hour if all goes well. I really can't say what the state of the server is before I can get the server back online. If it's a matter of restarting stuff then, then all should come back within an hour. Regards, -Tony Tony Sarajärvi CI Tech Lead The Qt Company - Elektroniikkatie 13, 90590 Oulu, Finland Email: tony.sarajarvi at theqtcompany.com http://qt.io Qt Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Sun May 29 19:10:06 2016 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sun, 29 May 2016 17:10:06 +0000 Subject: [Development] CI problems being solved In-Reply-To: References: Message-ID: Hi again. Seems I got it building again. However, there might be commits left out of control either in 'staging', 'staged' or 'integrating' states. If you find your commits hanging weirdly in these states, please let us know and we'll manually poke them with a cattle prod :) -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: 29. toukokuuta 2016 19:58 To: development at qt-project.org Subject: [Development] CI problems being solved Hi all! The CI is suffering from technical problems in the world of virtualization. I'm working on it and hopefully will get it back online within the hour if all goes well. I really can't say what the state of the server is before I can get the server back online. If it's a matter of restarting stuff then, then all should come back within an hour. Regards, -Tony Tony Sarajärvi CI Tech Lead The Qt Company - Elektroniikkatie 13, 90590 Oulu, Finland Email: tony.sarajarvi at theqtcompany.com http://qt.io Qt Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at theharmers.co.uk Sun May 29 21:02:16 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Sun, 29 May 2016 20:02:16 +0100 Subject: [Development] CI problems being solved In-Reply-To: References: Message-ID: Hi Tony, On 29/05/2016 18:10, Tony Sarajärvi wrote: > > Hi again. > > Seems I got it building again. However, there might be commits left > out of control either in ‘staging’, ‘staged’ or ‘integrating’ states. > If you find your commits hanging weirdly in these states, please let > us know and we’ll manually poke them with a cattle prod J > Could you poke: https://codereview.qt-project.org/#/c/160719/ https://codereview.qt-project.org/#/c/160723/ please? Thanks, Sean > -Tony > > *From:* Development > [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] *On > Behalf Of *Tony Sarajärvi > *Sent:* 29. toukokuuta 2016 19:58 > *To:* development at qt-project.org > *Subject:* [Development] CI problems being solved > > Hi all! > > The CI is suffering from technical problems in the world of > virtualization. I’m working on it and hopefully will get it back > online within the hour if all goes well. I really can’t say what the > state of the server is before I can get the server back online. If > it’s a matter of restarting stuff then, then all should come back > within an hour. > > Regards, > > -Tony > > Tony Sarajärvi > > CI Tech Lead > > The Qt Company - Elektroniikkatie 13, 90590 Oulu, Finland > > Email: tony.sarajarvi at theqtcompany.com > > > http://qt.io > > Qt Facebook: www.facebook.com/qt > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.jabot at gmail.com Sun May 29 21:46:27 2016 From: corentin.jabot at gmail.com (Corentin) Date: Sun, 29 May 2016 19:46:27 +0000 Subject: [Development] The missing pieces of QJSEngine In-Reply-To: References: Message-ID: WIP patch to add QJSEngine::newQMetaObject https://codereview.qt-project.org/160759 Le sam. 28 mai 2016 à 11:42, Corentin a écrit : > Hello. > I'm once again trying to cut dependencies on Qt Script. > > QJSEngine still lacks some features to do so. > > > - The ability to call a function from JS to C++. I found a work in > that direction. https://codereview.qt-project.org/#/c/108871/2 . I am > told the api was probably abandoned over threading consideration. > - The ability to construct a QObject from JS. QtScript had > newQMetaObject for that. > > I have see a lot of people requesting the ability to call a c++ function > from JS. One classic usage I have in mind is the implementation of the PAC > standard[1] > > As for creating QObject from JS, there are tons of use cases. It is my > understanding that QBS > depends on this feature a lot. > > > I don't think that QJSEngine can really pretend to be a replacement for > QScriptEngine without those features > > > So, I have a few questions > > - Is anyone working on these features ? > - If not, is there an interest for these api ? > > > > [1] > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko/Proxy_Auto-Configuration_(PAC)_file > > Regards, > Corentin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun May 29 22:31:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 29 May 2016 17:31:01 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <2097120.WNQMIhggTj@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> Message-ID: <1837210.nevGuMzOhv@tjmaciei-mobl1> Em domingo, 29 de maio de 2016, às 13:05:07 BRT, Thiago Macieira escreveu: > - simple connect() statements (even supports Qt::UniqueConnection, provided > that you're connecting PMFs [note: there might be bugs!!]) Confirmed: https://bugreports.qt.io/browse/QTBUG-53684 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuliocamuffo at gmail.com Mon May 30 08:29:47 2016 From: giuliocamuffo at gmail.com (Giulio Camuffo) Date: Mon, 30 May 2016 09:29:47 +0300 Subject: [Development] Touch issues with Qt5.6/Qt5.7 beta and weston In-Reply-To: References: Message-ID: Hi, 2016-05-27 12:53 GMT+03:00 Johannes Pointner : > Hello, > > I have posted this question before in the interest mailinglist but > didn't get any feedback. Therefore I thought maybe it would better fit > here: > > I have a setup with weston (wayland(egl vivante) 1.9, > weston(desktopshell) 1.9 and libinput 1.14 , yocto krogoth, but I also > tried wayland 1.10, weston 1.10 and libinput 1.2.4) on an i.MX6 and > have some issues regarding the touchscreen. > > The first one is that If I touch a combobox the combobox choices show > in a popup but I can't "touch" any selection or more specifically I > can't touch anything any more. But If I have a keyboard or a mouse > connected I can use them to select a choice. After doing this with the > keyboard/mouse I can use this comobox with my touchscreen without an > issue, but only this combobox. For every other combobox I have to > repeat this procedure. > > The second one is that without a keyboard connected I can't get the > activeWindow (qApp->activeWindow) which has focus. But If I connect a > keyboard this works. Unfortunately with wl_shell we don't have an "active" state, so we activate a window when it gets the keyboard focus. So that will obviously not work without a keyboard. We'd need to add a sane fallback. > > Does someone has experienced a similar behavior or has an idea what > I'm doing wrong? You're not doing anything wrong, they're just bugs. Please open an issue on the bug tracker for each of them. Thanks, Giulio > > Thx in advance, > Hannes > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tim at klingt.org Mon May 30 09:55:03 2016 From: tim at klingt.org (Tim Blechmann) Date: Mon, 30 May 2016 09:55:03 +0200 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> References: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> Message-ID: > Might be a bit premature, but is anyone opposed to dropping OS X 10.9 > and iOS 7.x in Qt 5.8? yes: it will prevent some users (including me) to update to qt-5.8, as our minimum osx requirement is still 10.9. From marc.mutz at kdab.com Mon May 30 10:19:38 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 30 May 2016 10:19:38 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <2097120.WNQMIhggTj@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> Message-ID: <201605301019.39407.marc.mutz@kdab.com> On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote: > I've just pushed a feature[1] to moc that makes it process multiple headers > at the same time, producing only one output file Separate compilation is not how I would recommend to use moc-generated files. I'd recommend to always include the moc file in the corresponding cpp file. That gives the compiler the whole picture and enables better optimisation[1] and error checking[2,3]. Thanks, Marc [1] https://codereview.qt-project.org/152423 [2] https://codereview.qt-project.org/153309 [3] https://codereview.qt-project.org/153321 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From markg85 at gmail.com Mon May 30 10:21:48 2016 From: markg85 at gmail.com (Mark Gaiser) Date: Mon, 30 May 2016 10:21:48 +0200 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> Message-ID: If possible, please don't.. Unless there is a technical reason which would make dropping that version a requirement? I'm still on OSX 10.9 since i like it much more then the versions that came after it. On Thu, May 26, 2016 at 11:39 AM, Tuukka Turunen wrote: > Sounds good to me in principle, especially since we very likely have again > next generation of both iOS and OS X to support in Qt 5.8. > > > > Especially in iOS users tend to upgrade to new versions quite quickly (and > then see if their devices still can run that or not). > > > > Yours, > > > > Tuukka > > > > *From:* Development [mailto:development-bounces+tuukka.turunen= > qt.io at qt-project.org] *On Behalf Of *Jake Petroules > *Sent:* keskiviikkona 25. toukokuuta 2016 21.17 > *To:* development at qt-project.org > *Subject:* [Development] Supported platforms for Qt 5.8 > > > > Hi all, > > > > Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and > iOS 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per > Qt release for the past 3 releases, but after that I think we should slow > to dropping one release for each release we add (so, once annually or about > once every two Qt minor releases). 10.10 and 8.0 were larger releases that > began a new "generation" so I think that gives us a better baseline to > start with before slowing to an annual upgrade cycle. > > -- > Jake Petroules - jake.petroules at theqtcompany.com > Consulting Services Engineer - The Qt Company > > Qbs build system evangelist - qbs.io > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Mon May 30 10:51:22 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 30 May 2016 08:51:22 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> Message-ID: That’s my view too: 10.9 may be a popular holdout for years, like 10.6 was. Now the typical response would be: well you can still deploy Qt applications to it - doesn’t mean it has to be a supported developer platform. Or, developers can stop upgrading Qt and stick with 5.6 or so. Is that really what we want them to do? Now I don’t think upgrading say a Core 2 Duo machine to 10.11 is anywhere near as bad as the iOS upgrade was (that was a disaster, in my experience on an iPad 2), but wouldn’t be surprised if people have good reasons not to. And what does it cost us? Most of the newer features are there anyway. Are there really so many ifdefs that we will avoid a maintenance nightmare by removing them? Or is it about the compiler? > On 30 May 2016, at 10:21, Mark Gaiser wrote: > > If possible, please don't.. > Unless there is a technical reason which would make dropping that version a requirement? > > I'm still on OSX 10.9 since i like it much more then the versions that came after it. > > On Thu, May 26, 2016 at 11:39 AM, Tuukka Turunen wrote: > Sounds good to me in principle, especially since we very likely have again next generation of both iOS and OS X to support in Qt 5.8. > > > > Especially in iOS users tend to upgrade to new versions quite quickly (and then see if their devices still can run that or not). > > > > Yours, > > > > Tuukka > > > > From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jake Petroules > Sent: keskiviikkona 25. toukokuuta 2016 21.17 > To: development at qt-project.org > Subject: [Development] Supported platforms for Qt 5.8 > > > > Hi all, > > > > Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and iOS 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per Qt release for the past 3 releases, but after that I think we should slow to dropping one release for each release we add (so, once annually or about once every two Qt minor releases). 10.10 and 8.0 were larger releases that began a new "generation" so I think that gives us a better baseline to start with before slowing to an annual upgrade cycle. > > -- > Jake Petroules - jake.petroules at theqtcompany.com > Consulting Services Engineer - The Qt Company > > Qbs build system evangelist - qbs.io > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Mon May 30 11:16:00 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 30 May 2016 11:16:00 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <201605301019.39407.marc.mutz@kdab.com> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <201605301019.39407.marc.mutz@kdab.com> Message-ID: <20160530091600.GD16044@troll08.it.local> On Mon, May 30, 2016 at 10:19:38AM +0200, Marc Mutz wrote: > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote: > > I've just pushed a feature[1] to moc that makes it process multiple headers > > at the same time, producing only one output file > > Separate compilation is not how I would recommend to use moc-generated files. > I'd recommend to always include the moc file in the corresponding cpp file. > i agree that the idea to bulk-compile mocs is somewhat backwards. however, manual includemocs are somewhat annoying, and in fact the need to include the moc when using Q_OBJECT in a .cpp file is one of the most common reasons for puzzling error messages (something about a missing vtable ... ?!?!). an idea would be auto-wrapping sources into generated files that include the actual source and the moc. but that might be a bit tough to implement with qmake, and the build artifacts would look a bit weird (particularly relevant for debugging). the next idea would be implementing moc inside the compiler itself, which is possible with at least clang and gcc nowadays. the last idea is doing away with moc entirely, at the cost of somewhat uglier macros, and actually working c++11/14 support in the compiler. "incidentally", olivier has more-or-less working solutions based on the latter two ideas. > That gives the compiler the whole picture and enables better optimisation[1] > and error checking[2,3]. > > Thanks, > Marc > > [1] https://codereview.qt-project.org/152423 > [2] https://codereview.qt-project.org/153309 > [3] https://codereview.qt-project.org/153321 > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon May 30 15:12:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 May 2016 10:12:01 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <201605301019.39407.marc.mutz@kdab.com> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <201605301019.39407.marc.mutz@kdab.com> Message-ID: <3278471.ZnoCSG6Fsk@tjmaciei-mobl1> Em segunda-feira, 30 de maio de 2016, às 10:19:38 BRT, Marc Mutz escreveu: > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote: > > I've just pushed a feature[1] to moc that makes it process multiple > > headers > > at the same time, producing only one output file > > Separate compilation is not how I would recommend to use moc-generated > files. I'd recommend to always include the moc file in the corresponding > cpp file. That gives the compiler the whole picture and enables better > optimisation[1] and error checking[2,3]. Sorry, I don't buy it. Instead: qmake -config ltcg There's a reason I showed the time for that build too. > [1] https://codereview.qt-project.org/152423 > [2] https://codereview.qt-project.org/153309 > [3] https://codereview.qt-project.org/153321 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at qt.io Mon May 30 16:24:38 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 30 May 2016 16:24:38 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <201605301019.39407.marc.mutz@kdab.com> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <201605301019.39407.marc.mutz@kdab.com> Message-ID: <20348918.RHZBax0rFY@42> On Monday 30 of May 2016 10:19:38 Marc Mutz wrote: > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote: > > I've just pushed a feature[1] to moc that makes it process multiple > > headers > > at the same time, producing only one output file > > Separate compilation is not how I would recommend to use moc-generated > files. I'd recommend to always include the moc file in the corresponding > cpp file. That gives the compiler the whole picture and enables better > optimisation[1] and error checking[2,3]. If moc has full picture it also can apply some nice optimizations, like for example here https://codereview.qt-project.org/#/c/75151/. Cheers, Jędrek From thiago.macieira at intel.com Mon May 30 16:26:46 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 May 2016 11:26:46 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <3278471.ZnoCSG6Fsk@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <201605301019.39407.marc.mutz@kdab.com> <3278471.ZnoCSG6Fsk@tjmaciei-mobl1> Message-ID: <366250532.U6umRFqkbA@tjmaciei-mobl1> On segunda-feira, 30 de maio de 2016 10:12:01 BRT Thiago Macieira wrote: > Em segunda-feira, 30 de maio de 2016, às 10:19:38 BRT, Marc Mutz escreveu: > > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote: > > > I've just pushed a feature[1] to moc that makes it process multiple > > > headers > > > at the same time, producing only one output file > > > > Separate compilation is not how I would recommend to use moc-generated > > files. I'd recommend to always include the moc file in the corresponding > > cpp file. That gives the compiler the whole picture and enables better > > optimisation[1] and error checking[2,3]. > > Sorry, I don't buy it. Instead: > qmake -config ltcg I've just fixed the LTCG build for Clang on Linux. I've been doign LTCG builds with GCC on Linux for some time too. See also Jędrzej's patch to share strings in moc[1] and between classes[2]. With both patche sets in, we should have one large string table for all classes in the library. [1] https://codereview.qt-project.org/75147 [2] https://codereview.qt-project.org/75151 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon May 30 17:53:48 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 30 May 2016 17:53:48 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <20348918.RHZBax0rFY@42> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <201605301019.39407.marc.mutz@kdab.com> <20348918.RHZBax0rFY@42> Message-ID: <201605301753.49408.marc.mutz@kdab.com> On Monday 30 May 2016 16:24:38 Jędrzej Nowacki wrote: > On Monday 30 of May 2016 10:19:38 Marc Mutz wrote: > > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote: > > > I've just pushed a feature[1] to moc that makes it process multiple > > > headers > > > at the same time, producing only one output file > > > > Separate compilation is not how I would recommend to use moc-generated > > files. I'd recommend to always include the moc file in the corresponding > > cpp file. That gives the compiler the whole picture and enables better > > optimisation[1] and error checking[2,3]. > > If moc has full picture it also can apply some nice optimizations, like for > example here https://codereview.qt-project.org/#/c/75151/. This is orthogonal. Obviously, I have nothing against running moc only once per library/executable, and applying optimisations such as string and sub-string sharing across classes. I also have nothing against a single output file for the tables. On the contrary. I applaud such changes. But I don't want QObject subclass member functions compiled into separate TUs anymore, for the reasons cited. So this would meet everyones requirements: a single moc run on all headers (and cpps) of a library, generating one output file with one large data table, and one file per class (or file), to be included in the class' .cpp file. This would even preserve Q_PRIVATE_SLOT, leading to less churn (unless that transition is desireable for other reasons than "doesn't work with moc_combine"). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Mon May 30 19:43:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 May 2016 14:43:32 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <201605301753.49408.marc.mutz@kdab.com> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <20348918.RHZBax0rFY@42> <201605301753.49408.marc.mutz@kdab.com> Message-ID: <1978489.YQOf8jaChJ@tjmaciei-mobl1> On segunda-feira, 30 de maio de 2016 17:53:48 BRT Marc Mutz wrote: > This is orthogonal. > > Obviously, I have nothing against running moc only once per > library/executable, and applying optimisations such as string and sub-string > sharing across classes. I also have nothing against a single output file > for the tables. On the contrary. I applaud such changes. > > But I don't want QObject subclass member functions compiled into separate > TUs anymore, for the reasons cited. > > So this would meet everyones requirements: a single moc run on all headers > (and cpps) of a library, generating one output file with one large data > table, and one file per class (or file), to be included in the class' .cpp > file. Except one requirement: the buildsytem. Each build target must produce exactly one output file. Anything else is not representable. $ gmake -f /dev/stdin foo bar <<<'foo bar: ; true' true true I also don't like that the string tables and other details would be extern symbols. Right now, they are static. For Qt code, we do have - fvisibility=hidden, but that's not required for users' code (though we could force Q_DECL_HIDDEN). > This would even preserve Q_PRIVATE_SLOT, leading to less churn (unless that > transition is desireable for other reasons than "doesn't work with > moc_combine"). It's desireable in most cases, but it's not always easy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Mon May 30 21:41:38 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 30 May 2016 21:41:38 +0200 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> References: <8ED48AB4-6497-467F-A60C-252BF83B8507@qt.io> Message-ID: <201605302141.38574.kde@carewolf.com> On Wednesday 25 May 2016, Jake Petroules wrote: > Hi all, > > Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and > iOS 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per > Qt release for the past 3 releases, but after that I think we should slow > to dropping one release for each release we add (so, once annually or > about once every two Qt minor releases). 10.10 and 8.0 were larger > releases that began a new "generation" so I think that gives us a better > baseline to start with before slowing to an annual upgrade cycle. -- Well Qt WebEngine has always had stricter requirements than the rest of Qt, so this shouldn't necessarily affect all other Qt modules, but it might be worth keeping in mind; The lastest Chromium 51, which is now being integrated into dev requires MSVC 2015 on Windows, and on Mac, XCode 6.4+ which Apple only allows to run on OS X 10.10+ Note though that these requirements are not final. Qt WebEngine 5.8 will likely end up using Chromium 53 before the we freeze the version, and the requirements might still change (though likely only up). Best regards `Allan From marc.mutz at kdab.com Mon May 30 17:58:44 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 30 May 2016 17:58:44 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <3278471.ZnoCSG6Fsk@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <201605301019.39407.marc.mutz@kdab.com> <3278471.ZnoCSG6Fsk@tjmaciei-mobl1> Message-ID: <201605301758.45857.marc.mutz@kdab.com> On Monday 30 May 2016 15:12:01 Thiago Macieira wrote: > Sorry, I don't buy it. Instead: > qmake -config ltcg I take that "I don't buy it" means that link-time compilation also warns about unused data and function members? Anyway, until such a time as that becomes the default build mode for Qt, I don't think we should discard optimisations that only(?) benefit separate- compilation modes. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Tue May 31 01:13:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 May 2016 20:13:16 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <201605301758.45857.marc.mutz@kdab.com> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <3278471.ZnoCSG6Fsk@tjmaciei-mobl1> <201605301758.45857.marc.mutz@kdab.com> Message-ID: <17532240.Lj4O1Feiqd@tjmaciei-mobl1> On segunda-feira, 30 de maio de 2016 17:58:44 BRT Marc Mutz wrote: > On Monday 30 May 2016 15:12:01 Thiago Macieira wrote: > > Sorry, I don't buy it. Instead: > > qmake -config ltcg > > I take that "I don't buy it" means that link-time compilation also warns > about unused data and function members? I didn't specifically test that. But I know that GCC does detect ODR violations when compiled in LTO mode. > Anyway, until such a time as that becomes the default build mode for Qt, I > don't think we should discard optimisations that only(?) benefit separate- > compilation modes. I doubt we'll make it the default. But correcting warnings is something that we Qt developers need to do and we can enable LTCG mode. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dmitry at 0fe.ru Tue May 31 06:34:19 2016 From: dmitry at 0fe.ru (Dmitry Shapovalov) Date: Tue, 31 May 2016 09:34:19 +0500 Subject: [Development] modbus over serial port on windows 7 ? Message-ID: Hello, can someone confirm that modbus over serial port is working on windows ? all my experiments led me to the thought that it is absolutely broken. i am using arduno as a modbus device. i tested it with qmodbus and modbus poll. works great. but when i try to use modbus examples from qt(qtserialbus/examples/serialbus/modbus/master), look like it can not send request. i tried release(5.6) and git version of qtserialbus and qtserialport modules with no luck. i am using windows 7 on virtualbox. arduino modbus library from here https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino arduino sketch http://pastebin.com/FHW3B7TX it's me or it's really broken ? -- -- With Best Regards Dmitry Shapovalov -------------- next part -------------- An HTML attachment was scrubbed... URL: From nolden at kde.org Tue May 31 08:59:14 2016 From: nolden at kde.org (Ralf Nolden) Date: Tue, 31 May 2016 08:59:14 +0200 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: Message-ID: <1605571.zKc7XR7oLN@w530.nolden.freebsd> Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: > Hello, > can someone confirm that modbus over serial port is working on windows ? I have tested modbus over serial port on windows with two Schneider Electric PLCs, a Twido and a Premium, both with TCP and RS485. We could evaluate your problems on IRC if you want. > all my experiments led me to the thought that it is absolutely broken. > i am using arduno as a modbus device. i tested it with qmodbus and modbus > poll. works great. but when i try to use modbus examples from > qt(qtserialbus/examples/serialbus/modbus/master), look like it can not send > request. > i tried release(5.6) and git version of qtserialbus and qtserialport > modules with no luck. > > i am using windows 7 on virtualbox. > arduino modbus library from here > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino > arduino sketch http://pastebin.com/FHW3B7TX > > it's me or it's really broken ? -- Kind regards, Ralf Nolden From Lars.Knoll at qt.io Tue May 31 09:03:26 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Tue, 31 May 2016 07:03:26 +0000 Subject: [Development] Nominating Edward Welbourne for approver status In-Reply-To: References: <141F5630-C501-43BE-B7EB-777FC74B8758@qt.io> <98541595-1C42-4A3E-B447-33A228F002E5@qt.io> Message-ID: <86D9D357-8F17-450D-BEB6-D7854C4D0872@qt.io> Approver rights have now been granted. Congratulations to Edward! Cheers, Lars On 10/05/16 05:21, "Development on behalf of Timur Pocheptsov" wrote: >+1 > >________________________________________ >From: Development on behalf of Shawn Rutledge >Sent: Monday, May 9, 2016 10:04:53 PM >To: Qt development mailing list >Subject: Re: [Development] Nominating Edward Welbourne for approver status > >On May 9, 2016, at 13:17, Lars Knoll wrote: > >> Hi, >> >> I'd like to nominate Edward Welbourne for Approver status. He's joined The Qt Company half a year ago, and has been working full time on Qt since. >> >> Here is his gerrit dashboard: >> >> https://codereview.qt-project.org/#/q/owner:edward.welbourne%2540theqtcompany.com+status:merged,n,z >> >> >> And his extensive list of reviews at: >> >> https://codereview.qt-project.org/#/q/reviewer:%22Edward+Welbourne+%253Cedward.welbourne%2540theqtcompany.com%253E%22,n,z >> > >+1 >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Tue May 31 09:45:40 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 31 May 2016 09:45:40 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <20160530091600.GD16044@troll08.it.local> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <201605301019.39407.marc.mutz@kdab.com> <20160530091600.GD16044@troll08.it.local> Message-ID: <1686563.NxmMuDruR1@oscar> On Montag, 30. Mai 2016 11:16:00 CEST Oswald Buddenhagen wrote: > On Mon, May 30, 2016 at 10:19:38AM +0200, Marc Mutz wrote: > > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote: > > > I've just pushed a feature[1] to moc that makes it process multiple > > > headers > > > at the same time, producing only one output file > > > > Separate compilation is not how I would recommend to use moc-generated > > files. I'd recommend to always include the moc file in the corresponding > > cpp file. > > i agree that the idea to bulk-compile mocs is somewhat backwards. Backwards to what? It's easy to do and save compilation time. [...] > the next idea would be implementing moc inside the compiler itself, > which is possible with at least clang and gcc nowadays. > > the last idea is doing away with moc entirely, at the cost of somewhat > uglier macros, and actually working c++11/14 support in the compiler. > > "incidentally", olivier has more-or-less working solutions based on the > latter two ideas. Which impose many more requirements on the compilers. And we support many more compiler in Qt. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From dmitry at 0fe.ru Tue May 31 11:23:42 2016 From: dmitry at 0fe.ru (Dmitry Shapovalov) Date: Tue, 31 May 2016 14:23:42 +0500 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: <1605571.zKc7XR7oLN@w530.nolden.freebsd> References: <1605571.zKc7XR7oLN@w530.nolden.freebsd> Message-ID: Thanks for reply Ralf. Email more preferable for me. Can you tell me what type of adapter you are using? Which version of qtserialport are you using? Maybe my problem is related to the type of serial port adapter. I tried use arduino with different usb-uart chips(ch430 and pl2303), but unsuccessfully. Here is output of qt modbus master example Запускается C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Desktop_Qt_5_6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... qt.modbus: (RTU client) Sent Serial PDU: 0x0400000001 qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x01040000000131ca qt.modbus: (RTU client) Send failed: 0x0400000001 qt.modbus: (RTU server) QSerialPort error: QSerialPort::SerialPortError(ResourceError) "Операция ввода/вывода была прервана из-за завершения потока команд или по запросу приложения." qt.modbus.lowlevel: (RTU client) Response buffer: "01" qt.modbus: (RTU client) Modbus ADU not complete qt.modbus.lowlevel: (RTU client) Response buffer: "0104024c494c06" qt.modbus: (RTU client) Received ADU: "0104024c494c06" qt.modbus: (RTU client) Cannot match response with open request, ignoring Look like it actually sends request, but qtserialport reports error, so qtserialbus(modbus) ignores response. 2016-05-31 11:59 GMT+05:00 Ralf Nolden : > Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: > > Hello, > > can someone confirm that modbus over serial port is working on windows ? > I have tested modbus over serial port on windows with two Schneider > Electric > PLCs, a Twido and a Premium, both with TCP and RS485. We could evaluate > your > problems on IRC if you want. > > > > all my experiments led me to the thought that it is absolutely broken. > > i am using arduno as a modbus device. i tested it with qmodbus and modbus > > poll. works great. but when i try to use modbus examples from > > qt(qtserialbus/examples/serialbus/modbus/master), look like it can not > send > > request. > > i tried release(5.6) and git version of qtserialbus and qtserialport > > modules with no luck. > > > > i am using windows 7 on virtualbox. > > arduino modbus library from here > > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino > > arduino sketch http://pastebin.com/FHW3B7TX > > > > it's me or it's really broken ? > > -- > Kind regards, > > Ralf Nolden > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- -- With Best Regards Dmitry Shapovalov -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Tue May 31 11:24:14 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 31 May 2016 11:24:14 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <1978489.YQOf8jaChJ@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <20348918.RHZBax0rFY@42> <201605301753.49408.marc.mutz@kdab.com> <1978489.YQOf8jaChJ@tjmaciei-mobl1> Message-ID: <20160531092414.GC22495@troll08.it.local> > On segunda-feira, 30 de maio de 2016 17:53:48 BRT Marc Mutz wrote: > > So this would meet everyones requirements: a single moc run on all headers > > (and cpps) of a library, generating one output file with one large data > > table, and one file per class (or file), to be included in the class' .cpp > > file. > sounds sensible. On Mon, May 30, 2016 at 02:43:32PM -0300, Thiago Macieira wrote: > Except one requirement: the buildsytem. Each build target must produce exactly > one output file. Anything else is not representable. > > $ gmake -f /dev/stdin foo bar <<<'foo bar: ; true' > true > true > that's a pretty bad test, as you're not using a file as a dep to synchronize on. also, we already employ a mild hack to represent compilers with multiple outputs in several places (e.g., yacc.prf). > I also don't like that the string tables and other details would be extern > symbols. Right now, they are static. For Qt code, we do have - > fvisibility=hidden, but that's not required for users' code > (though we could force Q_DECL_HIDDEN). > and why wouldn't we? it's auto-generated code ... > > This would even preserve Q_PRIVATE_SLOT, leading to less churn > > (unless that transition is desireable for other reasons than > > "doesn't work with moc_combine"). > > It's desireable in most cases, but it's not always easy. > can you get any more cryptic? ;) From nolden at kde.org Tue May 31 11:43:37 2016 From: nolden at kde.org (Ralf Nolden) Date: Tue, 31 May 2016 11:43:37 +0200 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: <1605571.zKc7XR7oLN@w530.nolden.freebsd> Message-ID: <1774553.lr7xm1JpR2@w530.nolden.freebsd> Am Dienstag, 31. Mai 2016, 14:23:42 schrieb Dmitry Shapovalov: > Thanks for reply Ralf. Email more preferable for me. > > Can you tell me what type of adapter you are using? Which version of > qtserialport are you using? Maybe my problem is related to the type of > serial port adapter. I tried use arduino with different usb-uart > chips(ch430 and pl2303), but unsuccessfully. > > Here is output of qt modbus master example > > Запускается > C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Desktop_Qt_5 > _6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... qt.modbus: (RTU client) > Sent Serial PDU: 0x0400000001 > qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x01040000000131ca > qt.modbus: (RTU client) Send failed: 0x0400000001 > qt.modbus: (RTU server) QSerialPort error: > QSerialPort::SerialPortError(ResourceError) "Операция ввода/вывода была > прервана из-за завершения потока команд или по запросу приложения." > qt.modbus.lowlevel: (RTU client) Response buffer: "01" > qt.modbus: (RTU client) Modbus ADU not complete > qt.modbus.lowlevel: (RTU client) Response buffer: "0104024c494c06" > qt.modbus: (RTU client) Received ADU: "0104024c494c06" > qt.modbus: (RTU client) Cannot match response with open request, ignoring > > Look like it actually sends request, but qtserialport reports error, so > qtserialbus(modbus) ignores response. The sending failed due to your log, then there is no open request that the response which you seem to get can be matched. You could also use a serial port sniffer to log the data transfer in parallel and check what is sent and received on the port. Anyway, from your output of the response buffer, you seem to get the requested value back: - slave id 1 - function code 4 - 2 bytes data to follow - value 4c49 - crc 4c06 (correct) Can you confirm the same string with your other tools and maybe try more than one value ? Your problem seems to be related to your error message above which I can't interpret due to missing language skills :) > > 2016-05-31 11:59 GMT+05:00 Ralf Nolden : > > Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: > > > Hello, > > > can someone confirm that modbus over serial port is working on windows ? > > > > I have tested modbus over serial port on windows with two Schneider > > Electric > > PLCs, a Twido and a Premium, both with TCP and RS485. We could evaluate > > your > > problems on IRC if you want. > > > > > all my experiments led me to the thought that it is absolutely broken. > > > i am using arduno as a modbus device. i tested it with qmodbus and > > > modbus > > > poll. works great. but when i try to use modbus examples from > > > qt(qtserialbus/examples/serialbus/modbus/master), look like it can not > > > > send > > > > > request. > > > i tried release(5.6) and git version of qtserialbus and qtserialport > > > modules with no luck. > > > > > > i am using windows 7 on virtualbox. > > > arduino modbus library from here > > > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino > > > arduino sketch http://pastebin.com/FHW3B7TX > > > > > > it's me or it's really broken ? > > > > -- > > Kind regards, > > > > Ralf Nolden > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development -- Kind regards, Ralf Nolden From denis.shienkov at gmail.com Tue May 31 12:05:11 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 31 May 2016 13:05:11 +0300 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: <1605571.zKc7XR7oLN@w530.nolden.freebsd> Message-ID: Seems, this: > qt.modbus: (RTU server) QSerialPort error: QSerialPort::SerialPortError(ResourceError) "Операция ввода/вывода была прервана из-за завершения потока команд или по запросу приложения." It is an 'ERROR_OPERATION_ABORTED', that can be caused by ::CancelIo() (e.g. when the serial port closes) or by a HW problems. BR, Denis 31.05.2016 12:23, Dmitry Shapovalov пишет: > Thanks for reply Ralf. Email more preferable for me. > > Can you tell me what type of adapter you are using? Which version of > qtserialport are you using? Maybe my problem is related to the type of > serial port adapter. I tried use arduino with different usb-uart > chips(ch430 and pl2303), but unsuccessfully. > > Here is output of qt modbus master example > > Запускается > C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Desktop_Qt_5_6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... > qt.modbus: (RTU client) Sent Serial PDU: 0x0400000001 > qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x01040000000131ca > qt.modbus: (RTU client) Send failed: 0x0400000001 > qt.modbus: (RTU server) QSerialPort error: > QSerialPort::SerialPortError(ResourceError) "Операция ввода/вывода > была прервана из-за завершения потока команд или по запросу приложения." > qt.modbus.lowlevel: (RTU client) Response buffer: "01" > qt.modbus: (RTU client) Modbus ADU not complete > qt.modbus.lowlevel: (RTU client) Response buffer: "0104024c494c06" > qt.modbus: (RTU client) Received ADU: "0104024c494c06" > qt.modbus: (RTU client) Cannot match response with open request, ignoring > > Look like it actually sends request, but qtserialport reports error, > so qtserialbus(modbus) ignores response. > > > 2016-05-31 11:59 GMT+05:00 Ralf Nolden >: > > Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: > > Hello, > > can someone confirm that modbus over serial port is working on > windows ? > I have tested modbus over serial port on windows with two > Schneider Electric > PLCs, a Twido and a Premium, both with TCP and RS485. We could > evaluate your > problems on IRC if you want. > > > > all my experiments led me to the thought that it is absolutely > broken. > > i am using arduno as a modbus device. i tested it with qmodbus > and modbus > > poll. works great. but when i try to use modbus examples from > > qt(qtserialbus/examples/serialbus/modbus/master), look like it > can not send > > request. > > i tried release(5.6) and git version of qtserialbus and qtserialport > > modules with no luck. > > > > i am using windows 7 on virtualbox. > > arduino modbus library from here > > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino > > arduino sketch http://pastebin.com/FHW3B7TX > > > > it's me or it's really broken ? > > -- > Kind regards, > > Ralf Nolden > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > -- > With Best Regards > Dmitry Shapovalov > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry at 0fe.ru Tue May 31 12:17:05 2016 From: dmitry at 0fe.ru (Dmitry Shapovalov) Date: Tue, 31 May 2016 15:17:05 +0500 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: <1605571.zKc7XR7oLN@w530.nolden.freebsd> Message-ID: Yep. That's right. It is ERROR_OPERATION_ABORTED. But why ? Any other application works as expected with this hardware. And i confirm that 0x01040000000131ca and 0x0104024c494c06 are correct request and response. 2016-05-31 15:05 GMT+05:00 Denis Shienkov : > Seems, this: > > > qt.modbus: (RTU server) QSerialPort error: > QSerialPort::SerialPortError(ResourceError) "Операция ввода/вывода была > прервана из-за завершения потока команд или по запросу приложения." > > It is an 'ERROR_OPERATION_ABORTED', that can be caused by ::CancelIo() > (e.g. when the serial port closes) or by a HW problems. > > BR, > > Denis > > 31.05.2016 12:23, Dmitry Shapovalov пишет: > > Thanks for reply Ralf. Email more preferable for me. > > Can you tell me what type of adapter you are using? Which version of > qtserialport are you using? Maybe my problem is related to the type of > serial port adapter. I tried use arduino with different usb-uart > chips(ch430 and pl2303), but unsuccessfully. > > Here is output of qt modbus master example > > Запускается > C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Desktop_Qt_5_6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... > qt.modbus: (RTU client) Sent Serial PDU: 0x0400000001 > qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x01040000000131ca > qt.modbus: (RTU client) Send failed: 0x0400000001 > qt.modbus: (RTU server) QSerialPort error: > QSerialPort::SerialPortError(ResourceError) "Операция ввода/вывода была > прервана из-за завершения потока команд или по запросу приложения." > qt.modbus.lowlevel: (RTU client) Response buffer: "01" > qt.modbus: (RTU client) Modbus ADU not complete > qt.modbus.lowlevel: (RTU client) Response buffer: "0104024c494c06" > qt.modbus: (RTU client) Received ADU: "0104024c494c06" > qt.modbus: (RTU client) Cannot match response with open request, ignoring > > Look like it actually sends request, but qtserialport reports error, so > qtserialbus(modbus) ignores response. > > > 2016-05-31 11:59 GMT+05:00 Ralf Nolden : > >> Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: >> > Hello, >> > can someone confirm that modbus over serial port is working on windows ? >> I have tested modbus over serial port on windows with two Schneider >> Electric >> PLCs, a Twido and a Premium, both with TCP and RS485. We could evaluate >> your >> problems on IRC if you want. >> >> >> > all my experiments led me to the thought that it is absolutely broken. >> > i am using arduno as a modbus device. i tested it with qmodbus and >> modbus >> > poll. works great. but when i try to use modbus examples from >> > qt(qtserialbus/examples/serialbus/modbus/master), look like it can not >> send >> > request. >> > i tried release(5.6) and git version of qtserialbus and qtserialport >> > modules with no luck. >> > >> > i am using windows 7 on virtualbox. >> > arduino modbus library from here >> > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino >> > arduino sketch http://pastebin.com/FHW3B7TX >> > >> > it's me or it's really broken ? >> >> -- >> Kind regards, >> >> Ralf Nolden >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > > -- > -- > With Best Regards > Dmitry Shapovalov > > > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- -- With Best Regards Dmitry Shapovalov -------------- next part -------------- An HTML attachment was scrubbed... URL: From berkayelbir at gmail.com Tue May 31 12:23:24 2016 From: berkayelbir at gmail.com (Berkay Elbir) Date: Tue, 31 May 2016 13:23:24 +0300 Subject: [Development] Qt 5.6 StyleSheet Message-ID: Hello All, I have a problem about Qt Stylesheets, I am using Qt 5.6 on windows.(This problem does not exist in Qt 5.5.1) I use this code piece, this is a QLabel inside a QDialog. ui.newGroupNameLabel->setStyleSheet("QLabel { color : black; }"); I also tried giving it a name usingQObject::setObjectName() and use an ID Selector to refer to it. But it still occurs. It affects whole project. I mean that affecting other widgets. All the expand symbols change to plus sign. This QLabel is unrelated to this widget(below). Did anyone face with this problem? [image: Inline image 1] [image: Inline image 2] Thanks in advance, Berkay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 1018 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 807 bytes Desc: not available URL: From sergio.martins at kdab.com Tue May 31 12:36:51 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 31 May 2016 11:36:51 +0100 Subject: [Development] Qt 5.6 StyleSheet In-Reply-To: References: Message-ID: <10262677.rhJfgCAJ1J@desktop> On Tuesday, 31 May 2016 13:23:24 WEST Berkay Elbir wrote: > Hello All, > > I have a problem about Qt Stylesheets, I am using Qt 5.6 on windows.(This > problem does not exist in Qt 5.5.1) I use this code piece, this is a QLabel > inside a QDialog. > > ui.newGroupNameLabel->setStyleSheet("QLabel { color : black; }"); Please open a bug report with a test case so people can verify your claim. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From denis.shienkov at gmail.com Tue May 31 12:53:15 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 31 May 2016 13:53:15 +0300 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: <1605571.zKc7XR7oLN@w530.nolden.freebsd> Message-ID: > But why ? I don't know.. maybe the Qt Modbus Master closes the connection without waiting of data send, maybe something else.. PS: I just have checked the QSerialPort autotests with the PL2303 on Windows - all worked. PS2: You can try to use the Terminal Example (from the Qt Serial Port) with the Rx/Tx connected, to check that your serial port works. 31.05.2016 13:17, Dmitry Shapovalov пишет: > Yep. That's right. It is ERROR_OPERATION_ABORTED. > But why ? Any other application works as expected with this hardware. > > And i confirm that 0x01040000000131ca and 0x0104024c494c06 are correct > request and response. > > > 2016-05-31 15:05 GMT+05:00 Denis Shienkov >: > > Seems, this: > > > qt.modbus: (RTU server) QSerialPort error: QSerialPort::SerialPortError(ResourceError) "Операция > ввода/вывода была прервана из-за завершения потока команд или по > запросу приложения." > > It is an 'ERROR_OPERATION_ABORTED', that can be caused by > ::CancelIo() (e.g. when the serial port closes) or by a HW problems. > > BR, > > Denis > > > 31.05.2016 12:23, Dmitry Shapovalov пишет: >> Thanks for reply Ralf. Email more preferable for me. >> >> Can you tell me what type of adapter you are using? Which version >> of qtserialport are you using? Maybe my problem is related to the >> type of serial port adapter. I tried use arduino with different >> usb-uart chips(ch430 and pl2303), but unsuccessfully. >> >> Here is output of qt modbus master example >> >> Запускается >> C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Desktop_Qt_5_6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... >> qt.modbus: (RTU client) Sent Serial PDU: 0x0400000001 >> qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x01040000000131ca >> qt.modbus: (RTU client) Send failed: 0x0400000001 >> qt.modbus: (RTU server) QSerialPort error: >> QSerialPort::SerialPortError(ResourceError) "Операция >> ввода/вывода была прервана из-за завершения потока команд или по >> запросу приложения." >> qt.modbus.lowlevel: (RTU client) Response buffer: "01" >> qt.modbus: (RTU client) Modbus ADU not complete >> qt.modbus.lowlevel: (RTU client) Response buffer: "0104024c494c06" >> qt.modbus: (RTU client) Received ADU: "0104024c494c06" >> qt.modbus: (RTU client) Cannot match response with open request, >> ignoring >> >> Look like it actually sends request, but qtserialport reports >> error, so qtserialbus(modbus) ignores response. >> >> >> 2016-05-31 11:59 GMT+05:00 Ralf Nolden > >: >> >> Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: >> > Hello, >> > can someone confirm that modbus over serial port is working >> on windows ? >> I have tested modbus over serial port on windows with two >> Schneider Electric >> PLCs, a Twido and a Premium, both with TCP and RS485. We >> could evaluate your >> problems on IRC if you want. >> >> >> > all my experiments led me to the thought that it is >> absolutely broken. >> > i am using arduno as a modbus device. i tested it with >> qmodbus and modbus >> > poll. works great. but when i try to use modbus examples from >> > qt(qtserialbus/examples/serialbus/modbus/master), look like >> it can not send >> > request. >> > i tried release(5.6) and git version of qtserialbus and >> qtserialport >> > modules with no luck. >> > >> > i am using windows 7 on virtualbox. >> > arduino modbus library from here >> > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino >> > arduino sketch http://pastebin.com/FHW3B7TX >> > >> > it's me or it's really broken ? >> >> -- >> Kind regards, >> >> Ralf Nolden >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> >> >> >> -- >> -- >> With Best Regards >> Dmitry Shapovalov >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > -- > With Best Regards > Dmitry Shapovalov > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From nolden at kde.org Tue May 31 14:15:15 2016 From: nolden at kde.org (Ralf Nolden) Date: Tue, 31 May 2016 14:15:15 +0200 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: Message-ID: <21228815.hmc38veoAe@w530.nolden.freebsd> Am Dienstag, 31. Mai 2016, 13:53:15 schrieb Denis Shienkov: > > But why ? > > I don't know.. maybe the Qt Modbus Master closes the connection without > waiting of data send, > > maybe something else.. > > PS: I just have checked the QSerialPort autotests with the PL2303 on > Windows - all worked. > > PS2: You can try to use the Terminal Example (from the Qt Serial Port) > with the Rx/Tx connected, > > to check that your serial port works. If you have a second PC around, try running the slave example there and connect them with a second adapter, then try the master example to see if your conection works between those two computers. At any rate. the modbus master is doing the right thing if the error comes from the serial port. We can't just ignore port errors in cases where the returned response theoretically matches the expected results :) > > 31.05.2016 13:17, Dmitry Shapovalov пишет: > > Yep. That's right. It is ERROR_OPERATION_ABORTED. > > But why ? Any other application works as expected with this hardware. > > > > And i confirm that 0x01040000000131ca and 0x0104024c494c06 are correct > > request and response. > > > > > > 2016-05-31 15:05 GMT+05:00 Denis Shienkov > > > >: > > Seems, this: > > > qt.modbus: (RTU server) QSerialPort error: > > > QSerialPort::SerialPortError(ResourceError) "Операция> > > ввода/вывода была прервана из-за завершения потока команд или по > > запросу приложения." > > > > It is an 'ERROR_OPERATION_ABORTED', that can be caused by > > > > ::CancelIo() (e.g. when the serial port closes) or by a HW problems. > > > > BR, > > > > Denis > > > > 31.05.2016 12:23, Dmitry Shapovalov пишет: > >> Thanks for reply Ralf. Email more preferable for me. > >> > >> Can you tell me what type of adapter you are using? Which version > >> of qtserialport are you using? Maybe my problem is related to the > >> type of serial port adapter. I tried use arduino with different > >> usb-uart chips(ch430 and pl2303), but unsuccessfully. > >> > >> Here is output of qt modbus master example > >> > >> Запускается > >> C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Deskt > >> op_Qt_5_6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... qt.modbus: > >> (RTU client) Sent Serial PDU: 0x0400000001 > >> qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x01040000000131ca > >> qt.modbus: (RTU client) Send failed: 0x0400000001 > >> qt.modbus: (RTU server) QSerialPort error: > >> QSerialPort::SerialPortError(ResourceError) "Операция > >> ввода/вывода была прервана из-за завершения потока команд или по > >> запросу приложения." > >> qt.modbus.lowlevel: (RTU client) Response buffer: "01" > >> qt.modbus: (RTU client) Modbus ADU not complete > >> qt.modbus.lowlevel: (RTU client) Response buffer: "0104024c494c06" > >> qt.modbus: (RTU client) Received ADU: "0104024c494c06" > >> qt.modbus: (RTU client) Cannot match response with open request, > >> ignoring > >> > >> Look like it actually sends request, but qtserialport reports > >> error, so qtserialbus(modbus) ignores response. > >> > >> > >> 2016-05-31 11:59 GMT+05:00 Ralf Nolden >> > >> >: > >> Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: > >> > Hello, > >> > can someone confirm that modbus over serial port is working > >> > >> on windows ? > >> I have tested modbus over serial port on windows with two > >> Schneider Electric > >> PLCs, a Twido and a Premium, both with TCP and RS485. We > >> could evaluate your > >> problems on IRC if you want. > >> > >> > all my experiments led me to the thought that it is > >> > >> absolutely broken. > >> > >> > i am using arduno as a modbus device. i tested it with > >> > >> qmodbus and modbus > >> > >> > poll. works great. but when i try to use modbus examples from > >> > qt(qtserialbus/examples/serialbus/modbus/master), look like > >> > >> it can not send > >> > >> > request. > >> > i tried release(5.6) and git version of qtserialbus and > >> > >> qtserialport > >> > >> > modules with no luck. > >> > > >> > i am using windows 7 on virtualbox. > >> > arduino modbus library from here > >> > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino > >> > arduino sketch http://pastebin.com/FHW3B7TX > >> > > >> > it's me or it's really broken ? > >> > >> -- > >> Kind regards, > >> > >> Ralf Nolden > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development -- Kind regards, Ralf Nolden From thiago.macieira at intel.com Tue May 31 14:56:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 May 2016 09:56:14 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <20160531092414.GC22495@troll08.it.local> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <1978489.YQOf8jaChJ@tjmaciei-mobl1> <20160531092414.GC22495@troll08.it.local> Message-ID: <13057872.HkLBc7rlxM@tjmaciei-mobl1> On terça-feira, 31 de maio de 2016 11:24:14 BRT Oswald Buddenhagen wrote: > > > This would even preserve Q_PRIVATE_SLOT, leading to less churn > > > (unless that transition is desireable for other reasons than > > > "doesn't work with moc_combine"). > > > > It's desireable in most cases, but it's not always easy. > > can you get any more cryptic? It's desireable to do that transition (remove Q_PRIVATE_SLOT) but it's not always easy. See I87e17314d8b24ae983b1fffd1453881278670a83 when I push it later today to get rid of the last Q_PRIVATE_SLOT in QtDBus. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From hugo.winter at lpp.polytechnique.fr Tue May 31 17:06:08 2016 From: hugo.winter at lpp.polytechnique.fr (hugo winter) Date: Tue, 31 May 2016 17:06:08 +0200 Subject: [Development] ColorMap class Message-ID: <1464707168.4354.12.camel@lpp.polytechnique.fr> Hello, I just wrote a ColorMap class for QtChart. It's part of a GUI project developedat the Laboratory of Plasma Physics (LPP / http://www.lpp.fr ) to visualize satellite data. While the work is still in progress, I'd like to have some feedback about it.Also, I'd like to discuss the possibility to integrate it, at some point, into the QtChart API. I'll be happy to make any changes from comments you may have. I would also be thankful if you could give me some advices about some troublesome points : - I had hard time trying to implement a custom axis to display a colorbar. Although functional, our actual implementation is a bit crapy.Is there a way to change the place where Ticklabels of QAbstractAxis are painted? http://imgur.com/Bu7wU1Q - I noticed that the colormap is somehow disappearing when multiple lineseries are added to the chart.It appears back when refreshing the painting process. Is this a known bug (it might come from an hover event) ? You can find the code here: https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/u sers/hugo/ColorMapChart In order to try it, you may look at : qtcharts/examples/colormap/sources/main.cpp It is under GPL. Thanks. Hugo From joerg.bornemann at qt.io Tue May 31 18:13:18 2016 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Tue, 31 May 2016 18:13:18 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <2097120.WNQMIhggTj@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> Message-ID: <70e1cf20-ae94-327a-0497-0816da278e03@qt.io> On 29/05/2016 18:05, Thiago Macieira wrote: > I've just pushed a feature[1] to moc that makes it process multiple headers at > the same time, producing only one output file, and a second feature[2] that > "precompiles" a header. Since moc is single-threaded, this often means more > wall-clock time than the previous case, but it's always less CPU time: [...] While this feature reduces the build time for full builds within a measurable range, it drastically increases build time for incremental builds. Changing just one Q_OBJECT header file results in full regeneration of combined_moc.cpp. Take for example: touch src/widgets/dialogs/qprogressdialog.h make moc time without moc_combine: 0.8s moc time with moc_combine: 15.6s This feature is nice for source distributions but isn't suitable for code being developed. BR, Joerg From thiago.macieira at intel.com Tue May 31 19:30:49 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 May 2016 14:30:49 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <1686563.NxmMuDruR1@oscar> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <20160530091600.GD16044@troll08.it.local> <1686563.NxmMuDruR1@oscar> Message-ID: <2161820.RyIZJbVMY2@tjmaciei-mobl1> On terça-feira, 31 de maio de 2016 09:45:40 BRT Olivier Goffart wrote: > > the next idea would be implementing moc inside the compiler itself, > > which is possible with at least clang and gcc nowadays. > > > > the last idea is doing away with moc entirely, at the cost of somewhat > > uglier macros, and actually working c++11/14 support in the compiler. > > > > "incidentally", olivier has more-or-less working solutions based on the > > latter two ideas. > > Which impose many more requirements on the compilers. And we support many > more compiler in Qt. I don't see us dropping the current moc until at least Qt 7 or when Microsoft Visual Studio is no longer relevant. I think we should provide moc-ng as an optional dependency, but neither bundled with Qt nor a requirement to build Qt or a user's project. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 31 19:42:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 May 2016 14:42:01 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <70e1cf20-ae94-327a-0497-0816da278e03@qt.io> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <70e1cf20-ae94-327a-0497-0816da278e03@qt.io> Message-ID: <4153317.MxXBt00U2c@tjmaciei-mobl1> On terça-feira, 31 de maio de 2016 18:13:18 BRT Joerg Bornemann wrote: > While this feature reduces the build time for full builds within a > measurable range, it drastically increases build time for incremental > builds. Changing just one Q_OBJECT header file results in full > regeneration of combined_moc.cpp. > > Take for example: > touch src/widgets/dialogs/qprogressdialog.h > make > > moc time without moc_combine: 0.8s > moc time with moc_combine: 15.6s > > This feature is nice for source distributions but isn't suitable for > code being developed. We can easily disable it for developer builds. But note that due to rebases and touching central files like qglobal.h or qobject.h, everything rebuilds anyway. The best of both worlds would be if: * moc could output more than one file * moc could be run once for however many files needed updating * moc could be given the list of files that have changed, but no others GNU make helps us for the last option: $? The names of all the prerequisites that are newer than the target, with spaces between them. For prerequisites which are archive members, only the named member is used (see Archives). [https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html#index-_003f-_0028automatic-variable_0029] I don't know how to implement the first two. Also, qmake would need to list only the actual headers, not the indirect dependencies of them as it currently does. That would mean moc would not get rerun if an indirect dependency of a header changed. In Qt 4, that wasn't a problem; for Qt 5, given that moc parses plugin and metatype declarations from included headers, the rerun would not produce the same as a clean build. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 31 20:14:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 May 2016 15:14:41 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <4153317.MxXBt00U2c@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <70e1cf20-ae94-327a-0497-0816da278e03@qt.io> <4153317.MxXBt00U2c@tjmaciei-mobl1> Message-ID: <36713893.opssEsTE1h@tjmaciei-mobl1> On terça-feira, 31 de maio de 2016 14:42:01 BRT Thiago Macieira wrote: > The best of both worlds would be if: > * moc could output more than one file > * moc could be run once for however many files needed updating > * moc could be given the list of files that have changed, but no others [cut] > Also, qmake would need to list only the actual headers, not the indirect > dependencies of them as it currently does. That would mean moc would not > get rerun if an indirect dependency of a header changed. In Qt 4, that > wasn't a problem; for Qt 5, given that moc parses plugin and metatype > declarations from included headers, the rerun would not produce the same as > a clean build. The attached Makefile accomplishes the goals above (to test, run "make create" first). $ gmake moc --combine=%.h=.moc/moc_%.cpp 1.h 2.h $ touch 1.h $ gmake moc --combine=%.h=.moc/moc_%.cpp 1.h $ touch 2.h $ gmake moc --combine=%.h=.moc/moc_%.cpp 2.h $ touch *.h $ gmake moc --combine=%.h=.moc/moc_%.cpp 1.h 2.h But it suffers from the problem of indirect dependencies, which I don't know how to solve: $ gmake gmake: Nothing to be done for 'mocables'. $ touch indirect1.h $ gmake gmake: Nothing to be done for 'mocables'. The other problem, of course, is about systems that don't use GNU make. Looks like nmake has the same syntax[1], but what about BSD makes? [1] https://msdn.microsoft.com/en-us/library/cbes8ded.aspx -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: text/x-makefile Size: 489 bytes Desc: not available URL: From joerg.bornemann at qt.io Tue May 31 20:35:17 2016 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Tue, 31 May 2016 20:35:17 +0200 Subject: [Development] Announcing moc_combine In-Reply-To: <4153317.MxXBt00U2c@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <70e1cf20-ae94-327a-0497-0816da278e03@qt.io> <4153317.MxXBt00U2c@tjmaciei-mobl1> Message-ID: <574DD965.6080004@qt.io> On 31/05/2016 19:42, Thiago Macieira wrote: >> This feature is nice for source distributions but isn't suitable for >> code being developed. > > We can easily disable it for developer builds. Yes, please! > But note that due to rebases and touching central files like qglobal.h or > qobject.h, everything rebuilds anyway. This depends on the area and branch you're working on. I can see how you're affected. ;) > The best of both worlds would be if: > * moc could output more than one file > * moc could be run once for however many files needed updating > * moc could be given the list of files that have changed, but no others > > GNU make helps us for the last option: > > $? The good thing is, nmake also supports $?: All dependents with a later timestamp than the current target. [https://msdn.microsoft.com/en-us/library/cbes8ded.aspx] > I don't know how to implement the first two. moc could output combined_moc.cpp which includes every moc_XXX.cpp. The update run of moc then regenerates the single moc_XXX.cpp files. This still leaves the issue that compilation of combined_moc.cpp will be slower for the incremental build case. So I'm not sure it's worth it. Turning moc_combine off for developer builds seems OK to me. BR, Joerg From thiago.macieira at intel.com Tue May 31 20:29:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 May 2016 15:29:45 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <36713893.opssEsTE1h@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <4153317.MxXBt00U2c@tjmaciei-mobl1> <36713893.opssEsTE1h@tjmaciei-mobl1> Message-ID: <2048890.4Foyy2zQhD@tjmaciei-mobl1> On terça-feira, 31 de maio de 2016 15:14:41 BRT Thiago Macieira wrote: > On terça-feira, 31 de maio de 2016 14:42:01 BRT Thiago Macieira wrote: > > Also, qmake would need to list only the actual headers, not the indirect > > dependencies of them as it currently does. That would mean moc would not > > get rerun if an indirect dependency of a header changed. In Qt 4, that > > wasn't a problem; for Qt 5, given that moc parses plugin and metatype > > declarations from included headers, the rerun would not produce the same > > as > > a clean build. > But it suffers from the problem of indirect dependencies, which I don't know > how to solve: > > $ gmake > gmake: Nothing to be done for 'mocables'. > $ touch indirect1.h > $ gmake > gmake: Nothing to be done for 'mocables'. The following extra rules solve the problem, at the expense of causing Qt Creator to complain that the header you had opened changed every time you build: 1.h: indirect1.h @touch $@ 2.h: indirect2.h @touch $@ indirect1.h: indirect1-1.h @touch $@ Proof: $ gmake moc --combine=%.h=.moc/moc_%.cpp 1.h 2.h $ touch indirect2.h $ gmake moc --combine=%.h=.moc/moc_%.cpp 2.h $ touch indirect1-1.h $ gmake moc --combine=%.h=.moc/moc_%.cpp 1.h -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 31 20:54:02 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 May 2016 15:54:02 -0300 Subject: [Development] Announcing moc_combine In-Reply-To: <2048890.4Foyy2zQhD@tjmaciei-mobl1> References: <2097120.WNQMIhggTj@tjmaciei-mobl1> <36713893.opssEsTE1h@tjmaciei-mobl1> <2048890.4Foyy2zQhD@tjmaciei-mobl1> Message-ID: <2179459.Ml8NWEUyRl@tjmaciei-mobl1> On terça-feira, 31 de maio de 2016 15:29:45 BRT Thiago Macieira wrote: > The following extra rules solve the problem, at the expense of causing Qt > Creator to complain that the header you had opened changed every time you > build: [cut] > Proof: > $ gmake > moc --combine=%.h=.moc/moc_%.cpp 1.h 2.h > $ touch indirect2.h > $ gmake > moc --combine=%.h=.moc/moc_%.cpp 2.h > $ touch indirect1-1.h > $ gmake > moc --combine=%.h=.moc/moc_%.cpp 1.h Ok, updated Makefile by using a shadow set of zero-sized files just to accummulate the timestamp. I've used some extra GNU make goodies here to make my life easier: === $(HEADERS:%=.timestamp-%): .timestamp-%: % @touch -r $< $@ .timestamp-1.h: .timestamp-indirect1.h .timestamp-2.h: .timestamp-indirect2.h .timestamp-indirect1.h: .timestamp-indirect1-1.h === But qmake could easily just write everything expanded ($< is the first prerequisite). However, this *does* require make to do at least one pattern substitution and I have no clue how to tell nmake to do it: .moc-run: .timestamp-1.h .timestamp-2.h moc --combine=%.h=$(MOC_DIR)moc_%.cpp ${?:.timestamp-%=%} Also note that this will fail for headers outside the current dir. Resolving that is an exercise left to the reader. Once someone resolves those two problems, I can change moc --combine to accept a pattern like the example above and generate multiple files. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: text/x-makefile Size: 815 bytes Desc: not available URL: