From sean.harmer at kdab.com Mon May 1 08:17:23 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 1 May 2017 07:17:23 +0100 Subject: [Development] New configuration system docs and FBX issues Message-ID: Hi, is there any documentation for the new configuration system please? My specific issue is that I need a config test that uses different library names on each platform and I can't see how to achieve this. On windows I want the FBX config test in Qt 3D to link against the static FBX library libfbxsdk-md.lib whereas on linux it would be libfbxsdk-static.a and on macOS libfbxsdk.a. An additional complication is that if we're building in debug and release build, the FBX SDK has the libs for these in different directories so we can't just rely upon passing the full -L path/to/fbxsdk/lib/platform/arch/{debug|release} to configure as if we pass debug we can't find the release lib and vice versa. If we can solve this then hopefully we can build the FBX plugin as part of the official build and not have to rely upon users to build it themselves. Thanks in advance for any help/pointers. Sean From alexander.blasche at qt.io Mon May 1 13:47:48 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 1 May 2017 11:47:48 +0000 Subject: [Development] JIra update and downtime on 10 May (starting 7:00 CEST) Message-ID: Hi, It's been some time since we gave Jira a more general update. It's time for the next round. We will update from Jira 6.3 to Jira 7.3. The update will bring along bug fixes and a minor face lift. In general it enables us to catch-up to Jira 's general release cycle. We will upgrade Jira on 10 May starting at 7:00 am CEST. Current expectation is that Jira will be back in business about 2 hrs later. I apologize for any inconvenience that this downtime might bring along. If you have any questions beforehand or after the update, please contact Andrey Leman (on CC) or me. -- Alex From thiago.macieira at intel.com Mon May 1 15:16:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 May 2017 10:16:23 -0300 Subject: [Development] New configuration system docs and FBX issues In-Reply-To: References: Message-ID: <1716189.cOT8g0p9p3@tjmaciei-mobl1> On Monday, 1 May 2017 03:17:23 -03 Sean Harmer wrote: > Hi, > > is there any documentation for the new configuration system please? > > My specific issue is that I need a config test that uses different > library names on each platform and I can't see how to achieve this. On > windows I want the FBX config test in Qt 3D to link against the static > FBX library libfbxsdk-md.lib whereas on linux it would be > libfbxsdk-static.a and on macOS libfbxsdk.a. Please make sure we're abe to link against the dynamic version of that library on Linux. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Tue May 2 09:22:49 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 2 May 2017 07:22:49 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes In-Reply-To: References: <5FCFBAA9-07AF-4D91-A8B4-A7B4B10AAA5E@qt.io> <4474F3B3-B2C6-4439-A7E8-4B91D4444C05@qt.io> <0C7D543C-F215-40FB-BAB7-E2ACE4F9C831@qt.io> <252A1631-FCB7-4564-B650-71EB6C852FFE@qt.io> Message-ID: <2195F5E3-F1A0-4868-BB57-3291F999AF67@qt.io> Hi, While I do agree that having a platform in CI and supporting it for those who have purchased support are not 1:1, in case of dropping the 32-bit iOS from CI for Qt 5.10 it also means that this configuration should no longer be used and not be supported. I do not see much problems with that as we continue to support 32 bit iOS for earlier platforms (until Apple drops it) and the 32 bit iOS devices are already quite old. Yours, Tuukka On 28/04/2017, 19.58, "Jake Petroules" wrote: > On Apr 27, 2017, at 11:28 PM, Lars Knoll wrote: > > >> On 27 Apr 2017, at 16:59, Jake Petroules wrote: >> >>> >>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen wrote: >>> >>> >>> Hi, >>> >>> Related to the Apple platforms, could we consider the following for Qt 5.10: >>> - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) >>> - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support >> >> I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional. > > Agree, there is a difference between the two. > > What I think we should however do for 5.10 is remove 32bit support for iOS from CI and our binary packages. And that means that things will be untested on 32bit iOS, and thus is likely to break at some point. I think 32-bit support on iOS is kind of unlikely to break accidentally, but I agree we should remove it from our binary packages. The iPhone 5 is dead. >> >> As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing… > > For the commercial version, it’s to a large extent up to TQtC to define the support offering. The open source project anyway does not offer any official support for the Qt versions released. All you can do is ask on the mailing lists or file a bug report and hope for the best. Or of course sit down, fix it yourself and submit a patch :) My point was that if a commercial customer goes to support with a bug in a 32-bit build of Qt for iOS, support won't say "we do not support that, go away". They will fix the problem, regardless of the fact that it isn't part of a reference configuration. If a customer sets the minimum deployment target of Qt for iOS to 5.0 and then goes to support saying Qt doesn't work, support WILL tell them "we do not support that (because we deliberately broke it), we can't help you and you'll have to talk to Services and pay money if you want it working that badly". That's the real-world outcome, which is why I don't like using the term "supported" as a synonym for "is a reference configuration in CI". A reference configuration in CI always constitutes something that is supported. However, something that's supported is not necessarily a reference configuration in CI. We should make this clear to our users by not using the term "supported" in a misleading way. > >> >> Something like the following seems nice: >> Tier 1 - the most rigorously tested configurations, tested in CI >> Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI >> Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement > > I’m ok to describe things in tiers, as that’s what we have in practice. We don’t test e.g. FreeBSD in CI, but we will accept patches if something’s broken on that platform and someone cares enough to fix it. Same would be true for 32bit iOS in 5.10 then. But the only thing the Qt project will be able to give some guarantees for are the configurations tested in CI. >> >> Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). > > Dropping it has other benefits. Currently iOS is on the critical path in the CI system for qt5.git integrations and thus package creation. Dropping 32bit support going to significantly cut down on iOS compile times, and should thus lead to faster turn around times for package creation. > > Lars > >> >>> - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) >> >> Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :) >> >> Current list is: >> - Qt 5.6 - supports macOS 10.7 and up >> - Qt 5.7 - supports macOS 10.8 and up >> - Qt 5.8 - supports macOS 10.9 and up >> - Qt 5.9 - supports macOS 10.10 and up >> >> Planned: >> - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10 >> - Qt 5.11 - supports macOS 10.11 and up >> >> By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported". >> >> If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright. >> >> But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10) >> >>> >>> Yours, >>> >>> Tuukka >>> >>> On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" wrote: >>> >>> >>>> On Apr 27, 2017, at 2:29 AM, Heikki Halmet wrote: >>>> >>>> Hi, >>>> >>>> Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. >>>> Please comment if the proposal is insufficient or the changes are unacceptable somehow. >>>> >>>> Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html >>>> >>>> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: >>>> RHEL 7.2 -> RHEL 7.3 (Any benefits?) >>>> OpenSUSE 42.1 -> OpenSUSE 42.2 >>>> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) >>>> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) >>> >>> Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. >>> >>>> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) >>> >>> 8.3.2, please. >>> >>>> Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 >>>> Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 >>>> INTEGRITY GHS 2016.5.4 -> 2017.1.x >>>> Support for Android 8 (if available on time) >>>> iOS 11 support (if available on time. Current rumors -> september) >>>> >>>> MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. >>>> This means that we can only use Preview release of 10.13 for testing before final official release is out. >>>> That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. >>> >>> How do you know it won't be called macOS 11? ;) >>> >>> The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. >>> >>> Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. >>> >>>> >>>> NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. >>>> With all others we'll do the best we can but we can't commit that those will be supported in 5.10. >>>> >>>> >>>> >>>> Best regards >>>> Heikki Halmet >>>> >>>> The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland >>>> Email: heikki.halmet at qt.io >>>> Phone: +358408672112 >>>> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petroules at qt.io >>> The Qt Company - Silicon Valley >>> Qbs build tool evangelist - qbs.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> >> -- >> Jake Petroules - jake.petroules at qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From sean.harmer at kdab.com Tue May 2 09:47:34 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 2 May 2017 08:47:34 +0100 Subject: [Development] New configuration system docs and FBX issues In-Reply-To: <1716189.cOT8g0p9p3@tjmaciei-mobl1> References: <1716189.cOT8g0p9p3@tjmaciei-mobl1> Message-ID: Hi, On 01/05/2017 14:16, Thiago Macieira wrote: > On Monday, 1 May 2017 03:17:23 -03 Sean Harmer wrote: >> Hi, >> >> is there any documentation for the new configuration system please? >> >> My specific issue is that I need a config test that uses different >> library names on each platform and I can't see how to achieve this. On >> windows I want the FBX config test in Qt 3D to link against the static >> FBX library libfbxsdk-md.lib whereas on linux it would be >> libfbxsdk-static.a and on macOS libfbxsdk.a. > > Please make sure we're abe to link against the dynamic version of that library > on Linux. Why the preference for dynamic linking here? It's another file to have to distribute? I don't particularly mind either way but is there a policy for such things? 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 rjvbertin at gmail.com Tue May 2 09:48:15 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 02 May 2017 09:48:15 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <13013557.Mnue7YQq09@tjmaciei-mobl1> <3769950.cUxRZ2AYE2@patux.local> <12577474.OERONMxfOn@tjmaciei-mobl1> Message-ID: <2386711.qmUd6InBHh@patux.local> Thiago Macieira wrote: At the very least there should be alternative binaries (QtCore? QtDBus?) available for download with the patch applied to which you can point people who report related issues, and the patch itself should be provided with the sources (in the tarball or clearly listed on the download page). >> If you're so certain of the patches why haven't they still been >> incorporated?! Seems there's an internal act that has to be gotten >> together! > > Because they fail in the CI. There's a regression. I'm aware of the direct reason. Apparently you're sure enough that the CI failure is without consequence to put the burden and responsibility of incorporating the patch on end-users. That's what I mean with getting an internal act together: what do you tell a commercial client who runs into this issue? That you're waiting for data from the wild to address a potential side- effect of a fix that is clearly necessary? I'm sorry but I cannot find other words than "man up". No one can reproduce the CI failure on a regular set-up? Fine, maybe the CI is flawed somewhere? Incorporate the patch with whatever workaround you can find for use on the CI (a configure flag to deactivate the patch, an extra runtime check that avoids the fatal operation even if the condition should never occur, anything that works). If the regression is not a false alarm you'll end up getting a bug report with the missing information because everyone will be using the patch. You'll finally address a known bug with confirmed sightings in the wild, POSSIBLY introducing another bug which might never be triggered. Not just the (un)happy few who are aware of a patch that you cannot even obtain easily. Digging up TWO codereviews and getting the patches in usable form is not what I have in mind with "easily", and after that you still need to build your own Qt copy. From joerg.bornemann at qt.io Tue May 2 09:57:27 2017 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Tue, 2 May 2017 09:57:27 +0200 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: <201704280935.10085.marc.mutz@kdab.com> References: <201704280935.10085.marc.mutz@kdab.com> Message-ID: <89c2df0d-0fe2-6191-d6e9-90ab485c3339@qt.io> On 28/04/2017 09:35, Marc Mutz wrote: > TL;DR: I propose to document overloaded functions with a single comment block, > containing multiple \fn's and a common documentation text, to be rendered as > one documentation block preceded by a listing of all the \fn's, instead of as > individual functions. +1 The text duplication is silly, and I have seen several places where information was inadvertently added to only one of the overloads. BR, Joerg From oswald.buddenhagen at qt.io Tue May 2 10:25:43 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 2 May 2017 10:25:43 +0200 Subject: [Development] New configuration system docs and FBX issues In-Reply-To: References: Message-ID: <20170502082543.GG2928@troll08> On Mon, May 01, 2017 at 07:17:23AM +0100, Sean Harmer wrote: > is there any documentation for the new configuration system please? > the "documentation" is the vast amount of configure.json files which actually use it. > My specific issue is that I need a config test that uses different > library names on each platform and I can't see how to achieve this. > funny, because the very first file one might look into - qtbase/configure.json - contains two examples of just that right at the top of the library list (zlib and dbus). the "next level" is openssl in qtbase/src/network. From sean.harmer at kdab.com Tue May 2 10:46:59 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 2 May 2017 09:46:59 +0100 Subject: [Development] New configuration system docs and FBX issues In-Reply-To: <20170502082543.GG2928@troll08> References: <20170502082543.GG2928@troll08> Message-ID: <65652ff6-c5fb-57db-34cb-5e32c278bb17@kdab.com> Hi, On 02/05/2017 09:25, Oswald Buddenhagen wrote: > On Mon, May 01, 2017 at 07:17:23AM +0100, Sean Harmer wrote: >> is there any documentation for the new configuration system please? >> > the "documentation" is the vast amount of configure.json files which > actually use it. Thanks, but that doesn't make it easy to get an overview of common use cases though as you don't know which ones are common without looking through many files. I just didn't know if I was missing documentation somewhere but it seems not. It's easy to miss the exact thing you are after when looking through like this too. I didn't know I could put a "condition" in a "sources". Now I do. >> My specific issue is that I need a config test that uses different >> library names on each platform and I can't see how to achieve this. >> > funny, because the very first file one might look into - > qtbase/configure.json - contains two examples of just that right at the > top of the library list (zlib and dbus). > the "next level" is openssl in qtbase/src/network. Thanks for the tips. I had been looking in qtbase/src/corelib and gui. 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 announce at qt-project.org Tue May 2 11:26:25 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 2 May 2017 09:26:25 +0000 Subject: [Development] [Announce] Qt 5.9 beta3 available Message-ID: Hi all, Qt 5.9 beta3 is available. As earlier you can update it at the top of your Qt 5.9 beta(2) online installation or do clean installation by using qt online installer. Detailed instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jani.heikkinen at qt.io Tue May 2 11:27:44 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 2 May 2017 09:27:44 +0000 Subject: [Development] Qt 5.9 beta3 available Message-ID: Hi all, Qt 5.9 beta3 is now available. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to second beta can be found as an attachment. Please test the release and report your effort via https://wiki.qt.io/Qt59_release_testing. I hope we can get results for each platform in the table to get full coverage & good understanding where we are. br, Jani Heikkinen Release Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.9.0-beta2-delta-beta3-commits Type: application/octet-stream Size: 17703 bytes Desc: qt5.9.0-beta2-delta-beta3-commits URL: From Martin.Smith at qt.io Tue May 2 11:37:36 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Tue, 2 May 2017 09:37:36 +0000 Subject: [Development] [docs] changing the way overloads are documented and presented In-Reply-To: <89c2df0d-0fe2-6191-d6e9-90ab485c3339@qt.io> References: <201704280935.10085.marc.mutz@kdab.com>, <89c2df0d-0fe2-6191-d6e9-90ab485c3339@qt.io> Message-ID: >The text duplication is silly, and I have seen several places where >information was inadvertently added to only one of the overloads. We still need a way to tell qdoc how to provide information that applies to one overload, or to a subset of the \fn overloads in the list. martin ________________________________________ From: Development on behalf of Joerg Bornemann Sent: Tuesday, May 2, 2017 9:57:27 AM To: Marc Mutz; development at qt-project.org Subject: Re: [Development] [docs] changing the way overloads are documented and presented On 28/04/2017 09:35, Marc Mutz wrote: > TL;DR: I propose to document overloaded functions with a single comment block, > containing multiple \fn's and a common documentation text, to be rendered as > one documentation block preceded by a listing of all the \fn's, instead of as > individual functions. +1 The text duplication is silly, and I have seen several places where information was inadvertently added to only one of the overloads. BR, Joerg _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue May 2 12:26:14 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 2 May 2017 10:26:14 +0000 Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files Message-ID: Hi all Maintainers! Branching from '5.9' to '5.9.0' is now ongoing and it is time to start creating change files for Qt 5.9.0. Please do the initial ones as soon as possible. And if some important change is coming in after the initial ones are in change owner can (& have to) update the change file as well. I am hoping we could get the change files now in early enough instead of fighting which these just before release (and even delaying the release because of missing ones...) br, Jani From thiago.macieira at intel.com Tue May 2 13:32:48 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 May 2017 06:32:48 -0500 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <2386711.qmUd6InBHh@patux.local> References: <1691504.8p7tJBIcV1@bola> <12577474.OERONMxfOn@tjmaciei-mobl1> <2386711.qmUd6InBHh@patux.local> Message-ID: <1971500.1OmyRXTGo0@tjmaciei-mobl1> On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > At the very least there should be alternative binaries (QtCore? QtDBus?) > available for download with the patch applied to which you can point people > who report related issues, and the patch itself should be provided with the > sources (in the tarball or clearly listed on the download page). We can't provide binaries because the regression causes a deadlock in the 5.8 branch build. I keep hoping someone will get annoyed enough and actually investigate the regression. Because it doesn't happen on my computer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 2 13:33:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 May 2017 06:33:39 -0500 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1971500.1OmyRXTGo0@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <2386711.qmUd6InBHh@patux.local> <1971500.1OmyRXTGo0@tjmaciei-mobl1> Message-ID: <5458272.Nf1PAQOlCQ@tjmaciei-mobl1> On Tuesday, 2 May 2017 06:32:48 CDT Thiago Macieira wrote: > On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote: > > Thiago Macieira wrote: > > > > At the very least there should be alternative binaries (QtCore? QtDBus?) > > available for download with the patch applied to which you can point > > people > > who report related issues, and the patch itself should be provided with > > the > > sources (in the tarball or clearly listed on the download page). > > We can't provide binaries because the regression causes a deadlock in the > 5.8 branch build. > > I keep hoping someone will get annoyed enough and actually investigate the > regression. Because it doesn't happen on my computer. But I can add it to the known issues wiki page. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 2 13:37:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 May 2017 06:37:54 -0500 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <2386711.qmUd6InBHh@patux.local> References: <1691504.8p7tJBIcV1@bola> <12577474.OERONMxfOn@tjmaciei-mobl1> <2386711.qmUd6InBHh@patux.local> Message-ID: <2160438.bqYSLf8oiV@tjmaciei-mobl1> On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote: > I'm aware of the direct reason. Apparently you're sure enough that the CI > failure is without consequence to put the burden and responsibility of > incorporating the patch on end-users. That's what I mean with getting an > internal act together: what do you tell a commercial client who runs into > this issue? That you're waiting for data from the wild to address a > potential side- effect of a fix that is clearly necessary? The commercial client will complain to paid support, support will investigate the issue and figure out what the regression is. > I'm sorry but I cannot find other words than "man up". > No one can reproduce the CI failure on a regular set-up? Fine, maybe the CI > is flawed somewhere? Incorporate the patch with whatever workaround you can > find for use on the CI (a configure flag to deactivate the patch, an extra > runtime check that avoids the fatal operation even if the condition should > never occur, anything that works). Yes, none of the regular QtDBus developers can reproduce the issue nor anyone who has investigated the issue could. (That set of people has a count of 1) The problem in 5.6 is an autotest that fails. In 5.8, the build deadlocks, so we can't even just disable a test. We'd have to disable all of the code that uses qdbusxml2cpp, like dbusmenu and dbustray. That's not acceptable. > If the regression is not a false alarm you'll end up getting a bug report > with the missing information because everyone will be using the patch. > You'll finally address a known bug with confirmed sightings in the wild, > POSSIBLY introducing another bug which might never be triggered. It's not a false alarm. IT's reliably reproduceable in the CI. Just not on the developers' computers. (again: population of 1) > Not just the (un)happy few who are aware of a patch that you cannot even > obtain easily. Digging up TWO codereviews and getting the patches in usable > form is not what I have in mind with "easily", and after that you still > need to build your own Qt copy. Yeah, hoping that someone annoyed enough will reproduce the regression and submit a fix to my patch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 2 13:37:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 May 2017 06:37:54 -0500 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <2386711.qmUd6InBHh@patux.local> References: <1691504.8p7tJBIcV1@bola> <12577474.OERONMxfOn@tjmaciei-mobl1> <2386711.qmUd6InBHh@patux.local> Message-ID: <2160438.bqYSLf8oiV@tjmaciei-mobl1> On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote: > I'm aware of the direct reason. Apparently you're sure enough that the CI > failure is without consequence to put the burden and responsibility of > incorporating the patch on end-users. That's what I mean with getting an > internal act together: what do you tell a commercial client who runs into > this issue? That you're waiting for data from the wild to address a > potential side- effect of a fix that is clearly necessary? The commercial client will complain to paid support, support will investigate the issue and figure out what the regression is. > I'm sorry but I cannot find other words than "man up". > No one can reproduce the CI failure on a regular set-up? Fine, maybe the CI > is flawed somewhere? Incorporate the patch with whatever workaround you can > find for use on the CI (a configure flag to deactivate the patch, an extra > runtime check that avoids the fatal operation even if the condition should > never occur, anything that works). Yes, none of the regular QtDBus developers can reproduce the issue nor anyone who has investigated the issue could. (That set of people has a count of 1) The problem in 5.6 is an autotest that fails. In 5.8, the build deadlocks, so we can't even just disable a test. We'd have to disable all of the code that uses qdbusxml2cpp, like dbusmenu and dbustray. That's not acceptable. > If the regression is not a false alarm you'll end up getting a bug report > with the missing information because everyone will be using the patch. > You'll finally address a known bug with confirmed sightings in the wild, > POSSIBLY introducing another bug which might never be triggered. It's not a false alarm. IT's reliably reproduceable in the CI. Just not on the developers' computers. (again: population of 1) > Not just the (un)happy few who are aware of a patch that you cannot even > obtain easily. Digging up TWO codereviews and getting the patches in usable > form is not what I have in mind with "easily", and after that you still > need to build your own Qt copy. Yeah, hoping that someone annoyed enough will reproduce the regression and submit a fix to my patch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 2 13:37:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 May 2017 06:37:54 -0500 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <2386711.qmUd6InBHh@patux.local> References: <1691504.8p7tJBIcV1@bola> <12577474.OERONMxfOn@tjmaciei-mobl1> <2386711.qmUd6InBHh@patux.local> Message-ID: <2160438.bqYSLf8oiV@tjmaciei-mobl1> On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote: > I'm aware of the direct reason. Apparently you're sure enough that the CI > failure is without consequence to put the burden and responsibility of > incorporating the patch on end-users. That's what I mean with getting an > internal act together: what do you tell a commercial client who runs into > this issue? That you're waiting for data from the wild to address a > potential side- effect of a fix that is clearly necessary? The commercial client will complain to paid support, support will investigate the issue and figure out what the regression is. > I'm sorry but I cannot find other words than "man up". > No one can reproduce the CI failure on a regular set-up? Fine, maybe the CI > is flawed somewhere? Incorporate the patch with whatever workaround you can > find for use on the CI (a configure flag to deactivate the patch, an extra > runtime check that avoids the fatal operation even if the condition should > never occur, anything that works). Yes, none of the regular QtDBus developers can reproduce the issue nor anyone who has investigated the issue could. (That set of people has a count of 1) The problem in 5.6 is an autotest that fails. In 5.8, the build deadlocks, so we can't even just disable a test. We'd have to disable all of the code that uses qdbusxml2cpp, like dbusmenu and dbustray. That's not acceptable. > If the regression is not a false alarm you'll end up getting a bug report > with the missing information because everyone will be using the patch. > You'll finally address a known bug with confirmed sightings in the wild, > POSSIBLY introducing another bug which might never be triggered. It's not a false alarm. IT's reliably reproduceable in the CI. Just not on the developers' computers. (again: population of 1) > Not just the (un)happy few who are aware of a patch that you cannot even > obtain easily. Digging up TWO codereviews and getting the patches in usable > form is not what I have in mind with "easily", and after that you still > need to build your own Qt copy. Yeah, hoping that someone annoyed enough will reproduce the regression and submit a fix to my patch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 2 13:37:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 May 2017 06:37:54 -0500 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <2386711.qmUd6InBHh@patux.local> References: <1691504.8p7tJBIcV1@bola> <12577474.OERONMxfOn@tjmaciei-mobl1> <2386711.qmUd6InBHh@patux.local> Message-ID: <2160438.bqYSLf8oiV@tjmaciei-mobl1> On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote: > I'm aware of the direct reason. Apparently you're sure enough that the CI > failure is without consequence to put the burden and responsibility of > incorporating the patch on end-users. That's what I mean with getting an > internal act together: what do you tell a commercial client who runs into > this issue? That you're waiting for data from the wild to address a > potential side- effect of a fix that is clearly necessary? The commercial client will complain to paid support, support will investigate the issue and figure out what the regression is. > I'm sorry but I cannot find other words than "man up". > No one can reproduce the CI failure on a regular set-up? Fine, maybe the CI > is flawed somewhere? Incorporate the patch with whatever workaround you can > find for use on the CI (a configure flag to deactivate the patch, an extra > runtime check that avoids the fatal operation even if the condition should > never occur, anything that works). Yes, none of the regular QtDBus developers can reproduce the issue nor anyone who has investigated the issue could. (That set of people has a count of 1) The problem in 5.6 is an autotest that fails. In 5.8, the build deadlocks, so we can't even just disable a test. We'd have to disable all of the code that uses qdbusxml2cpp, like dbusmenu and dbustray. That's not acceptable. > If the regression is not a false alarm you'll end up getting a bug report > with the missing information because everyone will be using the patch. > You'll finally address a known bug with confirmed sightings in the wild, > POSSIBLY introducing another bug which might never be triggered. It's not a false alarm. IT's reliably reproduceable in the CI. Just not on the developers' computers. (again: population of 1) > Not just the (un)happy few who are aware of a patch that you cannot even > obtain easily. Digging up TWO codereviews and getting the patches in usable > form is not what I have in mind with "easily", and after that you still > need to build your own Qt copy. Yeah, hoping that someone annoyed enough will reproduce the regression and submit a fix to my patch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue May 2 16:09:19 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 2 May 2017 14:09:19 +0000 Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files In-Reply-To: References: Message-ID: Hi, I'm a bit confused. The release team usually did the initial commit and maintainers edited the content. I'm fine with doing it myself, but I'm just wondering: Is there an intentional change in procedure? Simon ________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, May 2, 2017 12:26:14 PM To: development at qt-project.org Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files Hi all Maintainers! Branching from '5.9' to '5.9.0' is now ongoing and it is time to start creating change files for Qt 5.9.0. Please do the initial ones as soon as possible. And if some important change is coming in after the initial ones are in change owner can (& have to) update the change file as well. I am hoping we could get the change files now in early enough instead of fighting which these just before release (and even delaying the release because of missing ones...) br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Tue May 2 16:15:07 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 2 May 2017 14:15:07 +0000 Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files In-Reply-To: References: Message-ID: Hi, Well, that's true: We have created initial ones for maintainers to start with few previous releases. We can do the same for this time as well. Hoping already tomorrow br, Jani From: Simon Hausmann Sent: tiistaina 2. toukokuuta 2017 17.09 To: Jani Heikkinen ; development at qt-project.org Subject: Re: MAINTAINERS: your action needed: Qt 5.9.0 change files Hi, I'm a bit confused. The release team usually did the initial commit and maintainers edited the content. I'm fine with doing it myself, but I'm just wondering: Is there an intentional change in procedure? Simon ________________________________ From: Development > on behalf of Jani Heikkinen > Sent: Tuesday, May 2, 2017 12:26:14 PM To: development at qt-project.org Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files Hi all Maintainers! Branching from '5.9' to '5.9.0' is now ongoing and it is time to start creating change files for Qt 5.9.0. Please do the initial ones as soon as possible. And if some important change is coming in after the initial ones are in change owner can (& have to) update the change file as well. I am hoping we could get the change files now in early enough instead of fighting which these just before release (and even delaying the release because of missing ones...) br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Tue May 2 17:38:47 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 2 May 2017 16:38:47 +0100 Subject: [Development] New configuration system docs and FBX issues In-Reply-To: References: Message-ID: Hi, On 01/05/2017 07:17, Sean Harmer wrote: > Hi, > > is there any documentation for the new configuration system please? > > My specific issue is that I need a config test that uses different > library names on each platform and I can't see how to achieve this. On > windows I want the FBX config test in Qt 3D to link against the static > FBX library libfbxsdk-md.lib whereas on linux it would be > libfbxsdk-static.a and on macOS libfbxsdk.a. > > An additional complication is that if we're building in debug and > release build, the FBX SDK has the libs for these in different > directories so we can't just rely upon passing the full -L > path/to/fbxsdk/lib/platform/arch/{debug|release} to configure as if we > pass debug we can't find the release lib and vice versa. > > If we can solve this then hopefully we can build the FBX plugin as part > of the official build and not have to rely upon users to build it > themselves. > > Thanks in advance for any help/pointers. I've started this but am now stuck (again). Please see: https://codereview.qt-project.org/#/c/193269/ What I would like is to be able to find the FBX SDK from: 1) Well known locations, or 2) An environment variable, or 3) A location specified as an argument to configure. I've made a start on 3) but need to evaluate this in the custom test function, qtConfLibrary_fbx. 2) is already there to some extent. 1) we can pretty easily add a list of places to search as done for some other tests. Where I'm falling down is in trying to construct the path to search for the actual libraries. For e.g. with the latest FBX SDK I have paths such as: 1) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x64\debug 2) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x64\release 3) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x86\debug 4) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x86\release And from the docs it looks similar for other compiler versions and platforms. I've managed to build up the $compiler/$arch part of the path but I can't figure out how to handle the debug vs release vs debug-and-release parts. Is this possible to do at configure time or should I rather be doing this in a .pri/.pro file where we build the actual plugin? What is the recommendation for building the config.test, debug or release or both? Sorry if I'm being dumb, I still feel like I'm missing some of the though processes/rationale that went into designing the new system and I'm having trouble reverse engineering what is or isn't possible and how to best go about these things. Thanks in advance for any help. 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 rjvbertin at gmail.com Wed May 3 13:28:30 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 03 May 2017 13:28:30 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <12577474.OERONMxfOn@tjmaciei-mobl1> <2386711.qmUd6InBHh@patux.local> <2160438.bqYSLf8oiV@tjmaciei-mobl1> Message-ID: <3142421.5OD9ate9jy@patux.local> Thiago Macieira wrote: > The commercial client will complain to paid support, support will investigate > the issue and figure out what the regression is. And if they can't reproduce it either? > In 5.8, the build deadlocks, so > we can't even just disable a test. How is that even possible? > We'd have to disable all of the code that > uses qdbusxml2cpp, like dbusmenu and dbustray. That's not acceptable. Or you figure out a way to deactivate the venom part of the patch that causes the CI issue, when building on the CI. A bit like how Volkswagen detected testing cycles and activate certain required injection modifications in that case :) Do I have to understand that the CI system also creates the official installer binaries? >> If the regression is not a false alarm you'll end up getting a bug report > > It's not a false alarm. IT's reliably reproduceable in the CI. That doesn't necessarily mean that it means anything. A CI is supposed to be representative of a standard user system but can fail to be. R. From edward.welbourne at qt.io Wed May 3 14:08:49 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 3 May 2017 12:08:49 +0000 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <3142421.5OD9ate9jy@patux.local> References: <1691504.8p7tJBIcV1@bola> <12577474.OERONMxfOn@tjmaciei-mobl1> <2386711.qmUd6InBHh@patux.local> <2160438.bqYSLf8oiV@tjmaciei-mobl1>,<3142421.5OD9ate9jy@patux.local> Message-ID: Thiago Macieira wrote: >> In 5.8, the build deadlocks, so >> we can't even just disable a test. René J. V. Bertin (3 May 2017 13:28) replied: > How is that even possible? We don't know. And yet: https://testresults.qt.io/logs/qt/qtbase/74dfb52faa8370b61de9eb89947bfdd473fe4986/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCqtci-linux-Ubuntu-15.04-x86_64-6e07ddDisableTests_OpenGLES2/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz ... apparently repeatably. So Thiago is, understandably, reticent about moving forward until we can make sense of it. Eddy. From thiago.macieira at intel.com Wed May 3 14:59:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 May 2017 05:59:17 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <3142421.5OD9ate9jy@patux.local> References: <1691504.8p7tJBIcV1@bola> <2160438.bqYSLf8oiV@tjmaciei-mobl1> <3142421.5OD9ate9jy@patux.local> Message-ID: <6671102.me4dhGC0MJ@tjmaciei-mobl1> Em quarta-feira, 3 de maio de 2017, às 04:28:30 PDT, René J. V. Bertin escreveu: > Thiago Macieira wrote: > > The commercial client will complain to paid support, support will > > investigate the issue and figure out what the regression is. > > And if they can't reproduce it either? Then they don't have a problem. > > In 5.8, the build deadlocks, so > > we can't even just disable a test. > > How is that even possible? Beats me. It just did the last two times we tried to stage the fix through the CI. > > We'd have to disable all of the code that > > uses qdbusxml2cpp, like dbusmenu and dbustray. That's not acceptable. > > Or you figure out a way to deactivate the venom part of the patch that > causes the CI issue, when building on the CI. A bit like how Volkswagen > detected testing cycles and activate certain required injection > modifications in that case :) Be my guest if you have any ideas. I'm fresh out of them (and have been for a year). > Do I have to understand that the CI system also creates the official > installer binaries? Yes, it uses the same system. > >> If the regression is not a false alarm you'll end up getting a bug report > > > > It's not a false alarm. IT's reliably reproduceable in the CI. > > That doesn't necessarily mean that it means anything. A CI is supposed to be > representative of a standard user system but can fail to be. True, but it can be reliably reproduced in one system. Of course, experience with Linux distributions shipping the patches indicates that the deadlock does not happen for everyone. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed May 3 15:01:51 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 May 2017 06:01:51 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: References: <1691504.8p7tJBIcV1@bola> <3142421.5OD9ate9jy@patux.local> Message-ID: <3755586.85TL4puMER@tjmaciei-mobl1> Em quarta-feira, 3 de maio de 2017, às 05:08:49 PDT, Edward Welbourne escreveu: > Thiago Macieira wrote: > >> In 5.8, the build deadlocks, so > >> we can't even just disable a test. > > René J. V. Bertin (3 May 2017 13:28) replied: > > How is that even possible? > > We don't know. And yet: > > https://testresults.qt.io/logs/qt/qtbase/74dfb52faa8370b61de9eb89947bfdd473f > e4986/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCqtci-linux-Ubuntu > -15.04-x86_64-6e07ddDisableTests_OpenGLES2/85d6b000f945a84bc84a4f01f53ac65bc > 05cbe86/buildlog.txt.gz > > ... apparently repeatably. So Thiago is, understandably, reticent about > moving forward until we can make sense of it. I could start firing in the dark. For example, one characteristic of the above build that never matches any of my local tests is that it's a cross- compilation to ARM. So we could disable QtDBus by default when cross- compiling. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed May 3 16:02:37 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 03 May 2017 17:02:37 +0300 Subject: [Development] QtWebKit is coming back (part 2) Message-ID: <1711331493820157@web18j.yandex.ru> Hi all, A lot of time has passed since original thread [1]. Lots of work was done since then, and it took much more time than what I've originally planned, however I think now we can use updated QtWebKit as a full replacement of our previous branch that didn't have updates of WebKit engine since Qt 5.2. You can find results of this work in wip/next branch of our QtWebKit repository [2] that is checked by Coin on desktop Linux, macOS, and Windows (both MSVC and MinGW) configurations. QtWebKit Technology Preview 5 [3], based on this branch, is already packaged by Arch Linux [4] and MSYS2 [5], while KaOS Linux distribution ships it as a replacement for old QtWebKit package [6]. It also has had extensive testing by developers and users of such open source projects as PhantomJS [7], Otter Browser [8], Qutebrowser [9]. Lots of bugs were discovered and fixed in the process, a few are not fixed yet but there are no real showstoppers. Major concern, rased in the previous discussion, was feature parity. You can see current status at [10], all major gaps were filled, including support for QML API (WebKit 2) on Windows that was causing concerns previously (it isn't merged to wip/next yet, but works here). There are still a few missing features in QML API, but they affect undocumented experimental part of the API. I propose we should replace contents of dev branch with wip/next as soon as WebKit2/Windows patches are landed. I also think it would be better to release it alongside with Qt 5.9 instead of current 5.9 branch contents to stop proliferation of old insecure WebKit version. I understand that it does not fit into existing schedule of Qt 5.9, however in the previous discussion Lars supported the idea of having independent schedule for QtWebKit Remaining question is versioning. While it's fine to dub current release "5.9" (but not 5.0, because we will have another WebKit update in 5.10 time frame), using Qt versions in QtWebKit has downsides: 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, or is updated 2. It makes people believe that QtWebKit 5.N should be used with Qt 5.N only. QtWebKit supports wide range of Qt versions (starting from 5.2 as of now), and can be used e.g. as security update in Linux distro that does not normally update Qt version during its life cycle. Any comments? ------------------ [1] http://lists.qt-project.org/pipermail/development/2016-June/026156.html [2] https://code.qt.io/qt/qtwebkit.git; it contains snapshots from https://github.com/annulen/webkit with unnecessary files excluded [3] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 [4] https://www.archlinux.org/packages/extra/x86_64/qt5-webkit-ng/ https://www.archlinux.org/packages/extra/i686/qt5-webkit-ng/ [5] http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qtwebkit-tp5-4-any.pkg.tar.xz http://repo.msys2.org/mingw/i686/mingw-w64-i686-qtwebkit-tp5-4-any.pkg.tar.xz [6] http://kaosx.tk/packages/index.php?act=show&subdir=main&sortby=date&file=qtwebkit-tp-5.6.2.3-3-x86_64.pkg.tar.xz [7] http://phantomjs.org/ [8] http://otter-browser.org/ [9] http://qutebrowser.org/ [10] https://github.com/annulen/webkit/wiki/Comparison-with-QtWebKit-5.6 -- Regards, Konstantin From sergio.martins at kdab.com Wed May 3 16:25:42 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Wed, 03 May 2017 15:25:42 +0100 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1711331493820157@web18j.yandex.ru> References: <1711331493820157@web18j.yandex.ru> Message-ID: On 2017-05-03 15:02, Konstantin Tokarev wrote: > Remaining question is versioning. While it's fine to dub current > release "5.9" (but not 5.0, because we will have another WebKit update > in 5.10 time frame), using Qt versions in QtWebKit has downsides: > > 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, > or is updated > 2. It makes people believe that QtWebKit 5.N should be used with Qt > 5.N only. QtWebKit supports wide range of Qt versions (starting from > 5.2 as of now), and can be used e.g. as security update in Linux > distro that does not normally update Qt version during its life cycle. > > Any comments? If Qt and QtWebKit will have different release schedules then that numbering would indeed confuse people. Have you thought about an LTS version too ? What would LTS mean, for QtWebKit ? I think during the LTS lifetime we would still need to update the inner WebKit, for security reasons, (that even happened for QtWebEngine in a 5.6.x patch release). Thanks for your efforts on this! Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From annulen at yandex.ru Wed May 3 17:03:50 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 03 May 2017 18:03:50 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> Message-ID: <1985491493823830@web21o.yandex.ru> 03.05.2017, 17:27, "Sergio Martins" : > On 2017-05-03 15:02, Konstantin Tokarev wrote: >>  Remaining question is versioning. While it's fine to dub current >>  release "5.9" (but not 5.0, because we will have another WebKit update >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >>  or is updated >>  2. It makes people believe that QtWebKit 5.N should be used with Qt >>  5.N only. QtWebKit supports wide range of Qt versions (starting from >>  5.2 as of now), and can be used e.g. as security update in Linux >>  distro that does not normally update Qt version during its life cycle. >> >>  Any comments? > > If Qt and QtWebKit will have different release schedules then that > numbering would indeed confuse people. > > Have you thought about an LTS version too ? What would LTS mean, for > QtWebKit ? I think during the LTS lifetime we would still need to update > the inner WebKit, for security reasons, (that even happened for > QtWebEngine in a 5.6.x patch release). I'm not sure it would be acceptable, because updated QtWebKit requires full C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some features, or with code changes, which were not done yet). Also, there are differences in supported platforms and system requirements. macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is working fine on OS X 10.7, however the oldest officially supported version is 10.10 (as in upstream). I'm pretty sure that WK2 IPC with Mach ports will break when compiling for older targets, though it should be possible to switch to unix sockets just for 5.6. Windows: Windows XP support seems to be feasible, if needed, without new MediaFoundation-based player. Will require backporting Conan-related patches in qt5.git to 5.6 branch. Linux: GStreamer 0.10 is not supported, so official builds with video will have to use QtMultimedia MediaPlayer implementation. I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now because of missing ICU. However, I guess it will be possible to reintroduce QNX support if there are interested folks here, at least Widgets API. All platforms will need to have cmake >= 2.8.12, this might reduce testing coverage for older cmake versions in 5.6 > > Thanks for your efforts on this! > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts -- Regards, Konstantin From aclaure at gmail.com Wed May 3 17:04:53 2017 From: aclaure at gmail.com (Adalid Claure) Date: Wed, 3 May 2017 11:04:53 -0400 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> Message-ID: Does this mean that at some point this new QtWebKit would be packaged with Qt (like in the old days)? On Wed, May 3, 2017 at 10:25 AM, Sergio Martins wrote: > On 2017-05-03 15:02, Konstantin Tokarev wrote: > >> Remaining question is versioning. While it's fine to dub current >> release "5.9" (but not 5.0, because we will have another WebKit update >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >> or is updated >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >> 5.2 as of now), and can be used e.g. as security update in Linux >> distro that does not normally update Qt version during its life cycle. >> >> Any comments? >> > > If Qt and QtWebKit will have different release schedules then that > numbering would indeed confuse people. > > Have you thought about an LTS version too ? What would LTS mean, for > QtWebKit ? I think during the LTS lifetime we would still need to update > the inner WebKit, for security reasons, (that even happened for QtWebEngine > in a 5.6.x patch release). > > > Thanks for your efforts on this! > > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed May 3 17:14:26 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 03 May 2017 18:14:26 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> Message-ID: <2017531493824466@web21o.yandex.ru> 03.05.2017, 18:05, "Adalid Claure" : > Does this mean that at some point this new QtWebKit would be packaged with Qt (like in the old days)? I hope for this (if possible, in 5.9 with Technology preview status ;) Also note that you can already get binaries compatible with Qt 5.8.0 from https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 (but note that TP5 does not include QML API yet) They are built in Coin just like official binaries packaged in Qt SDK. > > On Wed, May 3, 2017 at 10:25 AM, Sergio Martins wrote: >> On 2017-05-03 15:02, Konstantin Tokarev wrote: >> Remaining question is versioning. While it's fine to dub current >> release "5.9" (but not 5.0, because we will have another WebKit update >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >> or is updated >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >> 5.2 as of now), and can be used e.g. as security update in Linux >> distro that does not normally update Qt version during its life cycle. >> >> Any comments? >> >> If Qt and QtWebKit will have different release schedules then that numbering would indeed confuse people. >> >> Have you thought about an LTS version too ? What would LTS mean, for QtWebKit ? I think during the LTS lifetime we would still need to update the inner WebKit, for security reasons, (that even happened for QtWebEngine in a 5.6.x patch release). >> >> Thanks for your efforts on this! >> >> Regards, >> -- >> Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - The Qt, C++ and OpenGL Experts >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From rjvbertin at gmail.com Wed May 3 17:45:42 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 03 May 2017 17:45:42 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: References: <1691504.8p7tJBIcV1@bola> <3142421.5OD9ate9jy@patux.local> Message-ID: <3388292.ESxjsnbB5x@bola> On Wednesday May 03 2017 12:08:49 Edward Welbourne wrote: >https://testresults.qt.io/logs/qt/qtbase/74dfb52faa8370b61de9eb89947bfdd473fe4986/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCqtci-linux-Ubuntu-15.04-x86_64-6e07ddDisableTests_OpenGLES2/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz > >... apparently repeatably. So Thiago is, understandably, reticent about >moving forward until we can make sense of it. Yes, but that also leaves you in a deadlock and I cannot shake the idea that at some point you'll have to move forward to get out of that one. That's on ARM, btw, does it only happen on that platform? Do you at least know where in qdbusxml2cpp something remains stuck (and for how long)? For what it's worth, I cannot remember exactly how I maintained my patch from 5.6.x through 5.7.1 to 5.8.0 - it's possible I refactored it manually. So for giggles or otherwise, I'm attaching what I'm using. R. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-fix-dbus-crash-at-exit.diff.zip Type: application/zip Size: 4606 bytes Desc: not available URL: From thiago.macieira at intel.com Wed May 3 19:44:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 May 2017 10:44:17 -0700 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1985491493823830@web21o.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <1985491493823830@web21o.yandex.ru> Message-ID: <1871907.ZmcG4Fd69f@tjmaciei-mobl1> Em quarta-feira, 3 de maio de 2017, às 08:03:50 PDT, Konstantin Tokarev escreveu: > I'm not sure it would be acceptable, because updated QtWebKit requires full > C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some > features, or with code changes, which were not done yet). > > Also, there are differences in supported platforms and system requirements. > > macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is > working fine on OS X 10.7, however the oldest officially supported version > is 10.10 (as in upstream). I'm pretty sure that WK2 IPC with Mach ports > will break when compiling for older targets, though it should be possible > to switch to unix sockets just for 5.6. > > Windows: Windows XP support seems to be feasible, if needed, without new > MediaFoundation-based player. Will require backporting Conan-related patches > in qt5.git to 5.6 branch. > > Linux: GStreamer 0.10 is not supported, so official builds with video will > have to use QtMultimedia MediaPlayer implementation. > > I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now > because of missing ICU. However, I guess it will be possible to reintroduce > QNX support if there are interested folks here, at least Widgets API. None of those look like deal-breakers. You should be able to: * require C++11 [*] and require newer compilers than 5.6 does * drop support for older platforms (XP, macOS < 10.9, etc.) * require upgraded libraries, like GStreamer Especially if you're going to do releases out of phase with Qt, it should be fine to require more than 5.6 did. And people should just accept it: if you're dealing with something that evolves rapidly and is a security-sensitive, you should be prepared to upgrade your environment quickly too. [*] actually, we should remove the option from configure. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed May 3 19:46:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 May 2017 10:46:34 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <3388292.ESxjsnbB5x@bola> References: <1691504.8p7tJBIcV1@bola> <3388292.ESxjsnbB5x@bola> Message-ID: <5703933.PAeu4HEdtE@tjmaciei-mobl1> Em quarta-feira, 3 de maio de 2017, às 08:45:42 PDT, René J.V. Bertin escreveu: > On Wednesday May 03 2017 12:08:49 Edward Welbourne wrote: > >https://testresults.qt.io/logs/qt/qtbase/74dfb52faa8370b61de9eb89947bfdd473 > >fe4986/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCqtci-linux-Ubun > >tu-15.04-x86_64-6e07ddDisableTests_OpenGLES2/85d6b000f945a84bc84a4f01f53ac6 > >5bc05cbe86/buildlog.txt.gz > > > >... apparently repeatably. So Thiago is, understandably, reticent about > >moving forward until we can make sense of it. > > Yes, but that also leaves you in a deadlock and I cannot shake the idea that > at some point you'll have to move forward to get out of that one. Yep. But my action might not be what you expect. > That's on ARM, btw, does it only happen on that platform? Do you at least > know where in qdbusxml2cpp something remains stuck (and for how long)? You've got all of the information available to us. That's in the link above. > For what it's worth, I cannot remember exactly how I maintained my patch > from 5.6.x through 5.7.1 to 5.8.0 - it's possible I refactored it manually. > So for giggles or otherwise, I'm attaching what I'm using. There was a minor update required for 5.8. I don't remember if 5.7 required anything. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed May 3 19:55:49 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 03 May 2017 20:55:49 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1871907.ZmcG4Fd69f@tjmaciei-mobl1> References: <1711331493820157@web18j.yandex.ru> <1985491493823830@web21o.yandex.ru> <1871907.ZmcG4Fd69f@tjmaciei-mobl1> Message-ID: <139971493834149@web57g.yandex.ru> 03.05.2017, 20:44, "Thiago Macieira" : > Em quarta-feira, 3 de maio de 2017, às 08:03:50 PDT, Konstantin Tokarev > escreveu: >>  I'm not sure it would be acceptable, because updated QtWebKit requires full >>  C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some >>  features, or with code changes, which were not done yet). >> >>  Also, there are differences in supported platforms and system requirements. >> >>  macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is >>  working fine on OS X 10.7, however the oldest officially supported version >>  is 10.10 (as in upstream). I'm pretty sure that WK2 IPC with Mach ports >>  will break when compiling for older targets, though it should be possible >>  to switch to unix sockets just for 5.6. >> >>  Windows: Windows XP support seems to be feasible, if needed, without new >>  MediaFoundation-based player. Will require backporting Conan-related patches >>  in qt5.git to 5.6 branch. >> >>  Linux: GStreamer 0.10 is not supported, so official builds with video will >>  have to use QtMultimedia MediaPlayer implementation. >> >>  I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now >>  because of missing ICU. However, I guess it will be possible to reintroduce >>  QNX support if there are interested folks here, at least Widgets API. > > None of those look like deal-breakers. You should be able to: >  * require C++11 [*] and require newer compilers than 5.6 does >  * drop support for older platforms (XP, macOS < 10.9, etc.) >  * require upgraded libraries, like GStreamer > > Especially if you're going to do releases out of phase with Qt, it should be > fine to require more than 5.6 did. And people should just accept it: if you're > dealing with something that evolves rapidly and is a security-sensitive, you > should be prepared to upgrade your environment quickly too. > > [*] actually, we should remove the option from configure. So, do you think we should update 5.6 branch of QtWebKit with wip/next contents, fix qmake wrapper project to work with Qt 5.6, and raise requirements to whatever it can require with Qt 5.9? That's fine with me. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed May 3 20:24:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 May 2017 11:24:40 -0700 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <139971493834149@web57g.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <1871907.ZmcG4Fd69f@tjmaciei-mobl1> <139971493834149@web57g.yandex.ru> Message-ID: <1824030.iPGYzTqa9g@tjmaciei-mobl1> Em quarta-feira, 3 de maio de 2017, às 10:55:49 PDT, Konstantin Tokarev escreveu: > So, do you think we should update 5.6 branch of QtWebKit with wip/next > contents, fix qmake wrapper project to work with Qt 5.6, and raise > requirements to whatever it can require with Qt 5.9? That's fine with me. No, you should make a different LTS release that works with Qt 5.6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed May 3 20:31:11 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 03 May 2017 21:31:11 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1824030.iPGYzTqa9g@tjmaciei-mobl1> References: <1711331493820157@web18j.yandex.ru> <1871907.ZmcG4Fd69f@tjmaciei-mobl1> <139971493834149@web57g.yandex.ru> <1824030.iPGYzTqa9g@tjmaciei-mobl1> Message-ID: <199761493836271@web60g.yandex.ru> 03.05.2017, 21:25, "Thiago Macieira" : > Em quarta-feira, 3 de maio de 2017, às 10:55:49 PDT, Konstantin Tokarev > escreveu: >>  So, do you think we should update 5.6 branch of QtWebKit with wip/next >>  contents, fix qmake wrapper project to work with Qt 5.6, and raise >>  requirements to whatever it can require with Qt 5.9? That's fine with me. > > No, you should make a different LTS release that works with Qt 5.6. OK > > -- > 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 jani.heikkinen at qt.io Thu May 4 09:17:30 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 4 May 2017 07:17:30 +0000 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <2017531493824466@web21o.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <2017531493824466@web21o.yandex.ru> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Konstantin Tokarev > Sent: keskiviikkona 3. toukokuuta 2017 18.14 > To: Adalid Claure > Cc: development at qt-project.org > Subject: Re: [Development] QtWebKit is coming back (part 2) > > > > 03.05.2017, 18:05, "Adalid Claure" : > > Does this mean that at some point this new QtWebKit would be packaged > with Qt (like in the old days)? > > I hope for this (if possible, in 5.9 with Technology preview status ;) I don't think adding new TP in 5.9 at this point isn't that wise anymore. We have agreed to get all these new submodules (also TP ones) in before FF and so on 5.10 is first option. br, Jani > > Also note that you can already get binaries compatible with Qt 5.8.0 from > > https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 > > (but note that TP5 does not include QML API yet) > > They are built in Coin just like official binaries packaged in Qt SDK. > > > > > On Wed, May 3, 2017 at 10:25 AM, Sergio Martins > wrote: > >> On 2017-05-03 15:02, Konstantin Tokarev wrote: > >> Remaining question is versioning. While it's fine to dub current > >> release "5.9" (but not 5.0, because we will have another WebKit > >> update in 5.10 time frame), using Qt versions in QtWebKit has downsides: > >> > >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, > >> or is updated 2. It makes people believe that QtWebKit 5.N should be > >> used with Qt 5.N only. QtWebKit supports wide range of Qt versions > >> (starting from > >> 5.2 as of now), and can be used e.g. as security update in Linux > >> distro that does not normally update Qt version during its life cycle. > >> > >> Any comments? > >> > >> If Qt and QtWebKit will have different release schedules then that > numbering would indeed confuse people. > >> > >> Have you thought about an LTS version too ? What would LTS mean, for > QtWebKit ? I think during the LTS lifetime we would still need to update the > inner WebKit, for security reasons, (that even happened for QtWebEngine in > a 5.6.x patch release). > >> > >> Thanks for your efforts on this! > >> > >> Regards, > >> -- > >> Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > >> Klarälvdalens Datakonsult AB, a KDAB Group company > >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - > The > >> Qt, C++ and OpenGL Experts > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > , > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From heikki.halmet at qt.io Thu May 4 09:23:46 2017 From: heikki.halmet at qt.io (Heikki Halmet) Date: Thu, 4 May 2017 07:23:46 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY Message-ID: Hi, First of all thank you for all these comments! There was few changes to the ‘proposal changes list’ and here is the summary: 32-bit iOS: will be dropped from CI and will be no longer supported by Qt OSX 10.10: will be dropped from CI, but will be supported by Qt GCC 7: When released it will be tested with some linux distro in CI Clang 4: Do we really need this to be tested with Linux in CI? If yes, then which configuration it will be replaced? Br Heikki Halmet -----Original Message----- From: Development [mailto:development-bounces+heikki.halmet=qt.io at qt-project.org] On Behalf Of Tuukka Turunen Sent: 2. toukokuuta 2017 10:23 To: Jake Petroules ; Lars Knoll Cc: Qt development mailing list Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations changes Hi, While I do agree that having a platform in CI and supporting it for those who have purchased support are not 1:1, in case of dropping the 32-bit iOS from CI for Qt 5.10 it also means that this configuration should no longer be used and not be supported. I do not see much problems with that as we continue to support 32 bit iOS for earlier platforms (until Apple drops it) and the 32 bit iOS devices are already quite old. Yours, Tuukka On 28/04/2017, 19.58, "Jake Petroules" wrote: > On Apr 27, 2017, at 11:28 PM, Lars Knoll wrote: > > >> On 27 Apr 2017, at 16:59, Jake Petroules wrote: >> >>> >>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen wrote: >>> >>> >>> Hi, >>> >>> Related to the Apple platforms, could we consider the following for Qt 5.10: >>> - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) >>> - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support >> >> I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional. > > Agree, there is a difference between the two. > > What I think we should however do for 5.10 is remove 32bit support for iOS from CI and our binary packages. And that means that things will be untested on 32bit iOS, and thus is likely to break at some point. I think 32-bit support on iOS is kind of unlikely to break accidentally, but I agree we should remove it from our binary packages. The iPhone 5 is dead. >> >> As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing… > > For the commercial version, it’s to a large extent up to TQtC to define the support offering. The open source project anyway does not offer any official support for the Qt versions released. All you can do is ask on the mailing lists or file a bug report and hope for the best. Or of course sit down, fix it yourself and submit a patch :) My point was that if a commercial customer goes to support with a bug in a 32-bit build of Qt for iOS, support won't say "we do not support that, go away". They will fix the problem, regardless of the fact that it isn't part of a reference configuration. If a customer sets the minimum deployment target of Qt for iOS to 5.0 and then goes to support saying Qt doesn't work, support WILL tell them "we do not support that (because we deliberately broke it), we can't help you and you'll have to talk to Services and pay money if you want it working that badly". That's the real-world outcome, which is why I don't like using the term "supported" as a synonym for "is a reference configuration in CI". A reference configuration in CI always constitutes something that is supported. However, something that's supported is not necessarily a reference configuration in CI. We should make this clear to our users by not using the term "supported" in a misleading way. > >> >> Something like the following seems nice: >> Tier 1 - the most rigorously tested configurations, tested in CI >> Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI >> Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement > > I’m ok to describe things in tiers, as that’s what we have in practice. We don’t test e.g. FreeBSD in CI, but we will accept patches if something’s broken on that platform and someone cares enough to fix it. Same would be true for 32bit iOS in 5.10 then. But the only thing the Qt project will be able to give some guarantees for are the configurations tested in CI. >> >> Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). > > Dropping it has other benefits. Currently iOS is on the critical path in the CI system for qt5.git integrations and thus package creation. Dropping 32bit support going to significantly cut down on iOS compile times, and should thus lead to faster turn around times for package creation. > > Lars > >> >>> - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one) >> >> Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :) >> >> Current list is: >> - Qt 5.6 - supports macOS 10.7 and up >> - Qt 5.7 - supports macOS 10.8 and up >> - Qt 5.8 - supports macOS 10.9 and up >> - Qt 5.9 - supports macOS 10.10 and up >> >> Planned: >> - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10 >> - Qt 5.11 - supports macOS 10.11 and up >> >> By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported". >> >> If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright. >> >> But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10) >> >>> >>> Yours, >>> >>> Tuukka >>> >>> On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" wrote: >>> >>> >>>> On Apr 27, 2017, at 2:29 AM, Heikki Halmet wrote: >>>> >>>> Hi, >>>> >>>> Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10. >>>> Please comment if the proposal is insufficient or the changes are unacceptable somehow. >>>> >>>> Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html >>>> >>>> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: >>>> RHEL 7.2 -> RHEL 7.3 (Any benefits?) >>>> OpenSUSE 42.1 -> OpenSUSE 42.2 >>>> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) >>>> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) >>> >>> Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. >>> >>>> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) >>> >>> 8.3.2, please. >>> >>>> Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 >>>> Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 >>>> INTEGRITY GHS 2016.5.4 -> 2017.1.x >>>> Support for Android 8 (if available on time) >>>> iOS 11 support (if available on time. Current rumors -> september) >>>> >>>> MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August. >>>> This means that we can only use Preview release of 10.13 for testing before final official release is out. >>>> That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10. >>> >>> How do you know it won't be called macOS 11? ;) >>> >>> The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. >>> >>> Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. >>> >>>> >>>> NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May. >>>> With all others we'll do the best we can but we can't commit that those will be supported in 5.10. >>>> >>>> >>>> >>>> Best regards >>>> Heikki Halmet >>>> >>>> The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland >>>> Email: heikki.halmet at qt.io >>>> Phone: +358408672112 >>>> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petroules at qt.io >>> The Qt Company - Silicon Valley >>> Qbs build tool evangelist - qbs.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> >> -- >> Jake Petroules - jake.petroules at qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andy.shaw at qt.io Thu May 4 09:58:45 2017 From: andy.shaw at qt.io (Andy Shaw) Date: Thu, 4 May 2017 07:58:45 +0000 Subject: [Development] Clarification needed on a crash caused by ignoring ownership of an object Message-ID: <05FDCEBC-FFCE-4B77-AE13-92D875B138A7@qt.io> Hi, I am trying to determine what we should be doing inside Qt in a certain case. When a QUndoCommand is deleted after it has been given another QUndoCommand as a parent it will cause a crash since the parent has not been informed that the child was deleted. The documentation for QUndoCommand is explicit on the fact that when it has a parent the ownership of the QUndoCommand is transferred to its parent. As such I would not expect it to be possible to delete the child directly anymore as a result as we no longer own it. So the question is, since it is still a crash, should we still be accounting for this in the Qt code so as to prevent the crash or is it a case of it is documented to transfer ownership and as such we don’t want to protect against it being deleted out of Qt’s hands? Andy From marc.mutz at kdab.com Thu May 4 10:08:13 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 4 May 2017 10:08:13 +0200 Subject: [Development] Clarification needed on a crash caused by ignoring ownership of an object In-Reply-To: <05FDCEBC-FFCE-4B77-AE13-92D875B138A7@qt.io> References: <05FDCEBC-FFCE-4B77-AE13-92D875B138A7@qt.io> Message-ID: <201705041008.13945.marc.mutz@kdab.com> On Thursday 04 May 2017 09:58:45 Andy Shaw wrote: > Hi, > > I am trying to determine what we should be doing inside Qt in a certain > case. When a QUndoCommand is deleted after it has been given another > QUndoCommand as a parent it will cause a crash since the parent has not > been informed that the child was deleted. The documentation for > QUndoCommand is explicit on the fact that when it has a parent the > ownership of the QUndoCommand is transferred to its parent. As such I > would not expect it to be possible to delete the child directly anymore as > a result as we no longer own it. > > So the question is, since it is still a crash, should we still be > accounting for this in the Qt code so as to prevent the crash or is it a > case of it is documented to transfer ownership and as such we don’t want > to protect against it being deleted out of Qt’s hands? Seeing as about half of the ubsan reports are about shutdown sequences of object hierarchies which allow parent-owned children to be deleted by the user, I'm tempted to say: add an assert (set a flag when the parent deletes a child, check that the flag is set in the child's dtor). OTOH, QObject parent-child relationships, and QTreeWidgetItems set a strong precedent. I'd decide based on how much complexity this adds to the implementation, but if you prepare a patch, the pressure to merge it is going to be a great one. The work is already done, after all. So, please decide yourself. You have my blessing to close as WONTFIX, or else enable the new use-case if it's not too complex (a very subjective criterion, I agree). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From andy.shaw at qt.io Thu May 4 10:14:19 2017 From: andy.shaw at qt.io (Andy Shaw) Date: Thu, 4 May 2017 08:14:19 +0000 Subject: [Development] Clarification needed on a crash caused by ignoring ownership of an object In-Reply-To: <201705041008.13945.marc.mutz@kdab.com> References: <05FDCEBC-FFCE-4B77-AE13-92D875B138A7@qt.io> <201705041008.13945.marc.mutz@kdab.com> Message-ID: <67335C45-EC27-4C0A-BB51-D1B693C6D6AA@qt.io> Thanks Marc, that covers what I needed to know to make a decision ☺ Andy Development på vegne av Marc Mutz skrev følgende den 04.05.2017, 10.08: On Thursday 04 May 2017 09:58:45 Andy Shaw wrote: > Hi, > > I am trying to determine what we should be doing inside Qt in a certain > case. When a QUndoCommand is deleted after it has been given another > QUndoCommand as a parent it will cause a crash since the parent has not > been informed that the child was deleted. The documentation for > QUndoCommand is explicit on the fact that when it has a parent the > ownership of the QUndoCommand is transferred to its parent. As such I > would not expect it to be possible to delete the child directly anymore as > a result as we no longer own it. > > So the question is, since it is still a crash, should we still be > accounting for this in the Qt code so as to prevent the crash or is it a > case of it is documented to transfer ownership and as such we don’t want > to protect against it being deleted out of Qt’s hands? Seeing as about half of the ubsan reports are about shutdown sequences of object hierarchies which allow parent-owned children to be deleted by the user, I'm tempted to say: add an assert (set a flag when the parent deletes a child, check that the flag is set in the child's dtor). OTOH, QObject parent-child relationships, and QTreeWidgetItems set a strong precedent. I'd decide based on how much complexity this adds to the implementation, but if you prepare a patch, the pressure to merge it is going to be a great one. The work is already done, after all. So, please decide yourself. You have my blessing to close as WONTFIX, or else enable the new use-case if it's not too complex (a very subjective criterion, I agree). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Morten.Sorvig at qt.io Thu May 4 14:45:16 2017 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Thu, 4 May 2017 12:45:16 +0000 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: Message-ID: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> Hi, Not sure if I can be of much help, but: - This thread discusses and solves a similar problem: https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application - If this could be reduced to a simple sandboxed-app-with-helper-process test case (no QtWebEngine usage), that that’s something I could look at, and something we could eventually add an autotest for. Morten > On 28 Apr 2017, at 18:49, Adalid Claure wrote: > > I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. > > The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI. > > When the app starts I see the following errors in Console: > > kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 > kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 > QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) > QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) > kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit > > My build process is pretty straight forward: > > 1. Run macdeployqt on the app, using the -appstore-compliant. > 2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file. > 3. Sign QtWebEngineProcess.app with the following entitlements file: > > > > > > com.apple.security.app-sandbox > > com.apple.security.inherit > > > > > 4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2. > > I have tried numerous things all in combination with one another, including: > > a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility) > b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements > c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. > d. tried linking with Qt 5.7 > e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because: > > ------------------------------- > Your app uses or references the following non-public API(s): > > framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit' > : NSAccessibilityUnregisterUniqueIdForUIElement > : _NSAppendToKillRing > : _NSDrawCarbonThemeBezel > : _NSDrawCarbonThemeListBox > : _NSInitializeKillRing > : _NSNewKillRingSequence > : _NSPrependToKillRing > : _NSSetKillRingToYankedState > : _NSYankFromKillRing > > framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices' > : CGSSetDenyWindowServerConnections > : CGSShutdownServerConnections > : CTFontCopyDefaultCascadeList > > The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. > ------------------------------- > > I have chronicled a lot of this in this thread here (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. > > Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine? > > Thanks. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From aclaure at gmail.com Thu May 4 15:11:45 2017 From: aclaure at gmail.com (Adalid Claure) Date: Thu, 4 May 2017 09:11:45 -0400 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> Message-ID: Yeah, I saw that thread and unfortunately the suggestions there didn't help me. I attached a simple app and some other files to this bug I logged: https://bugreports.qt.io/browse/QTBUG-60443 Thanks for your reply! On Thu, May 4, 2017 at 8:45 AM, Morten Sørvig wrote: > Hi, > > Not sure if I can be of much help, but: > > - This thread discusses and solves a similar problem: > https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not- > working-in-sandboxed-application > > - If this could be reduced to a simple sandboxed-app-with-helper-process > test case (no QtWebEngine usage), that that’s something I could look at, > and something we could eventually add an autotest for. > > > Morten > > > > On 28 Apr 2017, at 18:49, Adalid Claure wrote: > > > > I have a desktop app that I have been trying to get onto the Mac App > store but I have been having problems getting it to run in sandbox mode. > For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. > > > > The crux seems to be QtWebEngineProcess.app refuses to run after I > codesign the bundle. As a result, my QtWebEngine component doesn't load. I > am using this QtWebEngine component as part of my app's UI. > > > > When the app starts I see the following errors in Console: > > > > kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup > org.chromium.Chromium.rohitfork.20763 > > kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup > org.chromium.Chromium.rohitfork.20763 > > QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] > bootstrap_look_up: Permission denied (1100) > > QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] > bootstrap_look_up: Permission denied (1100) > > kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) > forbidden-sandbox-reinit > > > > My build process is pretty straight forward: > > > > 1. Run macdeployqt on the app, using the -appstore-compliant. > > 2. Sign all of the Qt Frameworks and PlugIns individually with my app's > entitlement file. > > 3. Sign QtWebEngineProcess.app with the following entitlements file: > > > > > > http://www.apple.com/DTDs/PropertyList-1.0.dtd"> > > > > > > com.apple.security.app-sandbox > > > > com.apple.security.inherit > > > > > > > > > > 4. Call codesign on the overall MyProgram.app bundle with the > entitlements file from Step 2. > > > > I have tried numerous things all in combination with one another, > including: > > > > a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code > (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes. > html#mac-app-store-compatibility) > > b. use macdeployqt's -codesign, even though the binarys have to be > signed a second time after this in order to apply the entitlements > > c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to > 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. > > d. tried linking with Qt 5.7 > > e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by > Apple because: > > > > ------------------------------- > > Your app uses or references the following non-public API(s): > > > > framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/ > AppKit' > > : NSAccessibilityUnregisterUniqueIdForUIElement > > : _NSAppendToKillRing > > : _NSDrawCarbonThemeBezel > > : _NSDrawCarbonThemeListBox > > : _NSInitializeKillRing > > : _NSNewKillRingSequence > > : _NSPrependToKillRing > > : _NSSetKillRingToYankedState > > : _NSYankFromKillRing > > > > framework: '/System/Library/Frameworks/ApplicationServices.framework/ > Versions/A/ApplicationServices' > > : CGSSetDenyWindowServerConnections > > : CGSShutdownServerConnections > > : CTFontCopyDefaultCascadeList > > > > The use of non-public APIs is not permitted on the App Store as it can > lead to a poor user experience should these APIs change. > > ------------------------------- > > > > I have chronicled a lot of this in this thread here ( > https://forum.qt.io/topic/78518/sandbox-app-for-the-mac- > app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. > > > > Does anyone have any suggestions? Does anyone know of any apps on the > Mac App Store that use QtWebEngine? > > > > Thanks. > > _______________________________________________ > > 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 alexandru.croitor at qt.io Thu May 4 15:15:57 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Thu, 4 May 2017 13:15:57 +0000 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> Message-ID: <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> Hi, I'm actually looking into this at the moment, as per the created issue here QTBUG-60443 I haven't completely finished my investigation, which I will post to the bug report. But the gist of it is: - the WebEngine / Chromium sub process calls manually sandbox_init, which is the macOS private API for enabling the sandbox. That interferes with the sandbox which you enable via codesign entitlements, which gives the "sandbox reinit denied' issue, and crashed process. - if the above call is commented out, then you need to make sure that the Qt Application is signed with sandbox setup entitlements, and the WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I couldn't get it to work. - Both of those entitlements have to specify a valid Team ID + prefix in the entitlment com.apple.security.application-groups key. - Google Chrome itself does not enable sandboxing via codesign entitlements, but only enables it for subprocess via sandbox_init, leaving the main process without a sandbox. Thus my preliminary suggestion is not to enable codesign sandboxing for QtWebengine applications. I'm open to discussion on this though. Note that the private API use inside WebEngine, which is removed via appstore_compliant configure switch, is a separate issue from sandboxing. Regards, Alex. On 04 May 2017, at 14:45, Morten Sørvig > wrote: Hi, Not sure if I can be of much help, but: - This thread discusses and solves a similar problem: https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application - If this could be reduced to a simple sandboxed-app-with-helper-process test case (no QtWebEngine usage), that that’s something I could look at, and something we could eventually add an autotest for. Morten On 28 Apr 2017, at 18:49, Adalid Claure > wrote: I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI. When the app starts I see the following errors in Console: kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit My build process is pretty straight forward: 1. Run macdeployqt on the app, using the -appstore-compliant. 2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file. 3. Sign QtWebEngineProcess.app with the following entitlements file: com.apple.security.app-sandbox com.apple.security.inherit 4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2. I have tried numerous things all in combination with one another, including: a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility) b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. d. tried linking with Qt 5.7 e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because: ------------------------------- Your app uses or references the following non-public API(s): framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit' : NSAccessibilityUnregisterUniqueIdForUIElement : _NSAppendToKillRing : _NSDrawCarbonThemeBezel : _NSDrawCarbonThemeListBox : _NSInitializeKillRing : _NSNewKillRingSequence : _NSPrependToKillRing : _NSSetKillRingToYankedState : _NSYankFromKillRing framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices' : CGSSetDenyWindowServerConnections : CGSShutdownServerConnections : CTFontCopyDefaultCascadeList The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. ------------------------------- I have chronicled a lot of this in this thread here (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine? Thanks. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Thu May 4 15:51:45 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 May 2017 16:51:45 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> Message-ID: <401401493905905@web24j.yandex.ru> 03.05.2017, 17:27, "Sergio Martins" : > On 2017-05-03 15:02, Konstantin Tokarev wrote: >>  Remaining question is versioning. While it's fine to dub current >>  release "5.9" (but not 5.0, because we will have another WebKit update >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >>  or is updated >>  2. It makes people believe that QtWebKit 5.N should be used with Qt >>  5.N only. QtWebKit supports wide range of Qt versions (starting from >>  5.2 as of now), and can be used e.g. as security update in Linux >>  distro that does not normally update Qt version during its life cycle. >> >>  Any comments? > > If Qt and QtWebKit will have different release schedules then that > numbering would indeed confuse people. What about choice of new versioning scheme? I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it clear that versioning is different now. Bug fixes will increment patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major verison (7.0 etc.) Qt5 supermodule will be tracking latest available stable branch. When release branch is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. However, I'm not sure about two things: 1) Is it possible to have custom branch names in qtwebkit repository, or there need to be virtual 5.10 etc. branches to match other modules? 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing new release numbers to items fixed in new releases ------------------------ Rationale why using Qt version is not optimal anymore: 1. New QtWebKit is using stable branch of WebKitGTK to simplify maintenance, and plan is to continue doing this in future. Currenly WebKitGTK creates new stable branch twice a year and follows GNOME release schedule. While this more or less matches Qt release schedule, there may be unfortunate cases when schedules mismatch, and WebKit upgrade won't be possible in time. Keeping WebKit not upgraded increases maintenance burden, because it's harder to cherry-pick patches from diverging trunk, and it's not possible anymore to reuse backporting work of WebKitGTK team. In case WebKit upgrade is finished before Qt release, it's highly desirable to allow downstreams (e.g. Linux distros) to get newer version faster. In case WebKit upgrade was skipped for some reason when new Qt release is made, it's important to reflect this in version number as well 2. There may be schedule missses because of lacking man power in QtWebKit team. Like now for example, release is long overdue and it's just unacceptable to hold it for more than half of year again. 3. As I already mentioned in the starting message, surprisingly large number of people believe that QtWebKit x.y is tied to Qt x.y, while it supports a range of Qt versions, and can be used as security update in Linux distros that do not normally update Qt version during their release life cycle. Historically, QtWebKit always supported at least N-1 release of Qt, and versioning scheme used in Qt 4 times since Qt 4.7 (QtWebKit 2.0 - 2.3) better reflected this fact. > > Have you thought about an LTS version too ? What would LTS mean, for > QtWebKit ? I think during the LTS lifetime we would still need to update > the inner WebKit, for security reasons, (that even happened for > QtWebEngine in a 5.6.x patch release). > > Thanks for your efforts on this! > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts -- Regards, Konstantin From thiago.macieira at intel.com Thu May 4 15:52:07 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 06:52:07 -0700 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> <2017531493824466@web21o.yandex.ru> Message-ID: <1886210.LZL4DfVyZ3@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 00:17:30 PDT, Jani Heikkinen escreveu: > > I hope for this (if possible, in 5.9 with Technology preview status > > I don't think adding new TP in 5.9 at this point isn't that wise anymore. We > have agreed to get all these new submodules (also TP ones) in before FF and > so on 5.10 is first option. Fair enough, but QtWebKit can release a TP a little afterwards and just say it's compatible with Qt 5.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 4 15:53:13 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 06:53:13 -0700 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY In-Reply-To: References: Message-ID: <1508297.yj66yaKhXv@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu: > Clang 4: Do we really need this to be tested with Linux in CI? If yes, then > which configuration it will be replaced? I don't think we need to. The macOS builds should be sufficient for almost everything intrinsic to Clang. Those of us who test it on Linux will submit fixes as needed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu May 4 15:54:38 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 May 2017 16:54:38 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1886210.LZL4DfVyZ3@tjmaciei-mobl1> References: <1711331493820157@web18j.yandex.ru> <2017531493824466@web21o.yandex.ru> <1886210.LZL4DfVyZ3@tjmaciei-mobl1> Message-ID: <416131493906078@web24j.yandex.ru> 04.05.2017, 16:52, "Thiago Macieira" : > Em quinta-feira, 4 de maio de 2017, às 00:17:30 PDT, Jani Heikkinen escreveu: >>  > I hope for this (if possible, in 5.9 with Technology preview status >> >>  I don't think adding new TP in 5.9 at this point isn't that wise anymore. We >>  have agreed to get all these new submodules (also TP ones) in before FF and >>  so on 5.10 is first option. > > Fair enough, but QtWebKit can release a TP a little afterwards and just say > it's compatible with Qt 5.9. Will it be possbile to get binary packages into repositories of online SDK updater? > > -- > 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 annulen at yandex.ru Thu May 4 15:58:53 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 May 2017 16:58:53 +0300 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY In-Reply-To: <1508297.yj66yaKhXv@tjmaciei-mobl1> References: <1508297.yj66yaKhXv@tjmaciei-mobl1> Message-ID: <436401493906333@web24j.yandex.ru> 04.05.2017, 16:53, "Thiago Macieira" : > Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu: >>  Clang 4: Do we really need this to be tested with Linux in CI? If yes, then >>  which configuration it will be replaced? > > I don't think we need to. The macOS builds should be sufficient for almost > everything intrinsic to Clang. Those of us who test it on Linux will submit > fixes as needed. But we could have Linux clang configuration with clazy plugin. > > -- > 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 Thu May 4 16:17:09 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 07:17:09 -0700 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <401401493905905@web24j.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> Message-ID: <3700134.KIHc1g5ZgD@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 06:51:45 PDT, Konstantin Tokarev escreveu: > I'm leaning towards "6.0.0" number, because it's larger than any 5.x and > makes it clear that versioning is different now. Bug fixes will increment > patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI > breaking changes - major verison (7.0 etc.) I thought you weren't breaking either source or binary compatibility. So using a new major number sounds wrong. And what would you do when Qt 6 gets released in a couple of years? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 4 16:18:15 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 07:18:15 -0700 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY In-Reply-To: <436401493906333@web24j.yandex.ru> References: <1508297.yj66yaKhXv@tjmaciei-mobl1> <436401493906333@web24j.yandex.ru> Message-ID: <2573613.ja5M7E7B3R@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev escreveu: > But we could have Linux clang configuration with clazy plugin. Why? Clazy is not part of our development philosophy. We should only do that after there's a QUIP explaining which options in Clazy we use (which there isn't). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu May 4 16:21:03 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 May 2017 17:21:03 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <3700134.KIHc1g5ZgD@tjmaciei-mobl1> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <3700134.KIHc1g5ZgD@tjmaciei-mobl1> Message-ID: <353461493907663@web7o.yandex.ru> 04.05.2017, 17:17, "Thiago Macieira" : > Em quinta-feira, 4 de maio de 2017, às 06:51:45 PDT, Konstantin Tokarev > escreveu: >>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and >>  makes it clear that versioning is different now. Bug fixes will increment >>  patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI >>  breaking changes - major verison (7.0 etc.) > > I thought you weren't breaking either source or binary compatibility. Correct. > So using a new major number sounds wrong. Yes. But using 5.$large_number seems wrong too, because there is no hard upper limit for Qt 5.x series > > And what would you do when Qt 6 gets released in a couple of years? There will be QtWebKit 7.x by then, because there are some desirable changes that would break ABI. There is no clear plan yet, though. > > -- > 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 sergio.martins at kdab.com Thu May 4 16:20:55 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 04 May 2017 15:20:55 +0100 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <401401493905905@web24j.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> Message-ID: On 2017-05-04 14:51, Konstantin Tokarev wrote: > 03.05.2017, 17:27, "Sergio Martins" : >> On 2017-05-03 15:02, Konstantin Tokarev wrote: >>>  Remaining question is versioning. While it's fine to dub current >>>  release "5.9" (but not 5.0, because we will have another WebKit >>> update >>>  in 5.10 time frame), using Qt versions in QtWebKit has downsides: >>> >>>  1. It is not clear if 5.N+1 ships with the same WebKit branch as >>> 5.N, >>>  or is updated >>>  2. It makes people believe that QtWebKit 5.N should be used with Qt >>>  5.N only. QtWebKit supports wide range of Qt versions (starting from >>>  5.2 as of now), and can be used e.g. as security update in Linux >>>  distro that does not normally update Qt version during its life >>> cycle. >>> >>>  Any comments? >> >> If Qt and QtWebKit will have different release schedules then that >> numbering would indeed confuse people. > > What about choice of new versioning scheme? > > I'm leaning towards "6.0.0" number, because it's larger than any 5.x > and makes it > clear that versioning is different now. Bug fixes will increment patch > version (6.0.x), > WebKit updates minor version (6.1.x etc), API/ABI breaking changes - > major > verison (7.0 etc.) If you go down that route just make sure 7.0 is out before Qt 6 is released, otherwise it's confusing too. No idea about your other questions. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Thu May 4 16:27:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 07:27:58 -0700 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <353461493907663@web7o.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <3700134.KIHc1g5ZgD@tjmaciei-mobl1> <353461493907663@web7o.yandex.ru> Message-ID: <4805906.tL8109MIlU@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 07:21:03 PDT, Konstantin Tokarev escreveu: > Yes. But using 5.$large_number seems wrong too, because there is no hard > upper limit for Qt 5.x series No, but it's highly unlikely we'll get to 5.20 or 5.100. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sergio.martins at kdab.com Thu May 4 16:34:34 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 04 May 2017 15:34:34 +0100 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY In-Reply-To: <1508297.yj66yaKhXv@tjmaciei-mobl1> References: <1508297.yj66yaKhXv@tjmaciei-mobl1> Message-ID: <9dd76bfcebb36d6eecb65d260423031b@kdab.com> On 2017-05-04 14:53, Thiago Macieira wrote: > Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet > escreveu: >> Clang 4: Do we really need this to be tested with Linux in CI? If yes, >> then >> which configuration it will be replaced? > > I don't think we need to. The macOS builds should be sufficient for > almost > everything intrinsic to Clang. Those of us who test it on Linux will > submit > fixes as needed. We've introduced bugs in the past that would have been caught immediately by clang + Werror if it had been in the CI. clang has warnings that gcc doesn't have. Apple Clang is based on older clang (which one?), so doesn't have all the nice warnings. I don't know the cost of adding it to the CI, so I won't comment on the cost/benefit relation. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Thu May 4 16:50:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 07:50:47 -0700 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY In-Reply-To: <9dd76bfcebb36d6eecb65d260423031b@kdab.com> References: <1508297.yj66yaKhXv@tjmaciei-mobl1> <9dd76bfcebb36d6eecb65d260423031b@kdab.com> Message-ID: <4916519.jJ7g50lKjP@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 07:34:34 PDT, Sergio Martins escreveu: > On 2017-05-04 14:53, Thiago Macieira wrote: > > Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet > > > > escreveu: > >> Clang 4: Do we really need this to be tested with Linux in CI? If yes, > >> then > >> which configuration it will be replaced? > > > > I don't think we need to. The macOS builds should be sufficient for > > almost > > everything intrinsic to Clang. Those of us who test it on Linux will > > submit > > fixes as needed. > > We've introduced bugs in the past that would have been caught > immediately by clang + Werror if it had been in the CI. > clang has warnings that gcc doesn't have. Apple Clang is based on older > clang (which one?), so doesn't have all the nice warnings. I'm not doubting it has benefits. That's why I build with it on my machine. In fact, I build linux-clang more often than macx-clang or win32-msvc. But Heikki's message implies it's not in the CI, so we're not losing anything we had. We're just not adding something we've never had. > I don't know the cost of adding it to the CI, so I won't comment on the > cost/benefit relation. That's exactly the point. The question was: "what should it replace" and I don't think we can confidently say it should replace anything. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu May 4 16:52:24 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 May 2017 17:52:24 +0300 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds Message-ID: <572531493909544@web10g.yandex.ru> Hello, I was told that there is some ongoing work to make subject possible. What is the current status? It is needed because large projects, namely QtWebEngine and QtWebKit (wip/next branch) are too large for making 32-bit debug builds on 32-bit OS. In case of QtWebKit it's possbile to work around this problem by issuing debug info for API implementation only, however this reduces debuggability. -- Regards, Konstantin From sergio.martins at kdab.com Thu May 4 16:51:25 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 04 May 2017 15:51:25 +0100 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY In-Reply-To: <2573613.ja5M7E7B3R@tjmaciei-mobl1> References: <1508297.yj66yaKhXv@tjmaciei-mobl1> <436401493906333@web24j.yandex.ru> <2573613.ja5M7E7B3R@tjmaciei-mobl1> Message-ID: On 2017-05-04 15:18, Thiago Macieira wrote: > Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev > escreveu: >> But we could have Linux clang configuration with clazy plugin. > > Why? Clazy is not part of our development philosophy. We should only do > that > after there's a QUIP explaining which options in Clazy we use (which > there > isn't). Probably the QUIP shouldn't be about clazy /per se/, but about which coding practices we want to enforce via static analysis tooling. clazy's current warning set could be used as a starting base for the discussion though, because it exists. But more about that *later*! There's interesting things in the pipeline which KDAB would like to show first. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From rjvbertin at gmail.com Thu May 4 17:03:47 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 04 May 2017 17:03:47 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <3142421.5OD9ate9jy@patux.local> <3755586.85TL4puMER@tjmaciei-mobl1> Message-ID: <5582529.ly8mcMrLUP@portia.local> Thiago Macieira wrote: > I could start firing in the dark. For example, one characteristic of the above > build that never matches any of my local tests is that it's a cross- > compilation to ARM. So we could disable QtDBus by default when cross- > compiling. I noticed that, and wondered if the issue affects only ARM (cross) builds. Here's another shot in the dark: that's a 64bit Intel host running an ARM cross build, maybe even for 32bit. I don't really know how you run tests on there (emulation?) but couldn't this be something that has to do with endianness and/or 32/64 bit differences? And couldn't it be something that has long been latent but was never triggered in a way that it caused problems? R. From thiago.macieira at intel.com Thu May 4 17:51:49 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 08:51:49 -0700 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds In-Reply-To: <572531493909544@web10g.yandex.ru> References: <572531493909544@web10g.yandex.ru> Message-ID: <2048800.yWSv5JRy2a@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 07:52:24 PDT, Konstantin Tokarev escreveu: > It is needed because large projects, namely QtWebEngine and QtWebKit > (wip/next branch) are too large for making 32-bit debug builds on 32-bit OS. > In case of QtWebKit it's possbile to work around this problem by issuing > debug info for API implementation only, however this reduces debuggability. Way back in Qt 4 times, QtWebKit was never built in debug mode even for debug Qt builds. The library was just too big. I think we should adopt the same policy. The number of people who may want to debug into the WebKit proper code is small. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 4 17:53:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 08:53:21 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <5582529.ly8mcMrLUP@portia.local> References: <1691504.8p7tJBIcV1@bola> <3755586.85TL4puMER@tjmaciei-mobl1> <5582529.ly8mcMrLUP@portia.local> Message-ID: <3180882.6A7jzFKAoh@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 08:03:47 PDT, René J. V. Bertin escreveu: > Here's another shot in the dark: that's a 64bit Intel host running an ARM > cross build, maybe even for 32bit. I don't really know how you run tests on > there (emulation?) but couldn't this be something that has to do with > endianness and/or 32/64 bit differences? And couldn't it be something that > has long been latent but was never triggered in a way that it caused > problems? I think our ARM builds are little-endian, so endianness cannot be an issue. The problem happens before any ARM code is run, so it's not an emulation or processor issue. It must be a cross-compilation (bootstrapping) issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Thu May 4 18:35:13 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 4 May 2017 18:35:13 +0200 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <401401493905905@web24j.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> Message-ID: <20170504163513.GX2928@troll08> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: > 03.05.2017, 17:27, "Sergio Martins" : > > On 2017-05-03 15:02, Konstantin Tokarev wrote: > >>  Remaining question is versioning. While it's fine to dub current > >>  release "5.9" (but not 5.0, because we will have another WebKit update > >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides: > >> > >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, > >>  or is updated > >>  2. It makes people believe that QtWebKit 5.N should be used with Qt > >>  5.N only. QtWebKit supports wide range of Qt versions (starting from > >>  5.2 as of now), and can be used e.g. as security update in Linux > >>  distro that does not normally update Qt version during its life cycle. > >> > >>  Any comments? > > > > If Qt and QtWebKit will have different release schedules then that > > numbering would indeed confuse people. > > What about choice of new versioning scheme? > > I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it > clear that versioning is different now. Bug fixes will increment patch version (6.0.x), > WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major > verison (7.0 etc.) > > Qt5 supermodule will be tracking latest available stable branch. When release branch > is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit > repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. > > However, I'm not sure about two things: > 1) Is it possible to have custom branch names in qtwebkit repository, or there need to > be virtual 5.10 etc. branches to match other modules? > 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing > new release numbers to items fixed in new releases > i'll say outright that you can't be part of the qt supermodule and yet have independent releases. while that was the plan once upon a time, the whole release infrastructure simply doesn't deliver, and even just diverging branch names are a pita (proved by enginio). as a product, qt is as monolithic as ever. your release cycle concerns seem to be centered around the webkit backend, and you can deal with that by lowering the compatibility guarantees of patch releases at this level, i.e. take the freedom to upgrade webkit in a patch release. as long as you keep qt's api/abi compat promises, you're fine. that means that you will not be able to expose new webkit features until the next minor release if they require new api. From rjvbertin at gmail.com Thu May 4 20:06:54 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 04 May 2017 20:06:54 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <3755586.85TL4puMER@tjmaciei-mobl1> <5582529.ly8mcMrLUP@portia.local> <3180882.6A7jzFKAoh@tjmaciei-mobl1> Message-ID: <1526792.ArDH2CLjne@patux.local> Thiago Macieira wrote: > I think our ARM builds are little-endian, so endianness cannot be an issue. > > The problem happens before any ARM code is run, so it's not an emulation or > processor issue. It must be a cross-compilation (bootstrapping) issue. So it cannot be something that has to do with a host application connecting to a dbus daemon running off ARM code? A communications glitch would be the simplest reason for a timeout in IPC context, in this case presumably when disconnecting from a DBus daemon. Something else: a standard llvm/clang install will generate code for ARM on demand without need to install a dedicated cross-compiler. Maybe worth checking if the same issue arises with clang (on a CI system or a developer workstation)? R From annulen at yandex.ru Thu May 4 20:10:00 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 May 2017 21:10:00 +0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1526792.ArDH2CLjne@patux.local> References: <1691504.8p7tJBIcV1@bola> <3755586.85TL4puMER@tjmaciei-mobl1> <5582529.ly8mcMrLUP@portia.local> <3180882.6A7jzFKAoh@tjmaciei-mobl1> <1526792.ArDH2CLjne@patux.local> Message-ID: <241001493921400@web31j.yandex.ru> 04.05.2017, 21:07, "René J. V. Bertin" : > Thiago Macieira wrote: > >>  I think our ARM builds are little-endian, so endianness cannot be an issue. >> >>  The problem happens before any ARM code is run, so it's not an emulation or >>  processor issue. It must be a cross-compilation (bootstrapping) issue. > > So it cannot be something that has to do with a host application connecting to a > dbus daemon running off ARM code? A communications glitch would be the simplest > reason for a timeout in IPC context, in this case presumably when disconnecting > from a DBus daemon. > > Something else: a standard llvm/clang install will generate code for ARM on > demand without need to install a dedicated cross-compiler. ...except that you need target-specific binutils, glibc, kernel headers... > Maybe worth checking > if the same issue arises with clang (on a CI system or a developer workstation)? > > R > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Thu May 4 20:18:28 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 11:18:28 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1526792.ArDH2CLjne@patux.local> References: <1691504.8p7tJBIcV1@bola> <3180882.6A7jzFKAoh@tjmaciei-mobl1> <1526792.ArDH2CLjne@patux.local> Message-ID: <12992969.1AtTstXF0W@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 11:06:54 PDT, René J. V. Bertin escreveu: > Thiago Macieira wrote: > > I think our ARM builds are little-endian, so endianness cannot be an > > issue. > > > > The problem happens before any ARM code is run, so it's not an emulation > > or > > processor issue. It must be a cross-compilation (bootstrapping) issue. > > So it cannot be something that has to do with a host application connecting > to a dbus daemon running off ARM code? A communications glitch would be the > simplest reason for a timeout in IPC context, in this case presumably when > disconnecting from a DBus daemon. How could it be? The problem happens with a host application that is a code generator that doesn't connect to the bus. > Something else: a standard llvm/clang install will generate code for ARM on > demand without need to install a dedicated cross-compiler. Maybe worth > checking if the same issue arises with clang (on a CI system or a developer > workstation)? For someone else. As I said, I don't cross-compile. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu May 4 20:33:44 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 04 May 2017 20:33:44 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <3180882.6A7jzFKAoh@tjmaciei-mobl1> <1526792.ArDH2CLjne@patux.local> <12992969.1AtTstXF0W@tjmaciei-mobl1> Message-ID: <16607722.pm48DqC87D@patux.local> Thiago Macieira wrote: > How could it be? The problem happens with a host application that is a code > generator that doesn't connect to the bus. Indeed. Does it even need to link to QtDbus then? R. From annulen at yandex.ru Thu May 4 21:26:07 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 May 2017 22:26:07 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <20170504163513.GX2928@troll08> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> Message-ID: <362941493925967@web48j.yandex.ru> 04.05.2017, 19:35, "Oswald Buddenhagen" : > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >>  03.05.2017, 17:27, "Sergio Martins" : >>  > On 2017-05-03 15:02, Konstantin Tokarev wrote: >>  >>  Remaining question is versioning. While it's fine to dub current >>  >>  release "5.9" (but not 5.0, because we will have another WebKit update >>  >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides: >>  >> >>  >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >>  >>  or is updated >>  >>  2. It makes people believe that QtWebKit 5.N should be used with Qt >>  >>  5.N only. QtWebKit supports wide range of Qt versions (starting from >>  >>  5.2 as of now), and can be used e.g. as security update in Linux >>  >>  distro that does not normally update Qt version during its life cycle. >>  >> >>  >>  Any comments? >>  > >>  > If Qt and QtWebKit will have different release schedules then that >>  > numbering would indeed confuse people. >> >>  What about choice of new versioning scheme? >> >>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >>  clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >>  WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >>  verison (7.0 etc.) >> >>  Qt5 supermodule will be tracking latest available stable branch. When release branch >>  is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >>  repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >> >>  However, I'm not sure about two things: >>  1) Is it possible to have custom branch names in qtwebkit repository, or there need to >>  be virtual 5.10 etc. branches to match other modules? >>  2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >>  new release numbers to items fixed in new releases > > i'll say outright that you can't be part of the qt supermodule and yet > have independent releases. while that was the plan once upon a time, the > whole release infrastructure simply doesn't deliver, and even just > diverging branch names are a pita (proved by enginio). as a product, qt > is as monolithic as ever. Understood: no custom branch/tag names in official repo. > > your release cycle concerns seem to be centered around the webkit > backend, and you can deal with that by lowering the compatibility > guarantees of patch releases at this level, i.e. take the freedom to > upgrade webkit in a patch release. as long as you keep qt's api/abi > compat promises, you're fine. that means that you will not be able to > expose new webkit features until the next minor release if they require > new api. That's probably fine with me, except 2 moments that seem to require "out of band" releases: 1. Something should be done with current release. As I said, it's not an option to postpone it to 5.10, however it also cannot be released as 5.9.1 because there are API additions which I don't want to revert (in particular because these APIs were already shipped by Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream format of QWebHistory. 2. Security updates. WebKitGTK team provides several patch releases for each stable branch, which contain only fixes for bugs and security issues, and towards the end of release life cycle they became primarily security updates. I think we should be able to release such updates ASAP, by making up some tag name and scheduling custom build against newest patch release of Qt. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Thu May 4 22:26:30 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 13:26:30 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <16607722.pm48DqC87D@patux.local> References: <1691504.8p7tJBIcV1@bola> <12992969.1AtTstXF0W@tjmaciei-mobl1> <16607722.pm48DqC87D@patux.local> Message-ID: <2385006.i13CncZpj1@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 11:33:44 PDT, René J. V. Bertin escreveu: > Thiago Macieira wrote: > > How could it be? The problem happens with a host application that is a > > code > > generator that doesn't connect to the bus. > > Indeed. Does it even need to link to QtDbus then? It links to QtBootstrapDBus. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Thu May 4 23:01:24 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 May 2017 23:01:24 +0200 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds References: <572531493909544@web10g.yandex.ru> Message-ID: Konstantin Tokarev wrote: > It is needed because large projects, namely QtWebEngine and QtWebKit > (wip/next branch) are too large for making 32-bit debug builds on 32-bit > OS. In case of QtWebKit it's possbile to work around this problem by > issuing debug info for API implementation only, however this reduces > debuggability. In Fedora, we use this to build at least SOME debugging information (-g1 level rather than the default -g which exhausts the address space) for QtWebEngine on 32-bit architectures: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n374 http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n395 (Also note that we build with CONFIG+="webcore_debug v8base_debug force_debug_info" or we would not be getting complete debugging information anywhere.) The -g1 trick is probably also workable for QtWebKit if it is hitting the same issue on any GCC target (including MinGW). But I don't know whether Visual C++ has anything comparable. Kevin Kofler From annulen at yandex.ru Thu May 4 23:22:55 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 05 May 2017 00:22:55 +0300 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds In-Reply-To: References: <572531493909544@web10g.yandex.ru> Message-ID: <485881493932975@web7g.yandex.ru> 05.05.2017, 00:01, "Kevin Kofler" : > Konstantin Tokarev wrote: >>  It is needed because large projects, namely QtWebEngine and QtWebKit >>  (wip/next branch) are too large for making 32-bit debug builds on 32-bit >>  OS. In case of QtWebKit it's possbile to work around this problem by >>  issuing debug info for API implementation only, however this reduces >>  debuggability. > > In Fedora, we use this to build at least SOME debugging information (-g1 > level rather than the default -g which exhausts the address space) for > QtWebEngine on 32-bit architectures: > http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n374 > http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n395 > > (Also note that we build with > CONFIG+="webcore_debug v8base_debug force_debug_info" > or we would not be getting complete debugging information anywhere.) > > The -g1 trick is probably also workable for QtWebKit if it is hitting the > same issue on any GCC target (including MinGW). But I don't know whether > Visual C++ has anything comparable. Unfortunately, VS is the worst offender at the moment, it does not have anything like -g1, or like -g0 (i.e. option to negate previously added /Zi) > >         Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Fri May 5 00:11:36 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 May 2017 15:11:36 -0700 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds In-Reply-To: <485881493932975@web7g.yandex.ru> References: <572531493909544@web10g.yandex.ru> <485881493932975@web7g.yandex.ru> Message-ID: <3250030.Gka3H93m88@tjmaciei-mobl1> Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin Tokarev escreveu: > Unfortunately, VS is the worst offender at the moment, it does not have > anything like -g1, or like -g0 (i.e. option to negate previously added /Zi) IIRC, the 32-bit linker is a 32-bit application too if you use "vcvarsall x86". You need a cross-compilation setup, like "vcvarsall x64_x86". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Fri May 5 00:15:59 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 05 May 2017 01:15:59 +0300 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds In-Reply-To: <3250030.Gka3H93m88@tjmaciei-mobl1> References: <572531493909544@web10g.yandex.ru> <485881493932975@web7g.yandex.ru> <3250030.Gka3H93m88@tjmaciei-mobl1> Message-ID: <496841493936159@web57g.yandex.ru> 05.05.2017, 01:11, "Thiago Macieira" : > Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin Tokarev > escreveu: >>  Unfortunately, VS is the worst offender at the moment, it does not have >>  anything like -g1, or like -g0 (i.e. option to negate previously added /Zi) > > IIRC, the 32-bit linker is a 32-bit application too if you use "vcvarsall > x86". > > You need a cross-compilation setup, like "vcvarsall x64_x86". Yes, use 64-bit tools while compiling for 32-bit target. That requires 64-bit OS image to start with. > > -- > 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 jani.heikkinen at qt.io Fri May 5 06:40:44 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 5 May 2017 04:40:44 +0000 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.0' completed Message-ID: > -----Original Message----- > From: Jani Heikkinen > Sent: torstaina 27. huhtikuuta 2017 14.00 > To: development at qt-project.org; releasing at qt-project.org > Subject: HEADS-UP: Branching from '5.9' to '5.9.0' started > > Hi, > We have soft branched '5.9.0' from '5.9'. Please start using '5.9.0' for new > changes targeted to Qt 5.9.0 release. There should be enough time to finalize > ongoing changes in '5.9'; final downmerge will happen Thursday 4th May. > > br, > Jani > Final downmerges are now done(*) and branching is completed. '5.9' is for Qt 5.9.1 from now on and all changes targeted to Qt 5.9.0 release must be done in '5.9.0' br, Jani (*) Webengine were delayed yesterday due to ongoing integrations but most probably finalized now as well From lars.knoll at qt.io Fri May 5 08:52:50 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 5 May 2017 06:52:50 +0000 Subject: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY In-Reply-To: References: <1508297.yj66yaKhXv@tjmaciei-mobl1> <436401493906333@web24j.yandex.ru> <2573613.ja5M7E7B3R@tjmaciei-mobl1> Message-ID: > On 4 May 2017, at 16:51, Sergio Martins wrote: > > On 2017-05-04 15:18, Thiago Macieira wrote: >> Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev >> escreveu: >>> But we could have Linux clang configuration with clazy plugin. >> Why? Clazy is not part of our development philosophy. We should only do that >> after there's a QUIP explaining which options in Clazy we use (which there >> isn't). > > Probably the QUIP shouldn't be about clazy /per se/, but about which coding practices we want to enforce via static analysis tooling. > clazy's current warning set could be used as a starting base for the discussion though, because it exists. This is getting a bit off topic ;-) Enforcing certain coding standards is probably a good idea. And we might be able to enforce more things in CI once the work on the virtualisation layer is done and we can scale up the available hardware. > > But more about that *later*! There's interesting things in the pipeline which KDAB would like to show first. > Looking forward to that :) Cheers, Lars From Simon.Hausmann at qt.io Fri May 5 08:55:07 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 5 May 2017 06:55:07 +0000 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds In-Reply-To: <496841493936159@web57g.yandex.ru> References: <572531493909544@web10g.yandex.ru> <485881493932975@web7g.yandex.ru> <3250030.Gka3H93m88@tjmaciei-mobl1>, <496841493936159@web57g.yandex.ru> Message-ID: Hi, I believe Akseli was making progress on that front. Can you fill us briefly in on the status? Thanks :) Simon > On 5. May 2017, at 00:16, Konstantin Tokarev wrote: > > > > 05.05.2017, 01:11, "Thiago Macieira" : >> Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin Tokarev >> escreveu: >>> Unfortunately, VS is the worst offender at the moment, it does not have >>> anything like -g1, or like -g0 (i.e. option to negate previously added /Zi) >> >> IIRC, the 32-bit linker is a 32-bit application too if you use "vcvarsall >> x86". >> >> You need a cross-compilation setup, like "vcvarsall x64_x86". > > Yes, use 64-bit tools while compiling for 32-bit target. That requires 64-bit OS > image to start with. > >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Fri May 5 09:04:13 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 5 May 2017 07:04:13 +0000 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <362941493925967@web48j.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> Message-ID: <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> Hi, There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. Yours, Tuukka On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" wrote: 04.05.2017, 19:35, "Oswald Buddenhagen" : > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >> 03.05.2017, 17:27, "Sergio Martins" : >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >> >> Remaining question is versioning. While it's fine to dub current >> >> release "5.9" (but not 5.0, because we will have another WebKit update >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >> >> or is updated >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >> >> 5.2 as of now), and can be used e.g. as security update in Linux >> >> distro that does not normally update Qt version during its life cycle. >> >> >> >> Any comments? >> > >> > If Qt and QtWebKit will have different release schedules then that >> > numbering would indeed confuse people. >> >> What about choice of new versioning scheme? >> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >> clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >> verison (7.0 etc.) >> >> Qt5 supermodule will be tracking latest available stable branch. When release branch >> is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >> >> However, I'm not sure about two things: >> 1) Is it possible to have custom branch names in qtwebkit repository, or there need to >> be virtual 5.10 etc. branches to match other modules? >> 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >> new release numbers to items fixed in new releases > > i'll say outright that you can't be part of the qt supermodule and yet > have independent releases. while that was the plan once upon a time, the > whole release infrastructure simply doesn't deliver, and even just > diverging branch names are a pita (proved by enginio). as a product, qt > is as monolithic as ever. Understood: no custom branch/tag names in official repo. > > your release cycle concerns seem to be centered around the webkit > backend, and you can deal with that by lowering the compatibility > guarantees of patch releases at this level, i.e. take the freedom to > upgrade webkit in a patch release. as long as you keep qt's api/abi > compat promises, you're fine. that means that you will not be able to > expose new webkit features until the next minor release if they require > new api. That's probably fine with me, except 2 moments that seem to require "out of band" releases: 1. Something should be done with current release. As I said, it's not an option to postpone it to 5.10, however it also cannot be released as 5.9.1 because there are API additions which I don't want to revert (in particular because these APIs were already shipped by Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream format of QWebHistory. 2. Security updates. WebKitGTK team provides several patch releases for each stable branch, which contain only fixes for bugs and security issues, and towards the end of release life cycle they became primarily security updates. I think we should be able to release such updates ASAP, by making up some tag name and scheduling custom build against newest patch release of Qt. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Fri May 5 09:25:29 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 05 May 2017 10:25:29 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> Message-ID: <1461331493969129@web57j.yandex.ru> 05.05.2017, 10:04, "Tuukka Turunen" : > Hi, > > There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. > > I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. > > For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. Note that qttools submodule depends on QtWebKit (for proper HTML rendering in Qt Assistant). Also, QtWebEngine is require for QtWebView module on Windows/MSVC. BTW, currently QtWebView is unavailable for Windows/MinGW, so it would make sense to add QtWebKit backend as well. That's one reason why we cannot just exclude QtWebKit and QtWebEngine from qt5 supermodule. Other reason is that Coin doesn't seem to be ready to support building projects other than qt5 and its submodules. > > Yours, > >         Tuukka > > On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" wrote: > >     04.05.2017, 19:35, "Oswald Buddenhagen" : >     > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >     >> 03.05.2017, 17:27, "Sergio Martins" : >     >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >     >> >> Remaining question is versioning. While it's fine to dub current >     >> >> release "5.9" (but not 5.0, because we will have another WebKit update >     >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >     >> >> >     >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >     >> >> or is updated >     >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >     >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >     >> >> 5.2 as of now), and can be used e.g. as security update in Linux >     >> >> distro that does not normally update Qt version during its life cycle. >     >> >> >     >> >> Any comments? >     >> > >     >> > If Qt and QtWebKit will have different release schedules then that >     >> > numbering would indeed confuse people. >     >> >     >> What about choice of new versioning scheme? >     >> >     >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >     >> clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >     >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >     >> verison (7.0 etc.) >     >> >     >> Qt5 supermodule will be tracking latest available stable branch. When release branch >     >> is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >     >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >     >> >     >> However, I'm not sure about two things: >     >> 1) Is it possible to have custom branch names in qtwebkit repository, or there need to >     >> be virtual 5.10 etc. branches to match other modules? >     >> 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >     >> new release numbers to items fixed in new releases >     > >     > i'll say outright that you can't be part of the qt supermodule and yet >     > have independent releases. while that was the plan once upon a time, the >     > whole release infrastructure simply doesn't deliver, and even just >     > diverging branch names are a pita (proved by enginio). as a product, qt >     > is as monolithic as ever. > >     Understood: no custom branch/tag names in official repo. > >     > >     > your release cycle concerns seem to be centered around the webkit >     > backend, and you can deal with that by lowering the compatibility >     > guarantees of patch releases at this level, i.e. take the freedom to >     > upgrade webkit in a patch release. as long as you keep qt's api/abi >     > compat promises, you're fine. that means that you will not be able to >     > expose new webkit features until the next minor release if they require >     > new api. > >     That's probably fine with me, except 2 moments that seem to require "out of band" releases: > >     1. Something should be done with current release. As I said, it's not an option to postpone >     it to 5.10, however it also cannot be released as 5.9.1 because there are API additions >     which I don't want to revert (in particular because these APIs were already shipped by >     Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream >     format of QWebHistory. > >     2. Security updates. WebKitGTK team provides several patch releases for each stable branch, >     which contain only fixes for bugs and security issues, and towards the end of release life cycle >     they became primarily security updates. I think we should be able to release such updates ASAP, >     by making up some tag name and scheduling custom build against newest patch release of Qt. > >     > _______________________________________________ >     > Development mailing list >     > Development at qt-project.org >     > http://lists.qt-project.org/mailman/listinfo/development > >     -- >     Regards, >     Konstantin >     _______________________________________________ >     Development mailing list >     Development at qt-project.org >     http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From rjvbertin at gmail.com Fri May 5 10:47:53 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 05 May 2017 10:47:53 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <12992969.1AtTstXF0W@tjmaciei-mobl1> <16607722.pm48DqC87D@patux.local> <2385006.i13CncZpj1@tjmaciei-mobl1> Message-ID: <1938240.ruvVQiKkiH@patux.local> Thiago Macieira wrote: >> Indeed. Does it even need to link to QtDbus then? > > It links to QtBootstrapDBus. That looks like an internal library which itself links to QtDBus, right? Some more thoughts how to work around this: - include only those required bits and pieces into QtBootstrapDBus rather than linking to QtDBus. If the connection-related code isn't required maybe the issue goes away when that code is removed. - do a bogus DBus connect (on ARM) or at least call QtDBusConnection::sessionBus() so there is something to clean up. The most "just" approach might be something like this: - find a way to deactivate the patch on ARM and wait until an ARM user complains about the issue it fixes. It could be just as unlikely that someone will run into the original issue on ARM as someone running into the build issue because of the patch. If we assume that there is now enough indication that the patch is required on Intel; with this approach you wouldn't be withholding it because of a potential issue on ARM. I'll try to figure out if the Debian QtCurve package maintainer(s) know whether they ever encountered the original crash-on-exit on ARM. Something else: > I think our ARM builds are little-endian, so endianness cannot be an issue. My bad, I extrapolated from my Mac/PPC experience that ARM was big-endian and learned only now it is bi-endian (a 1-letter difference with big consequences :)). R. From michal.klocek at qt.io Fri May 5 12:00:57 2017 From: michal.klocek at qt.io (Michal Klocek) Date: Fri, 5 May 2017 12:00:57 +0200 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 Message-ID: Hi With 5.8.0 we released web engine libs which export operator new , new[] , delete, delete[] globally, unfortunately the issue was not spotted in time. https://bugreports.qt.io/browse/QTBUG-60565 With 5.9.0 we plan to correct the issue, unfortunately everything which was compiled against qtwebengine 5.8.0 will be broken when used with 5.9.0 libraries due to missing symbols and needs to be recompiled. Br Michal From sergio.martins at kdab.com Fri May 5 12:27:10 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Fri, 05 May 2017 11:27:10 +0100 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 In-Reply-To: References: Message-ID: <85d247b4013f572435160326b8062727@kdab.com> On 2017-05-05 11:00, Michal Klocek wrote: > Hi > > With 5.8.0 we released web engine libs which export operator new , > new[] , delete, delete[] globally, unfortunately the issue was not > spotted in time. > > https://bugreports.qt.io/browse/QTBUG-60565 > > With 5.9.0 we plan to correct the issue, unfortunately everything which > was compiled against qtwebengine 5.8.0 will be broken when used with > 5.9.0 libraries due to missing symbols and needs to be recompiled. Ouch, this would be a pretty good argument for the 5.8.1 patch release. Now we effectively have a Qt minor version that's ABI incompatible with all others. Too late for that now though. Can we leverage the CI to prevent these kinds of mistakes ? Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From annulen at yandex.ru Fri May 5 12:40:01 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 05 May 2017 13:40:01 +0300 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 In-Reply-To: <85d247b4013f572435160326b8062727@kdab.com> References: <85d247b4013f572435160326b8062727@kdab.com> Message-ID: <2666361493980801@web13j.yandex.ru> 05.05.2017, 13:29, "Sergio Martins" : > On 2017-05-05 11:00, Michal Klocek wrote: >>  Hi >> >>  With 5.8.0 we released web engine libs which export operator new , >>  new[] , delete, delete[] globally, unfortunately the issue was not >>  spotted in time. >> >>  https://bugreports.qt.io/browse/QTBUG-60565 >> >>  With 5.9.0 we plan to correct the issue, unfortunately everything which >>  was compiled against qtwebengine 5.8.0 will be broken when used with >>  5.9.0 libraries due to missing symbols and needs to be recompiled. > > Ouch, this would be a pretty good argument for the 5.8.1 patch release. > Now we effectively have a Qt minor version that's ABI incompatible with > all others. > Too late for that now though. > > Can we leverage the CI to prevent these kinds of mistakes ? There is ABI tracker, maintained by Andrey Ponomarenko, that tracks ABI changes between Qt releases: https://abi-laboratory.pro/tracker/timeline/qt/ However, it seems like QtWebEngine is not tracked. It should be feasible to set up dedicated instance of ABI tracker for Qt CI and track changes in braches right after (or even before) they are merged. > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Fri May 5 13:15:25 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 05 May 2017 14:15:25 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> Message-ID: <2864721493982925@web13j.yandex.ru> 05.05.2017, 10:04, "Tuukka Turunen" : > Hi, > > There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. > > I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. > > For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. BTW, let me bring an attention to the elephant in the room. Yes, my fork of QtWebKit existed for a while as a separate item. But it was never and "official" successor, and even me myself was warning people that it is not an official replacement as some features are not yet restored. However, now there is no valid reason to keep using QtWebKit contained in 5.9 and dev branches anymore. Feature parity is achieved to the level of drop-in replacement that can be applied system-wide. Still many people see 5.9 branch as a source of truth. We need to convey a message to wide audience that old QtWebKit should no longer be used, and that there is a new release that should be used instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., Ubuntu 14.04). This is why question about version numbers and related stuff is important. If this is not done, it doesn't matter at all whatever tag names will be picked and what schedules will be followed. > > Yours, > >         Tuukka > > On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" wrote: > >     04.05.2017, 19:35, "Oswald Buddenhagen" : >     > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >     >> 03.05.2017, 17:27, "Sergio Martins" : >     >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >     >> >> Remaining question is versioning. While it's fine to dub current >     >> >> release "5.9" (but not 5.0, because we will have another WebKit update >     >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >     >> >> >     >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >     >> >> or is updated >     >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >     >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >     >> >> 5.2 as of now), and can be used e.g. as security update in Linux >     >> >> distro that does not normally update Qt version during its life cycle. >     >> >> >     >> >> Any comments? >     >> > >     >> > If Qt and QtWebKit will have different release schedules then that >     >> > numbering would indeed confuse people. >     >> >     >> What about choice of new versioning scheme? >     >> >     >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >     >> clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >     >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >     >> verison (7.0 etc.) >     >> >     >> Qt5 supermodule will be tracking latest available stable branch. When release branch >     >> is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >     >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >     >> >     >> However, I'm not sure about two things: >     >> 1) Is it possible to have custom branch names in qtwebkit repository, or there need to >     >> be virtual 5.10 etc. branches to match other modules? >     >> 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >     >> new release numbers to items fixed in new releases >     > >     > i'll say outright that you can't be part of the qt supermodule and yet >     > have independent releases. while that was the plan once upon a time, the >     > whole release infrastructure simply doesn't deliver, and even just >     > diverging branch names are a pita (proved by enginio). as a product, qt >     > is as monolithic as ever. > >     Understood: no custom branch/tag names in official repo. > >     > >     > your release cycle concerns seem to be centered around the webkit >     > backend, and you can deal with that by lowering the compatibility >     > guarantees of patch releases at this level, i.e. take the freedom to >     > upgrade webkit in a patch release. as long as you keep qt's api/abi >     > compat promises, you're fine. that means that you will not be able to >     > expose new webkit features until the next minor release if they require >     > new api. > >     That's probably fine with me, except 2 moments that seem to require "out of band" releases: > >     1. Something should be done with current release. As I said, it's not an option to postpone >     it to 5.10, however it also cannot be released as 5.9.1 because there are API additions >     which I don't want to revert (in particular because these APIs were already shipped by >     Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream >     format of QWebHistory. > >     2. Security updates. WebKitGTK team provides several patch releases for each stable branch, >     which contain only fixes for bugs and security issues, and towards the end of release life cycle >     they became primarily security updates. I think we should be able to release such updates ASAP, >     by making up some tag name and scheduling custom build against newest patch release of Qt. > >     > _______________________________________________ >     > Development mailing list >     > Development at qt-project.org >     > http://lists.qt-project.org/mailman/listinfo/development > >     -- >     Regards, >     Konstantin >     _______________________________________________ >     Development mailing list >     Development at qt-project.org >     http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From jani.heikkinen at qt.io Fri May 5 13:24:30 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 5 May 2017 11:24:30 +0000 Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files In-Reply-To: References: , Message-ID: Initial change files are now created, please take those over & finalize as soon as possible br, Jani ________________________________________ From: Simon Hausmann Sent: Tuesday, May 2, 2017 5:09 PM To: Jani Heikkinen; development at qt-project.org Subject: Re: MAINTAINERS: your action needed: Qt 5.9.0 change files Hi, I'm a bit confused. The release team usually did the initial commit and maintainers edited the content. I'm fine with doing it myself, but I'm just wondering: Is there an intentional change in procedure? Simon ________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, May 2, 2017 12:26:14 PM To: development at qt-project.org Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files Hi all Maintainers! Branching from '5.9' to '5.9.0' is now ongoing and it is time to start creating change files for Qt 5.9.0. Please do the initial ones as soon as possible. And if some important change is coming in after the initial ones are in change owner can (& have to) update the change file as well. I am hoping we could get the change files now in early enough instead of fighting which these just before release (and even delaying the release because of missing ones...) br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From denis.shienkov at gmail.com Fri May 5 13:28:58 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 May 2017 14:28:58 +0300 Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files In-Reply-To: References: Message-ID: Hi folks,I'm currently have not notifications about the skeleton of change file for qtserialport yet.. Denis 2017-05-05 14:24 GMT+03:00 Jani Heikkinen : > Initial change files are now created, please take those over & finalize as > soon as possible > > br, > Jani > ________________________________________ > From: Simon Hausmann > Sent: Tuesday, May 2, 2017 5:09 PM > To: Jani Heikkinen; development at qt-project.org > Subject: Re: MAINTAINERS: your action needed: Qt 5.9.0 change files > > Hi, > > > I'm a bit confused. The release team usually did the initial commit and > maintainers edited the content. I'm fine with doing it myself, but I'm just > wondering: Is there an intentional change in procedure? > > > > Simon > > ________________________________ > From: Development > on behalf of Jani Heikkinen > Sent: Tuesday, May 2, 2017 12:26:14 PM > To: development at qt-project.org > Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change > files > > Hi all Maintainers! > > Branching from '5.9' to '5.9.0' is now ongoing and it is time to start > creating change files for Qt 5.9.0. Please do the initial ones as soon as > possible. And if some important change is coming in after the initial ones > are in change owner can (& have to) update the change file as well. > > I am hoping we could get the change files now in early enough instead of > fighting which these just before release (and even delaying the release > because of missing ones...) > > br, > Jani > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.roquetto at kdab.com Fri May 5 14:27:20 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Fri, 5 May 2017 09:27:20 -0300 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: <096baaa2-b7c3-0b8d-9007-f721b401b815@pelagicore.com> References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> <83596482-732D-4415-90C9-31F2254C11A2@qt.io> <096baaa2-b7c3-0b8d-9007-f721b401b815@pelagicore.com> Message-ID: <20170505122718.GA5660@orion> It has been 15 days. I will adjust the wiki accordingly. If there is anything else that needs to be done, could someone take care of it? Thanks, Rafael On Thu, Apr 20, 2017 at 04:05:35PM +0200, Bernd Weimer wrote: > Hi, > > I'd like to add that James will act as the sole maintainer for QNX. > I am still listed as co-maintainer along with Rafael at least on paper. > Though, I have been dragged away from QNX even more unfortunately, so > there is no point in keeping this role. > @James: make Qt on QNX great (again)! > > Bernd. > > On 04/19/2017 08:05 PM, James McDonnell wrote: > > I'd be happy to take responsibility for the QNX parts of Qt ;-). > > > > On 2017-04-19, 12:47 PM, "Development on behalf of Lars Knoll" > > > lars.knoll at qt.io> wrote: > > > >> A big thanks from me as well for all you work on maintaining Qt on QNX. > >> > >> James would indeed be a great person to take over this role, but he > >> hasn't said anything himself yet. James, are you willing to take over > >> maintainership for the QNX port? > >> > >> Cheers, > >> Lars > >> > >>> On 19 Apr 2017, at 16:41, Tuukka Turunen wrote: > >>> > >>> > >>> Thanks Rafael for your work on this. I see James very well fit for this > >>> role. > >>> > >>> Yours, > >>> > >>> Tuukka > >>> > >>> On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" > >>> >>> rafael.roquetto at kdab.com> wrote: > >>> > >>> Hello, > >>> > >>> I would like to announce that I am stepping down as the QNX > >>> maintainer. I > >>> would like to propose James McDonnell from QNX for the role. I > >>> believe he is > >>> the right person to carry on the maintenance of QNX on Qt, because: > >>> > >>> * he works for QNX, and therefore has a better contextual > >>> overview of what > >>> needs to be done and considered. > >>> * he has been comitting to Qt on QNX for quite a while, being > >>> even more > >>> active than myself. James is an approver and has been working > >>> on several > >>> fronts, including QtMultimedia, general bugfixing and brigging > >>> excellent > >>> QNX support into QtCreator. > >>> > >>> Long live Qt on QNX! > >>> > >>> Rafael > >>> > >>> -- > >>> Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > >>> Klarälvdalens Datakonsult AB, a KDAB Group company > >>> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > >>> KDAB - Qt Experts > >>> > >>> > >>> _______________________________________________ > >>> Development mailing list > >>> Development at qt-project.org > >>> http://lists.qt-project.org/mailman/listinfo/development > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From rafael.roquetto at kdab.com Fri May 5 14:31:57 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Fri, 5 May 2017 09:31:57 -0300 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: <20170505122718.GA5660@orion> References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> <83596482-732D-4415-90C9-31F2254C11A2@qt.io> <096baaa2-b7c3-0b8d-9007-f721b401b815@pelagicore.com> <20170505122718.GA5660@orion> Message-ID: <20170505123156.GB5660@orion> Ok, apparently I cannot edit the wikipage: "Your edit was aborted by an ArticleSave hook" Can someone do it, then? Thanks, Rafael On Fri, May 05, 2017 at 09:27:20AM -0300, Rafael Roquetto wrote: > It has been 15 days. I will adjust the wiki accordingly. If there is anything > else that needs to be done, could someone take care of it? > > Thanks, > Rafael > > On Thu, Apr 20, 2017 at 04:05:35PM +0200, Bernd Weimer wrote: > > Hi, > > > > I'd like to add that James will act as the sole maintainer for QNX. > > I am still listed as co-maintainer along with Rafael at least on paper. > > Though, I have been dragged away from QNX even more unfortunately, so > > there is no point in keeping this role. > > @James: make Qt on QNX great (again)! > > > > Bernd. > > > > On 04/19/2017 08:05 PM, James McDonnell wrote: > > > I'd be happy to take responsibility for the QNX parts of Qt ;-). > > > > > > On 2017-04-19, 12:47 PM, "Development on behalf of Lars Knoll" > > > > > lars.knoll at qt.io> wrote: > > > > > >> A big thanks from me as well for all you work on maintaining Qt on QNX. > > >> > > >> James would indeed be a great person to take over this role, but he > > >> hasn't said anything himself yet. James, are you willing to take over > > >> maintainership for the QNX port? > > >> > > >> Cheers, > > >> Lars > > >> > > >>> On 19 Apr 2017, at 16:41, Tuukka Turunen wrote: > > >>> > > >>> > > >>> Thanks Rafael for your work on this. I see James very well fit for this > > >>> role. > > >>> > > >>> Yours, > > >>> > > >>> Tuukka > > >>> > > >>> On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" > > >>> > >>> rafael.roquetto at kdab.com> wrote: > > >>> > > >>> Hello, > > >>> > > >>> I would like to announce that I am stepping down as the QNX > > >>> maintainer. I > > >>> would like to propose James McDonnell from QNX for the role. I > > >>> believe he is > > >>> the right person to carry on the maintenance of QNX on Qt, because: > > >>> > > >>> * he works for QNX, and therefore has a better contextual > > >>> overview of what > > >>> needs to be done and considered. > > >>> * he has been comitting to Qt on QNX for quite a while, being > > >>> even more > > >>> active than myself. James is an approver and has been working > > >>> on several > > >>> fronts, including QtMultimedia, general bugfixing and brigging > > >>> excellent > > >>> QNX support into QtCreator. > > >>> > > >>> Long live Qt on QNX! > > >>> > > >>> Rafael > > >>> > > >>> -- > > >>> Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > > >>> Klarälvdalens Datakonsult AB, a KDAB Group company > > >>> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > > >>> KDAB - Qt Experts > > >>> > > >>> > > >>> _______________________________________________ > > >>> Development mailing list > > >>> Development at qt-project.org > > >>> http://lists.qt-project.org/mailman/listinfo/development > > >> > > >> _______________________________________________ > > >> Development mailing list > > >> Development at qt-project.org > > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From lars.knoll at qt.io Fri May 5 14:45:47 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 5 May 2017 12:45:47 +0000 Subject: [Development] Stepping down as the QNX maintainer / proposing James McDonnell In-Reply-To: <20170505123156.GB5660@orion> References: <20170419130517.GA6906@orion> <58C88965-00BC-47E8-BC95-D7F171617E3E@qt.io> <83596482-732D-4415-90C9-31F2254C11A2@qt.io> <096baaa2-b7c3-0b8d-9007-f721b401b815@pelagicore.com> <20170505122718.GA5660@orion> <20170505123156.GB5660@orion> Message-ID: <0C016D81-619E-4BD9-9B68-F3F1FF37D19D@qt.io> Congratulations James! I’ve now updated the wiki page and the maintainers group on gerrit. Cheers, Lars > On 5 May 2017, at 14:31, Rafael Roquetto wrote: > > Ok, apparently I cannot edit the wikipage: "Your edit was aborted by an > ArticleSave hook" > > Can someone do it, then? > > Thanks, > Rafael > > On Fri, May 05, 2017 at 09:27:20AM -0300, Rafael Roquetto wrote: >> It has been 15 days. I will adjust the wiki accordingly. If there is anything >> else that needs to be done, could someone take care of it? >> >> Thanks, >> Rafael >> >> On Thu, Apr 20, 2017 at 04:05:35PM +0200, Bernd Weimer wrote: >>> Hi, >>> >>> I'd like to add that James will act as the sole maintainer for QNX. >>> I am still listed as co-maintainer along with Rafael at least on paper. >>> Though, I have been dragged away from QNX even more unfortunately, so >>> there is no point in keeping this role. >>> @James: make Qt on QNX great (again)! >>> >>> Bernd. >>> >>> On 04/19/2017 08:05 PM, James McDonnell wrote: >>>> I'd be happy to take responsibility for the QNX parts of Qt ;-). >>>> >>>> On 2017-04-19, 12:47 PM, "Development on behalf of Lars Knoll" >>>> >>> lars.knoll at qt.io> wrote: >>>> >>>>> A big thanks from me as well for all you work on maintaining Qt on QNX. >>>>> >>>>> James would indeed be a great person to take over this role, but he >>>>> hasn't said anything himself yet. James, are you willing to take over >>>>> maintainership for the QNX port? >>>>> >>>>> Cheers, >>>>> Lars >>>>> >>>>>> On 19 Apr 2017, at 16:41, Tuukka Turunen wrote: >>>>>> >>>>>> >>>>>> Thanks Rafael for your work on this. I see James very well fit for this >>>>>> role. >>>>>> >>>>>> Yours, >>>>>> >>>>>> Tuukka >>>>>> >>>>>> On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" >>>>>> >>>>> rafael.roquetto at kdab.com> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I would like to announce that I am stepping down as the QNX >>>>>> maintainer. I >>>>>> would like to propose James McDonnell from QNX for the role. I >>>>>> believe he is >>>>>> the right person to carry on the maintenance of QNX on Qt, because: >>>>>> >>>>>> * he works for QNX, and therefore has a better contextual >>>>>> overview of what >>>>>> needs to be done and considered. >>>>>> * he has been comitting to Qt on QNX for quite a while, being >>>>>> even more >>>>>> active than myself. James is an approver and has been working >>>>>> on several >>>>>> fronts, including QtMultimedia, general bugfixing and brigging >>>>>> excellent >>>>>> QNX support into QtCreator. >>>>>> >>>>>> Long live Qt on QNX! >>>>>> >>>>>> Rafael >>>>>> >>>>>> -- >>>>>> Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer >>>>>> Klarälvdalens Datakonsult AB, a KDAB Group company >>>>>> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >>>>>> KDAB - Qt Experts >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - Qt Experts > > > >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > -- > Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kde at carewolf.com Fri May 5 15:43:57 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 5 May 2017 15:43:57 +0200 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 In-Reply-To: References: Message-ID: <201705051543.58146.kde@carewolf.com> On Friday 05 May 2017, Michal Klocek wrote: > Hi > > With 5.8.0 we released web engine libs which export operator new , new[] > , delete, delete[] globally, unfortunately the issue was not spotted in > time. > > https://bugreports.qt.io/browse/QTBUG-60565 > > With 5.9.0 we plan to correct the issue, unfortunately everything which > was compiled against qtwebengine 5.8.0 will be broken when used with > 5.9.0 libraries due to missing symbols and needs to be recompiled. > Note that this primarily affects Linux, but since BC is mainly important for Linux that doesn't help much. The issue trigger because Qt exports symbols with the Qt_5 tag, so applications that used the overridden new/delete operators will be looking not just for new and delete, but new and delete with the Qt_5 tag. Best regards `Allan From thiago.macieira at intel.com Fri May 5 15:56:22 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 May 2017 06:56:22 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1938240.ruvVQiKkiH@patux.local> References: <1691504.8p7tJBIcV1@bola> <2385006.i13CncZpj1@tjmaciei-mobl1> <1938240.ruvVQiKkiH@patux.local> Message-ID: <5244423.eq0l33cDAR@tjmaciei-mobl1> Em sexta-feira, 5 de maio de 2017, às 01:47:53 PDT, René J. V. Bertin escreveu: > Thiago Macieira wrote: > >> Indeed. Does it even need to link to QtDbus then? > > > > It links to QtBootstrapDBus. > > That looks like an internal library which itself links to QtDBus, right? No, it's a bootstrapped version of QtDBus so that qdbusxml2cpp and qdbuscpp2xml can be bootstrapped too and run as a host binaray during cross- compilation. It's also built during a regular -developer-built but not used by anything, just so that I wouldn't make changes that would break that bootstrapped built, which like I said I never use. > Some more thoughts how to work around this: > - include only those required bits and pieces into QtBootstrapDBus rather > than linking to QtDBus. If the connection-related code isn't required maybe > the issue goes away when that code is removed. That's already how it is. > - do a bogus DBus connect (on ARM) or at least call > QtDBusConnection::sessionBus() so there is something to clean up. There's no connect in the first place. QtBootstrapDBus is just the XML parsing and metaobject generation code, along with the base metatype support. It's that base metatype support that was affected by one of the patches and must be the reason why the deadlock happens. > The most "just" approach might be something like this: > - find a way to deactivate the patch on ARM and wait until an ARM user > complains about the issue it fixes. It could be just as unlikely that > someone will run into the original issue on ARM as someone running into the > build issue because of the patch. Be my guest. I can't test this, so I don't have a way to even try whether it worked. I won't waste my time and my reviewes' time by submitting patches, waiting for +2, then staging only to find out that it doesn't fix anything. > If we assume that there is now enough indication that the patch is required > on Intel; with this approach you wouldn't be withholding it because of a > potential issue on ARM. The patch is required everywhere, as you've found out. Without it, QtDBus applications crash on exit. > I'll try to figure out if the Debian QtCurve package maintainer(s) know > whether they ever encountered the original crash-on-exit on ARM. Because it's not architecture dependent. I told you yesterday, "The problem happens before any ARM code is run, so it's not an emulation or processor issue. It must be a cross-compilation (bootstrapping) issue." -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri May 5 16:19:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 May 2017 07:19:06 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1691504.8p7tJBIcV1@bola> References: <1691504.8p7tJBIcV1@bola> Message-ID: <1701995.0fgXlvrcbm@tjmaciei-mobl1> Em sexta-feira, 28 de abril de 2017, às 02:32:04 PDT, René J.V. Bertin escreveu: > Together with the principal maintainer I am looking into issues in a style > plugin related to its use of DBus (to be informed of desktop-wide changes): > > https://bugs.kde.org/show_bug.cgi?id=363753 i don't know if anyone else noticed, but the backtraces have no QtDBus in them. Well, I did when the bug was actually reported. Took me less than a minute to realise that, then figure out what the issue was and submit a patch. https://codereview.qt-project.org/193448 It's now integrated for 5.9.1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Sat May 6 11:06:26 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 06 May 2017 11:06:26 +0200 Subject: [Development] XCB QPA standalone building Message-ID: <1611846.1ZBh8WT8Zq@bola> Hi, As you may remember I've been spending some time creating a standalone-build project for a personalised fork of the Cocoa QPA (and Mac style) plugin. This turned out to be relatively easy and given how the QPA architecture one doesn't even need to overwrite the official plugin (please don't change that :) ) I've taken a quick look into doing the same with the XCB plugin, hoping I could make it easier to allow other interested Mac users to use Qt under XQuartz, but it seems that it's a lot more complicated to build that plugin outside of a QtBase build. Yet I know the plugin can be taken from a QtBase/XCB build and used with a QtBase/Cocoa build. That approach works well enough for instance to use KDE's Konsole as a modern alternative to XTerm (used by a surprising number of Mac users!) - locally or even remotely. (And look-and-feel purists can even use the Macintosh style ;) ). Should I just drop this or are there tweaks to the .pro file or qmake invocation that would make a standalone build possible? Thanks, R. From rjvbertin at gmail.com Sat May 6 14:14:30 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 06 May 2017 14:14:30 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <2385006.i13CncZpj1@tjmaciei-mobl1> <1938240.ruvVQiKkiH@patux.local> <5244423.eq0l33cDAR@tjmaciei-mobl1> Message-ID: <35586444.9HtKVlGZy5@portia.local> Thiago Macieira wrote: > Be my guest. I can't test this, so I don't have a way to even try whether it Actually I think you could. Testing this would mean implementing a version of the patches that does nothing on ARM, and then getting that to run that on the ARM CI. The only thing I could possibly do in this approach is implemented the alternative patch, from there on the ball would still be in your camp. > The patch is required everywhere, as you've found out. Without it, QtDBus > applications crash on exit. Have I? In my experience it only happens under specific conditions, and I've never seen evidence that it happens on other architectures. It does seem reasonable to expect that it will. > Because it's not architecture dependent. I told you yesterday, "The problem > happens before any ARM code is run, so it's not an emulation or processor > issue. It must be a cross-compilation (bootstrapping) issue." I can read, thank you :) That's the CI issue, the original issue is the QtDBus crash-on-exit. But since you repeat this: what's different with that xml2cpp code generator in the cross-compilation setting? Does it contain/run ARM-conditional code (built for X86), for instance? Is there no way to figure that out without doing a full- fledged cross build? Can't you fetch the executable from the CI and run it on a regular developer workstation, or possibly the entire build tree? Lastly, can't the CI be set up to generate a stack backtrace of applications that it kills (supposing you don't already have one)? I think I'm going to stop firing in the dark... R From thiago.macieira at intel.com Sat May 6 17:00:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 06 May 2017 08:00:50 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <35586444.9HtKVlGZy5@portia.local> References: <1691504.8p7tJBIcV1@bola> <5244423.eq0l33cDAR@tjmaciei-mobl1> <35586444.9HtKVlGZy5@portia.local> Message-ID: <1963160.3oN18OL0Sd@tjmaciei-mobl1> On Saturday, 6 May 2017 05:14:30 PDT René J. V. Bertin wrote: > But since you repeat this: what's different with that xml2cpp code generator > in the cross-compilation setting? Does it contain/run ARM-conditional code > (built for X86), for instance? Is there no way to figure that out without > doing a full- fledged cross build? At the risk of repeating myself, it has nothing to do with ARM. The difference is that in a cross-compilation setting, qdbusxml2cpp links to libQtBootstrapDBus instead of libQtDBus. The question is: what is causing the bootstrapped build of QtDBus to deadlock? > Can't you fetch the executable from the CI and run it on a regular developer > workstation, or possibly the entire build tree? Someone could do that. I'd even appreciate just a backtrace from the deadlocked application. > Lastly, can't the CI be set up to generate a stack backtrace of applications > that it kills (supposing you don't already have one)? That would be a good idea. It's happened recently for another situation and it would be useful. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Sat May 6 21:20:29 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 06 May 2017 21:20:29 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <5244423.eq0l33cDAR@tjmaciei-mobl1> <35586444.9HtKVlGZy5@portia.local> <1963160.3oN18OL0Sd@tjmaciei-mobl1> Message-ID: <3505165.6JFxzgKi5W@patux.local> Thiago Macieira wrote: > At the risk of repeating myself, it has nothing to do with ARM. Does it happen on any of the other builders? If so, apologies, if someone had pointed that out I wouldn't have fixated so much on ARM. > The difference is that in a cross-compilation setting, qdbusxml2cpp links to > libQtBootstrapDBus instead of libQtDBus. The question is: what is causing the > bootstrapped build of QtDBus to deadlock? How hard is it to make a bootstrapped build of qdbusxml2cpp? If that's feasible without setting up a cross-compilation setting I could try that. BTW, is it possible to set up things for a "fake" cross build, i.e. one that targets the host platform? > Someone could do that. I'd even appreciate just a backtrace from the > deadlocked application. At the risk of me repeating myself again: there's an internal act to get together here ... R From thiago.macieira at intel.com Sat May 6 21:48:57 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 06 May 2017 12:48:57 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <3505165.6JFxzgKi5W@patux.local> References: <1691504.8p7tJBIcV1@bola> <1963160.3oN18OL0Sd@tjmaciei-mobl1> <3505165.6JFxzgKi5W@patux.local> Message-ID: <1930463.8hztgAgGOn@tjmaciei-mobl1> On Saturday, 6 May 2017 12:20:29 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > At the risk of repeating myself, it has nothing to do with ARM. > > Does it happen on any of the other builders? If so, apologies, if someone > had pointed that out I wouldn't have fixated so much on ARM. There are two problems with that question: First, because the CI stops at the moment the first problem happens. So we don't know where else it may have happened. We only know where it did happen. Second, compiling to ARM requires cross-compilation. Since the problem happens because of cross-compilation, it happens for all ARM builds. > > The difference is that in a cross-compilation setting, qdbusxml2cpp links > > to libQtBootstrapDBus instead of libQtDBus. The question is: what is > > causing the bootstrapped build of QtDBus to deadlock? > > How hard is it to make a bootstrapped build of qdbusxml2cpp? If that's > feasible without setting up a cross-compilation setting I could try that. Not very. You're welcome to try. But I think I tried this last year and couldn't reproduce the problem, though it was with 5.6, not 5.8. All you need to do is attempt a cross-compilation. > BTW, is it possible to set up things for a "fake" cross build, i.e. one that > targets the host platform? Yes. You can also cd src; qmake -config force_bootstrap. > > Someone could do that. I'd even appreciate just a backtrace from the > > deadlocked application. > > At the risk of me repeating myself again: there's an internal act to get > together here ... Internal to me? I don't think looking at my bowels will help. If you meant someone else or some company, it seems no one else is interested. The Linux distributions are satisified with the patch and haven't seen any regressions because of it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat May 6 22:06:59 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 06 May 2017 13:06:59 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1930463.8hztgAgGOn@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <3505165.6JFxzgKi5W@patux.local> <1930463.8hztgAgGOn@tjmaciei-mobl1> Message-ID: <5106876.IVyibe7A3X@tjmaciei-mobl1> On Saturday, 6 May 2017 12:48:57 PDT Thiago Macieira wrote: > First, because the CI stops at the moment the first problem happens. So we > don't know where else it may have happened. We only know where it did > happen. > > Second, compiling to ARM requires cross-compilation. Since the problem > happens because of cross-compilation, it happens for all ARM builds. Ok, here you go: I've just removed the ability to cross-compile QtDBus, which in turn removes the need for a bootstrapped QtDBus and its tools in the first place. https://codereview.qt-project.org/193827 Since I'm the maintainer for QtDBus, I've used my own maintainer privilege and self-approved. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Sun May 7 11:57:09 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 07 May 2017 11:57:09 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <3505165.6JFxzgKi5W@patux.local> <1930463.8hztgAgGOn@tjmaciei-mobl1> <5106876.IVyibe7A3X@tjmaciei-mobl1> Message-ID: <3512390.f7kP34Lxkh@portia.local> Thiago Macieira wrote: > > First, because the CI stops at the moment the first problem happens. So we > > don't know where else it may have happened. We only know where it did happen. Oh, right. I assumed that there were independent builders for the different platforms. > Ok, here you go: I've just removed the ability to cross-compile QtDBus, which > in turn removes the need for a bootstrapped QtDBus and its tools in the first > place. That's another solution - one that has the power to force users who do cross- compile and want QtDBus to step out of the shadows and provide the missing info. :) R. From ville.voutilainen at gmail.com Sun May 7 12:20:26 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sun, 7 May 2017 13:20:26 +0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1930463.8hztgAgGOn@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <1963160.3oN18OL0Sd@tjmaciei-mobl1> <3505165.6JFxzgKi5W@patux.local> <1930463.8hztgAgGOn@tjmaciei-mobl1> Message-ID: On 6 May 2017 at 22:48, Thiago Macieira wrote: > Second, compiling to ARM requires cross-compilation. Since the problem happens > because of cross-compilation, it happens for all ARM builds. Perhaps we should get ARM hardware so that we can do ARM builds without cross-compilation. :) From rjvbertin at gmail.com Sun May 7 17:36:56 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 07 May 2017 17:36:56 +0200 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? References: <1691504.8p7tJBIcV1@bola> <1963160.3oN18OL0Sd@tjmaciei-mobl1> <3505165.6JFxzgKi5W@patux.local> <1930463.8hztgAgGOn@tjmaciei-mobl1> Message-ID: <1531331.JO7kOOMFRB@portia.local> Ville Voutilainen wrote: > Perhaps we should get ARM hardware so that we can do ARM builds > without cross-compilation. :) Not a single Qt dev who'd be willing to donate his/her old phone or Raspberry for this purpose? ;) From ville.voutilainen at gmail.com Sun May 7 18:05:43 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sun, 7 May 2017 19:05:43 +0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1531331.JO7kOOMFRB@portia.local> References: <1691504.8p7tJBIcV1@bola> <1963160.3oN18OL0Sd@tjmaciei-mobl1> <3505165.6JFxzgKi5W@patux.local> <1930463.8hztgAgGOn@tjmaciei-mobl1> <1531331.JO7kOOMFRB@portia.local> Message-ID: On 7 May 2017 at 18:36, René J. V. Bertin wrote: > Ville Voutilainen wrote: > >> Perhaps we should get ARM hardware so that we can do ARM builds >> without cross-compilation. :) > > Not a single Qt dev who'd be willing to donate his/her old phone or Raspberry > for this purpose? ;) I was actually thinking of something along the lines of https://www.qualcomm.com/news/releases/2016/12/07/qualcomm-begins-commercial-sampling-worlds-first-10nm-server-processor-and But even with such options potentially becoming available, it would be rather good if cross-compilation worked. From thiago.macieira at intel.com Sun May 7 18:23:30 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 May 2017 09:23:30 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: References: <1691504.8p7tJBIcV1@bola> <1930463.8hztgAgGOn@tjmaciei-mobl1> Message-ID: <1713233.tW3J3EN1SE@tjmaciei-mobl1> On Sunday, 7 May 2017 03:20:26 PDT Ville Voutilainen wrote: > On 6 May 2017 at 22:48, Thiago Macieira wrote: > > Second, compiling to ARM requires cross-compilation. Since the problem > > happens because of cross-compilation, it happens for all ARM builds. > > Perhaps we should get ARM hardware so that we can do ARM builds > without cross-compilation. :) You can always just do an emulated build (with qemu). This is how most distributions build for non-x86, since most software cannot cross-compile. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sun May 7 21:26:02 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 07 May 2017 22:26:02 +0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1713233.tW3J3EN1SE@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <1930463.8hztgAgGOn@tjmaciei-mobl1> <1713233.tW3J3EN1SE@tjmaciei-mobl1> Message-ID: <6174811494185162@web27o.yandex.ru> 07.05.2017, 19:24, "Thiago Macieira" : > On Sunday, 7 May 2017 03:20:26 PDT Ville Voutilainen wrote: >>  On 6 May 2017 at 22:48, Thiago Macieira wrote: >>  > Second, compiling to ARM requires cross-compilation. Since the problem >>  > happens because of cross-compilation, it happens for all ARM builds. >> >>  Perhaps we should get ARM hardware so that we can do ARM builds >>  without cross-compilation. :) > > You can always just do an emulated build (with qemu). This is how most > distributions build for non-x86, since most software cannot cross-compile. That's rather strong claim. I would say that most of open-source software can be cross-compiled, and distributions use emulation because it's not 100%, and because their tooling is not adjusted for cross-compilation. OTOH there are "distributions" focused entirely on cross-compilation, e.g. Buildroot and Yocto. I'm doing embedded software development, and wouldn't even consider including emulated builds into my pipeline. > > -- > 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 Sun May 7 21:42:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 May 2017 12:42:19 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <6174811494185162@web27o.yandex.ru> References: <1691504.8p7tJBIcV1@bola> <1713233.tW3J3EN1SE@tjmaciei-mobl1> <6174811494185162@web27o.yandex.ru> Message-ID: <6420371.EkLhfIdTAI@tjmaciei-mobl1> On Sunday, 7 May 2017 12:26:02 PDT Konstantin Tokarev wrote: > I'm doing embedded software development, and wouldn't even consider > including emulated builds into my pipeline. Then if you have a need for QtDBus, you'll maybe step up and help us solve this one-year-old issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sun May 7 21:43:39 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 07 May 2017 22:43:39 +0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <6420371.EkLhfIdTAI@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <1713233.tW3J3EN1SE@tjmaciei-mobl1> <6174811494185162@web27o.yandex.ru> <6420371.EkLhfIdTAI@tjmaciei-mobl1> Message-ID: <6103211494186219@web6j.yandex.ru> 07.05.2017, 22:43, "Thiago Macieira" : > On Sunday, 7 May 2017 12:26:02 PDT Konstantin Tokarev wrote: >>  I'm doing embedded software development, and wouldn't even consider >>  including emulated builds into my pipeline. > > Then if you have a need for QtDBus, you'll maybe step up and help us solve > this one-year-old issue. No, I don't use dbus > > -- > 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 8 05:43:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 May 2017 20:43:42 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <6103211494186219@web6j.yandex.ru> References: <1691504.8p7tJBIcV1@bola> <6420371.EkLhfIdTAI@tjmaciei-mobl1> <6103211494186219@web6j.yandex.ru> Message-ID: <5124729.Q6y0gz0QNF@tjmaciei-mobl1> On Sunday, 7 May 2017 12:43:39 PDT Konstantin Tokarev wrote: > 07.05.2017, 22:43, "Thiago Macieira" : > > On Sunday, 7 May 2017 12:26:02 PDT Konstantin Tokarev wrote: > >> I'm doing embedded software development, and wouldn't even consider > >> including emulated builds into my pipeline. > > > > Then if you have a need for QtDBus, you'll maybe step up and help us solve > > this one-year-old issue. > > No, I don't use dbus Yeah, like I said, no one who does is affected by the regression. That's why I am disabling the cross-compilation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sergio.martins at kdab.com Mon May 8 07:56:53 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Mon, 08 May 2017 06:56:53 +0100 Subject: [Development] =?utf-8?q?DBus_signals_for_=28dlclose=27d=29_style?= =?utf-8?q?_plugin_causing_crash_during_application_exit=3F?= In-Reply-To: <1963160.3oN18OL0Sd@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <5244423.eq0l33cDAR@tjmaciei-mobl1> <35586444.9HtKVlGZy5@portia.local> <1963160.3oN18OL0Sd@tjmaciei-mobl1> Message-ID: On 2017-05-06 16:00, Thiago Macieira wrote: > Someone could do that. I'd even appreciate just a backtrace from the > deadlocked application. Have you asked the CI guys for such backtrace ? Why isn't there a JIRA issue for this ? Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From lars.knoll at qt.io Mon May 8 08:38:33 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 8 May 2017 06:38:33 +0000 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 In-Reply-To: <201705051543.58146.kde@carewolf.com> References: <201705051543.58146.kde@carewolf.com> Message-ID: Hi, why can't we just keep these symbols around without exporting them through a header file and make them simply forward to the global new/delete operators? If we don't export them in a header at least newly compiled code would stop using them, and old code would continue working like that. Cheers, Lars > On 5 May 2017, at 15:43, Allan Sandfeld Jensen wrote: > > On Friday 05 May 2017, Michal Klocek wrote: >> Hi >> >> With 5.8.0 we released web engine libs which export operator new , new[] >> , delete, delete[] globally, unfortunately the issue was not spotted in >> time. >> >> https://bugreports.qt.io/browse/QTBUG-60565 >> >> With 5.9.0 we plan to correct the issue, unfortunately everything which >> was compiled against qtwebengine 5.8.0 will be broken when used with >> 5.9.0 libraries due to missing symbols and needs to be recompiled. >> > Note that this primarily affects Linux, but since BC is mainly important for > Linux that doesn't help much. > > The issue trigger because Qt exports symbols with the Qt_5 tag, so > applications that used the overridden new/delete operators will be looking not > just for new and delete, but new and delete with the Qt_5 tag. > > Best regards > `Allan > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon May 8 08:47:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 May 2017 23:47:01 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: References: <1691504.8p7tJBIcV1@bola> <1963160.3oN18OL0Sd@tjmaciei-mobl1> Message-ID: <1898980.is4RtUE86b@tjmaciei-mobl1> On Sunday, 7 May 2017 22:56:53 PDT Sergio Martins wrote: > On 2017-05-06 16:00, Thiago Macieira wrote: > > Someone could do that. I'd even appreciate just a backtrace from the > > deadlocked application. > > Have you asked the CI guys for such backtrace ? Why isn't there a JIRA > issue for this ? I asked for anyone who could reproduce the issue to help and no one did. And until this discussion now, I had not realised it was connected to cross- compilation -- though in fact we have not proven it, it's just a very good theory. As for a JIRA task to get backtraces from crashed or stuck applications, it again hadn't seemed necessary so far. The qmake crash that we saw this week was only the second time that it would have been helpful. Well... that and all those moc crashes we experienced for a year. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kari.oikarinen at qt.io Mon May 8 08:56:19 2017 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Mon, 8 May 2017 09:56:19 +0300 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1898980.is4RtUE86b@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <1963160.3oN18OL0Sd@tjmaciei-mobl1> <1898980.is4RtUE86b@tjmaciei-mobl1> Message-ID: <88f83d99-e66d-0462-a3a8-8f3e44d5125e@qt.io> On 08.05.2017 09:47, Thiago Macieira wrote: > On Sunday, 7 May 2017 22:56:53 PDT Sergio Martins wrote: >> On 2017-05-06 16:00, Thiago Macieira wrote: >>> Someone could do that. I'd even appreciate just a backtrace from the >>> deadlocked application. >> >> Have you asked the CI guys for such backtrace ? Why isn't there a JIRA >> issue for this ? > > I asked for anyone who could reproduce the issue to help and no one did. And > until this discussion now, I had not realised it was connected to cross- > compilation -- though in fact we have not proven it, it's just a very good > theory. > > As for a JIRA task to get backtraces from crashed or stuck applications, it > again hadn't seemed necessary so far. The qmake crash that we saw this week > was only the second time that it would have been helpful. > > Well... that and all those moc crashes we experienced for a year. > The failures of https://codereview.qt-project.org/#/c/180231/ and https://codereview.qt-project.org/#/c/180232/ happened on Ubuntu Touch builds. That platform is not part of 5.9 CI anymore. So as far as I understand it hasn't been tried if the patches could successfully integrate into 5.9? Disabling cross-compilation of QtDBus would break a lot of users. (Including Qt for Device Creation builds.) So hopefully we can find some other way. -- Kari From thiago.macieira at intel.com Mon May 8 08:59:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 May 2017 23:59:43 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <88f83d99-e66d-0462-a3a8-8f3e44d5125e@qt.io> References: <1691504.8p7tJBIcV1@bola> <1898980.is4RtUE86b@tjmaciei-mobl1> <88f83d99-e66d-0462-a3a8-8f3e44d5125e@qt.io> Message-ID: <2633612.15xtHcd9Zv@tjmaciei-mobl1> On Sunday, 7 May 2017 23:56:19 PDT Kari Oikarinen wrote: > The failures of https://codereview.qt-project.org/#/c/180231/ and > https://codereview.qt-project.org/#/c/180232/ happened on Ubuntu Touch > builds. > > That platform is not part of 5.9 CI anymore. So as far as I understand > it hasn't been tried if the patches could successfully integrate into 5.9? We should try. As soon as Ossi retargets to 5.9.0, can someone stage them? > Disabling cross-compilation of QtDBus would break a lot of users. > (Including Qt for Device Creation builds.) So hopefully we can find some > other way. That's no longer my problem. No one in a year has stepped up to help. Maybe by removing the ability to cross-compile, someone now will. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon May 8 09:03:27 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 08 May 2017 00:03:27 -0700 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 In-Reply-To: References: <201705051543.58146.kde@carewolf.com> Message-ID: <1928155.QGs3TC2pe6@tjmaciei-mobl1> On Sunday, 7 May 2017 23:38:33 PDT Lars Knoll wrote: > Hi, > > why can't we just keep these symbols around without exporting them through a > header file and make them simply forward to the global new/delete > operators? If we don't export them in a header at least newly compiled code > would stop using them, and old code would continue working like that. The problem is not related to compilation and thus headers. The problem is that the symbols *exist*. Since they exist, the linker will link to them. Now, the problem is that they exist under an ELF version, so when we remove them, the dynamic linker will no longer find the plain unversioned ones in libstdc++.so.6. I *think* it's possible to provide them under as special type of version that allows the previous uses to be found, but no longer allow new linking to them (non-default version). But since I don't have qtwebengine around, I need information: Does _Znwm appear with one or two @ ? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexandru.croitor at qt.io Mon May 8 10:43:01 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Mon, 8 May 2017 08:43:01 +0000 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> Message-ID: Hi, Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the whole application, instead of leaving that to be done by Chromium. Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium code, so that access is granted to the cross-process resources. By default Chromium uses "org.chromium.Chromium" prefix as the application group key, which results in the permission denied issues. You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" entitlement key. That made it work for me. Regards, Alex. On 06 May 2017, at 14:46, Adalid Claure > wrote: FWIW, I tried these changes but like you said I ran into another error (though, I'm pretty sure it's one I've seen before). 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) 5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) Does this look like the other issues you were referring to? There is progress in the sense that the QtWebEngine widget is now white, instead of invisible (since it wasn't loading, I presume) like before. Of course, nothing renders inside it though. On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor > wrote: It's in the function SandboxCompiler::CompileAndApplyProfile in qt59_source/qtwebengine/src/3rdparty/chromium/content/common/sandbox_mac.mm:150 the whole if branch. But please do note my warning, even if it appears to work, it does not mean you will not have issues. Chromium has its own special sandbox profile (set of rules) that it applies to the subprocess, and it never applies it to the main process. So by simply enabling default sandboxing for both, you invite untested territories. On 04 May 2017, at 15:26, Adalid Claure > wrote: I am the one who logged the bug. Can you point me to the line of code that you commented out where you were able to get it to work? On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor > wrote: Hi, I'm actually looking into this at the moment, as per the created issue here QTBUG-60443 I haven't completely finished my investigation, which I will post to the bug report. But the gist of it is: - the WebEngine / Chromium sub process calls manually sandbox_init, which is the macOS private API for enabling the sandbox. That interferes with the sandbox which you enable via codesign entitlements, which gives the "sandbox reinit denied' issue, and crashed process. - if the above call is commented out, then you need to make sure that the Qt Application is signed with sandbox setup entitlements, and the WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I couldn't get it to work. - Both of those entitlements have to specify a valid Team ID + prefix in the entitlment com.apple.security.application-groups key. - Google Chrome itself does not enable sandboxing via codesign entitlements, but only enables it for subprocess via sandbox_init, leaving the main process without a sandbox. Thus my preliminary suggestion is not to enable codesign sandboxing for QtWebengine applications. I'm open to discussion on this though. Note that the private API use inside WebEngine, which is removed via appstore_compliant configure switch, is a separate issue from sandboxing. Regards, Alex. On 04 May 2017, at 14:45, Morten Sørvig > wrote: Hi, Not sure if I can be of much help, but: - This thread discusses and solves a similar problem: https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application - If this could be reduced to a simple sandboxed-app-with-helper-process test case (no QtWebEngine usage), that that’s something I could look at, and something we could eventually add an autotest for. Morten On 28 Apr 2017, at 18:49, Adalid Claure > wrote: I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI. When the app starts I see the following errors in Console: kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit My build process is pretty straight forward: 1. Run macdeployqt on the app, using the -appstore-compliant. 2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file. 3. Sign QtWebEngineProcess.app with the following entitlements file: com.apple.security.app-sandbox com.apple.security.inherit 4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2. I have tried numerous things all in combination with one another, including: a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility) b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. d. tried linking with Qt 5.7 e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because: ------------------------------- Your app uses or references the following non-public API(s): framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit' : NSAccessibilityUnregisterUniqueIdForUIElement : _NSAppendToKillRing : _NSDrawCarbonThemeBezel : _NSDrawCarbonThemeListBox : _NSInitializeKillRing : _NSNewKillRingSequence : _NSPrependToKillRing : _NSSetKillRingToYankedState : _NSYankFromKillRing framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices' : CGSSetDenyWindowServerConnections : CGSShutdownServerConnections : CTFontCopyDefaultCascadeList The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. ------------------------------- I have chronicled a lot of this in this thread here (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine? Thanks. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Mon May 8 10:52:13 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 8 May 2017 10:52:13 +0200 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 In-Reply-To: References: <201705051543.58146.kde@carewolf.com> Message-ID: <201705081052.14182.kde@carewolf.com> On Monday 08 May 2017, Lars Knoll wrote: > Hi, > > why can't we just keep these symbols around without exporting them through > a header file and make them simply forward to the global new/delete > operators? If we don't export them in a header at least newly compiled > code would stop using them, and old code would continue working like that. > They were never exported through a header file. They were just marked exported and then picked up by the linker when it looked for new/delete definitions. `Allan From edward.welbourne at qt.io Mon May 8 11:06:59 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 8 May 2017 09:06:59 +0000 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <1898980.is4RtUE86b@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <1963160.3oN18OL0Sd@tjmaciei-mobl1> , <1898980.is4RtUE86b@tjmaciei-mobl1> Message-ID: ________________________________________ From: Development on behalf of Thiago Macieira Sent: 08 May 2017 08:47 To: development at qt-project.org Subject: Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? On Sunday, 7 May 2017 22:56:53 PDT Sergio Martins wrote: > On 2017-05-06 16:00, Thiago Macieira wrote: > > Someone could do that. I'd even appreciate just a backtrace from the > > deadlocked application. > > Have you asked the CI guys for such backtrace ? Why isn't there a JIRA > issue for this ? I asked for anyone who could reproduce the issue to help and no one did. And until this discussion now, I had not realised it was connected to cross- compilation -- though in fact we have not proven it, it's just a very good theory. As for a JIRA task to get backtraces from crashed or stuck applications, it again hadn't seemed necessary so far. The qmake crash that we saw this week was only the second time that it would have been helpful. Well... that and all those moc crashes we experienced for a year. -- 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 michal.klocek at qt.io Mon May 8 11:32:20 2017 From: michal.klocek at qt.io (Michal Klocek) Date: Mon, 8 May 2017 09:32:20 +0000 Subject: [Development] abi breakage for qtwebengine libraries in 5.9 In-Reply-To: <1928155.QGs3TC2pe6@tjmaciei-mobl1> References: <201705051543.58146.kde@carewolf.com> , <1928155.QGs3TC2pe6@tjmaciei-mobl1> Message-ID: Thanks Thiago for the hint, I only tried to make symbols as weak alias, but that did not do the job. Now when you mentioned about default version I checked and symbols indeed were exported as 'default', I will try later today to see if this can be fixed as you suggested. Br Michal ________________________________ From: Development on behalf of Thiago Macieira Sent: Monday, May 8, 2017 9:03 AM To: development at qt-project.org Subject: Re: [Development] abi breakage for qtwebengine libraries in 5.9 On Sunday, 7 May 2017 23:38:33 PDT Lars Knoll wrote: > Hi, > > why can't we just keep these symbols around without exporting them through a > header file and make them simply forward to the global new/delete > operators? If we don't export them in a header at least newly compiled code > would stop using them, and old code would continue working like that. The problem is not related to compilation and thus headers. The problem is that the symbols *exist*. Since they exist, the linker will link to them. Now, the problem is that they exist under an ELF version, so when we remove them, the dynamic linker will no longer find the plain unversioned ones in libstdc++.so.6. I *think* it's possible to provide them under as special type of version that allows the previous uses to be found, but no longer allow new linking to them (non-default version). But since I don't have qtwebengine around, I need information: Does _Znwm appear with one or two @ ? -- 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 Info Page - Qt lists.qt-project.org To see the collection of prior postings to the list, visit the Development Archives. Using Development: To post a message to all the list members ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon May 8 11:55:47 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 08 May 2017 12:55:47 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <2864721493982925@web13j.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> <2864721493982925@web13j.yandex.ru> Message-ID: <6406901494237347@web23g.yandex.ru> 05.05.2017, 14:15, "Konstantin Tokarev" : > 05.05.2017, 10:04, "Tuukka Turunen" : >>  Hi, >> >>  There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. >> >>  I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. >> >>  For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. > > BTW, let me bring an attention to the elephant in the room. > > Yes, my fork of QtWebKit existed for a while as a separate item. But it was never > and "official" successor, and even me myself was warning people that it is not an > official replacement as some features are not yet restored. > > However, now there is no valid reason to keep using QtWebKit contained in 5.9 and > dev branches anymore. Feature parity is achieved to the level of drop-in replacement > that can be applied system-wide. Still many people see 5.9 branch as a source of truth. > > We need to convey a message to wide audience that old QtWebKit should no longer be > used, and that there is a new release that should be used instead. Not only with Qt 5.9.0, > but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., Ubuntu 14.04). > > This is why question about version numbers and related stuff is important. If this is not > done, it doesn't matter at all whatever tag names will be picked and what schedules will > be followed. Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does not exist, I think it should be to make exceptions in branch and release management policies for 5.9 and 5.9.0 branches, solely to resolve situation described above. I propose the following plan: 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to "alpha" release, that has feature parity, but is not yet guaranteed to be polished enough. 2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha release at http://download.qt.io/community_releases/5.9/ 3. For dev branch, follow all necessary procedures to change status of QtWebKit and make it work for Qt 5.10 without any schedule exceptions. [1] http://doc.qt.io/qt-5/qtmodules.html > >>  Yours, >> >>          Tuukka >> >>  On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" wrote: >> >>      04.05.2017, 19:35, "Oswald Buddenhagen" : >>      > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >>      >> 03.05.2017, 17:27, "Sergio Martins" : >>      >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >>      >> >> Remaining question is versioning. While it's fine to dub current >>      >> >> release "5.9" (but not 5.0, because we will have another WebKit update >>      >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >>      >> >> >>      >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >>      >> >> or is updated >>      >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >>      >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >>      >> >> 5.2 as of now), and can be used e.g. as security update in Linux >>      >> >> distro that does not normally update Qt version during its life cycle. >>      >> >> >>      >> >> Any comments? >>      >> > >>      >> > If Qt and QtWebKit will have different release schedules then that >>      >> > numbering would indeed confuse people. >>      >> >>      >> What about choice of new versioning scheme? >>      >> >>      >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >>      >> clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >>      >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >>      >> verison (7.0 etc.) >>      >> >>      >> Qt5 supermodule will be tracking latest available stable branch. When release branch >>      >> is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >>      >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >>      >> >>      >> However, I'm not sure about two things: >>      >> 1) Is it possible to have custom branch names in qtwebkit repository, or there need to >>      >> be virtual 5.10 etc. branches to match other modules? >>      >> 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >>      >> new release numbers to items fixed in new releases >>      > >>      > i'll say outright that you can't be part of the qt supermodule and yet >>      > have independent releases. while that was the plan once upon a time, the >>      > whole release infrastructure simply doesn't deliver, and even just >>      > diverging branch names are a pita (proved by enginio). as a product, qt >>      > is as monolithic as ever. >> >>      Understood: no custom branch/tag names in official repo. >> >>      > >>      > your release cycle concerns seem to be centered around the webkit >>      > backend, and you can deal with that by lowering the compatibility >>      > guarantees of patch releases at this level, i.e. take the freedom to >>      > upgrade webkit in a patch release. as long as you keep qt's api/abi >>      > compat promises, you're fine. that means that you will not be able to >>      > expose new webkit features until the next minor release if they require >>      > new api. >> >>      That's probably fine with me, except 2 moments that seem to require "out of band" releases: >> >>      1. Something should be done with current release. As I said, it's not an option to postpone >>      it to 5.10, however it also cannot be released as 5.9.1 because there are API additions >>      which I don't want to revert (in particular because these APIs were already shipped by >>      Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream >>      format of QWebHistory. >> >>      2. Security updates. WebKitGTK team provides several patch releases for each stable branch, >>      which contain only fixes for bugs and security issues, and towards the end of release life cycle >>      they became primarily security updates. I think we should be able to release such updates ASAP, >>      by making up some tag name and scheduling custom build against newest patch release of Qt. >> >>      > _______________________________________________ >>      > Development mailing list >>      > Development at qt-project.org >>      > http://lists.qt-project.org/mailman/listinfo/development >> >>      -- >>      Regards, >>      Konstantin >>      _______________________________________________ >>      Development mailing list >>      Development at qt-project.org >>      http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From aclaure at gmail.com Mon May 8 13:33:21 2017 From: aclaure at gmail.com (Adalid Claure) Date: Mon, 8 May 2017 07:33:21 -0400 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> Message-ID: > Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the > whole application, instead of leaving that to be done by Chromium. Hmm.. I'm not sure what you mean. How exactly should I be signing my app then? Per the MAS, I have to sign it my app with " com.apple.security.app-sandbox". > Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" > entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium > code, so that access is granted to the cross-process resources. By default Chromium uses > "org.chromium.Chromium" prefix as the application group key, which results in the permission denied > issues. I see. I've been using the . entitlement for my main app, but I guess Chromium's code ignores that and uses this hard coded value? > You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/ > 3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" > entitlement key. That made it work for me. Ok, I will give this a try. Thanks again for your help. On Mon, May 8, 2017 at 4:43 AM, Alexandru Croitor wrote: > Hi, > > Well, to be fair, it seems you haven't heeded my advice, and are going > with the approach of sandboxing the whole application, instead of leaving > that to be done by Chromium. > > Regarding the issues you are seeing now, it is because of the > "com.apple.security.application-groups" entitlement key. That value (team > id + "." + random domain-like suffix string) has to be used by Chromium > code, so that access is granted to the cross-process resources. By default > Chromium uses "org.chromium.Chromium" prefix as the application group key, > which results in the permission denied issues. > > You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/ > 3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle > id to your "team_id + suffix" entitlement key. That made it work for me. > > Regards, Alex. > > On 06 May 2017, at 14:46, Adalid Claure wrote: > > FWIW, I tried these changes but like you said I ran into another error > (though, I'm pretty sure it's one I've seen before). > > 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) > mach-lookup org.chromium.Chromium.rohitfork.5957 > 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) > mach-lookup org.chromium.Chromium.rohitfork.5957 > 5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR: > mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) > 5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR: > mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) > > Does this look like the other issues you were referring to? > > There is progress in the sense that the QtWebEngine widget is now white, > instead of invisible (since it wasn't loading, I presume) like before. Of > course, nothing renders inside it though. > > > > On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor > wrote: > >> It's in the function SandboxCompiler::CompileAndApplyProfile in >> qt59_source/qtwebengine/src/3rdparty/chromium/content/common/ >> sandbox_mac.mm:150 >> the whole if branch. >> >> But please do note my warning, even if it appears to work, it does not >> mean you will not have issues. Chromium has its own special sandbox profile >> (set of rules) that it applies to the subprocess, and it never applies it >> to the main process. So by simply enabling default sandboxing for both, you >> invite untested territories. >> >> >> On 04 May 2017, at 15:26, Adalid Claure wrote: >> >> I am the one who logged the bug. >> >> Can you point me to the line of code that you commented out where you >> were able to get it to work? >> >> On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor < >> alexandru.croitor at qt.io> wrote: >> >>> Hi, >>> >>> I'm actually looking into this at the moment, as per the created issue >>> here QTBUG-60443 >>> >>> I haven't completely finished my investigation, which I will post to the >>> bug report. >>> >>> But the gist of it is: >>> - the WebEngine / Chromium sub process calls manually sandbox_init, >>> which is the macOS private API for enabling the sandbox. That interferes >>> with the sandbox which you enable via codesign entitlements, which gives >>> the "sandbox reinit denied' issue, and crashed process. >>> >>> - if the above call is commented out, then you need to make sure that >>> the Qt Application is signed with sandbox setup entitlements, and the >>> WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I >>> couldn't get it to work. >>> >>> - Both of those entitlements have to specify a valid Team ID + prefix in >>> the entitlment com.apple.security.application-groups >>> key. >>> >>> - Google Chrome itself does not enable sandboxing via codesign >>> entitlements, but only enables it for subprocess via sandbox_init, leaving >>> the main process without a sandbox. >>> >>> Thus my preliminary suggestion is not to enable codesign sandboxing for >>> QtWebengine applications. >>> >>> I'm open to discussion on this though. >>> >>> Note that the private API use inside WebEngine, which is removed via >>> appstore_compliant configure switch, is a separate issue from sandboxing. >>> >>> Regards, Alex. >>> >>> >>> >>> >>> On 04 May 2017, at 14:45, Morten Sørvig wrote: >>> >>> Hi, >>> >>> Not sure if I can be of much help, but: >>> >>> - This thread discusses and solves a similar problem: >>> https://forum.qt.io/topic/49250/solved-qtwebengineprocess-no >>> t-working-in-sandboxed-application >>> >>> - If this could be reduced to a simple sandboxed-app-with-helper-process >>> test case (no QtWebEngine usage), that that’s something I could look at, >>> and something we could eventually add an autotest for. >>> >>> >>> Morten >>> >>> >>> On 28 Apr 2017, at 18:49, Adalid Claure wrote: >>> >>> I have a desktop app that I have been trying to get onto the Mac App >>> store but I have been having problems getting it to run in sandbox mode. >>> For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. >>> >>> The crux seems to be QtWebEngineProcess.app refuses to run after I >>> codesign the bundle. As a result, my QtWebEngine component doesn't load. I >>> am using this QtWebEngine component as part of my app's UI. >>> >>> When the app starts I see the following errors in Console: >>> >>> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup >>> org.chromium.Chromium.rohitfork.20763 >>> kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup >>> org.chromium.Chromium.rohitfork.20763 >>> QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] >>> bootstrap_look_up: Permission denied (1100) >>> QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] >>> bootstrap_look_up: Permission denied (1100) >>> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) >>> forbidden-sandbox-reinit >>> >>> My build process is pretty straight forward: >>> >>> 1. Run macdeployqt on the app, using the -appstore-compliant. >>> 2. Sign all of the Qt Frameworks and PlugIns individually with my app's >>> entitlement file. >>> 3. Sign QtWebEngineProcess.app with the following entitlements file: >>> >>> >>> >> http://www.apple.com/DTDs/PropertyList-1.0.dtd"> >>> >>> >>> com.apple.security.app-sandbox >>> >>> com.apple.security.inherit >>> >>> >>> >>> >>> 4. Call codesign on the overall MyProgram.app bundle with the >>> entitlements file from Step 2. >>> >>> I have tried numerous things all in combination with one another, >>> including: >>> >>> a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code >>> (per the notes here: https://doc.qt.io/qt-5/qtweben >>> gine-platform-notes.html#mac-app-store-compatibility) >>> b. use macdeployqt's -codesign, even though the binarys have to be >>> signed a second time after this in order to apply the entitlements >>> c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to >>> 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. >>> d. tried linking with Qt 5.7 >>> e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by >>> Apple because: >>> >>> ------------------------------- >>> Your app uses or references the following non-public API(s): >>> >>> framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppK >>> it' >>> : NSAccessibilityUnregisterUniqueIdForUIElement >>> : _NSAppendToKillRing >>> : _NSDrawCarbonThemeBezel >>> : _NSDrawCarbonThemeListBox >>> : _NSInitializeKillRing >>> : _NSNewKillRingSequence >>> : _NSPrependToKillRing >>> : _NSSetKillRingToYankedState >>> : _NSYankFromKillRing >>> >>> framework: '/System/Library/Frameworks/ApplicationServices.framework/Ve >>> rsions/A/ApplicationServices' >>> : CGSSetDenyWindowServerConnections >>> : CGSShutdownServerConnections >>> : CTFontCopyDefaultCascadeList >>> >>> The use of non-public APIs is not permitted on the App Store as it can >>> lead to a poor user experience should these APIs change. >>> ------------------------------- >>> >>> I have chronicled a lot of this in this thread here ( >>> https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app >>> -store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. >>> >>> Does anyone have any suggestions? Does anyone know of any apps on the >>> Mac App Store that use QtWebEngine? >>> >>> Thanks. >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Mon May 8 13:37:02 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 8 May 2017 11:37:02 +0000 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <6406901494237347@web23g.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> <2864721493982925@web13j.yandex.ru> <6406901494237347@web23g.yandex.ru> Message-ID: Couple of comments below br, Jani > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Konstantin Tokarev > Sent: maanantaina 8. toukokuuta 2017 12.56 > To: Tuukka Turunen ; Oswald Buddenhagen > ; development at qt-project.org > Subject: Re: [Development] QtWebKit is coming back (part 2) > > > > 05.05.2017, 14:15, "Konstantin Tokarev" : > > 05.05.2017, 10:04, "Tuukka Turunen" : > >>  Hi, > >> > >>  There has also been some interest also for getting Qt WebEngine to be > released much faster cycle than Qt – exactly due to the security update need. > Even if we succeed in making substantially more frequent Qt patch releases > than before, it may still be better if user would have the option to update > some parts (like QWE) more frequently or out of sync. > >> > >>  I think what we should consider, is to perhaps carve out Qt WebEngine > from Qt as well. Not immediately, but for Qt 6 we should anyway consider > our current setup of essential and add-on modules. For the html5 engine > there is the matter of binary size in addition to release frequency. This is not > to say that we would stop developing html5 engine – just that it might be > beneficial to do in in different way than currently. > >> > >>  For new updated Qt Webkit, perhaps we could have it as a separate item > that works on top of Qt 5.9 for those to use it who prefer it over Qt > WebEngine. After it has existed for a while as a separate item, it is also easier > to know what would be the best way to get it into a Qt release – or is that > even necessary. > > > > BTW, let me bring an attention to the elephant in the room. > > > > Yes, my fork of QtWebKit existed for a while as a separate item. But > > it was never and "official" successor, and even me myself was warning > > people that it is not an official replacement as some features are not yet > restored. > > > > However, now there is no valid reason to keep using QtWebKit contained > > in 5.9 and dev branches anymore. Feature parity is achieved to the > > level of drop-in replacement that can be applied system-wide. Still many > people see 5.9 branch as a source of truth. > > > > We need to convey a message to wide audience that old QtWebKit should > > no longer be used, and that there is a new release that should be used > > instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt > 5.2.x if people still use it (e.g., Ubuntu 14.04). > > > > This is why question about version numbers and related stuff is > > important. If this is not done, it doesn't matter at all whatever tag > > names will be picked and what schedules will be followed. > > Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does > not exist, I think it should be to make exceptions in branch and release > management policies for > 5.9 and 5.9.0 branches, solely to resolve situation described above. Actually 'old ' webkit is in our builds but not part of official releases, see e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162 That is because we have agreed to keep it working and deliver src packages for the releases as well. Not part of official release but in addition. > > I propose the following plan: > > 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to > "alpha" release, that has feature parity, but is not yet guaranteed to be > polished enough. To be honest, I don't want to do this now. From release schedule point of view it is just too late, we cannot risk our Qt 5.9.0 release schedule because of this. At this point 5.10 should be enough. For me it is ok if you want to add TP/Alpha etc in http://download.qt.io/community_releases/5.9/ but being part of official ci builds in '5.9.x' it is too risky. > 2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha > release at http://download.qt.io/community_releases/5.9/ This should be OK as well > 3. For dev branch, follow all necessary procedures to change status of > QtWebKit and make it work for Qt 5.10 without any schedule exceptions. > > [1] http://doc.qt.io/qt-5/qtmodules.html > > > > >>  Yours, > >> > >>          Tuukka > >> > >>  On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" > annulen at yandex.ru> wrote: > >> > >>      04.05.2017, 19:35, "Oswald Buddenhagen" > : > >>      > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev > wrote: > >>      >> 03.05.2017, 17:27, "Sergio Martins" : > >>      >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: > >>      >> >> Remaining question is versioning. While it's fine to dub > >> current > >>      >> >> release "5.9" (but not 5.0, because we will have another > >> WebKit update > >>      >> >> in 5.10 time frame), using Qt versions in QtWebKit has > downsides: > >>      >> >> > >>      >> >> 1. It is not clear if 5.N+1 ships with the same WebKit > >> branch as 5.N, > >>      >> >> or is updated > >>      >> >> 2. It makes people believe that QtWebKit 5.N should be > >> used with Qt > >>      >> >> 5.N only. QtWebKit supports wide range of Qt versions > >> (starting from > >>      >> >> 5.2 as of now), and can be used e.g. as security update in > >> Linux > >>      >> >> distro that does not normally update Qt version during its life > cycle. > >>      >> >> > >>      >> >> Any comments? > >>      >> > > >>      >> > If Qt and QtWebKit will have different release schedules > >> then that > >>      >> > numbering would indeed confuse people. > >>      >> > >>      >> What about choice of new versioning scheme? > >>      >> > >>      >> I'm leaning towards "6.0.0" number, because it's larger than > >> any 5.x and makes it > >>      >> clear that versioning is different now. Bug fixes will > >> increment patch version (6.0.x), > >>      >> WebKit updates minor version (6.1.x etc), API/ABI breaking > >> changes - major > >>      >> verison (7.0 etc.) > >>      >> > >>      >> Qt5 supermodule will be tracking latest available stable > >> branch. When release branch > >>      >> is created (e.g. 5.10.0), corresponding patch release branch > >> is created in qtwebkit > >>      >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt > release branches. > >>      >> > >>      >> However, I'm not sure about two things: > >>      >> 1) Is it possible to have custom branch names in qtwebkit > >> repository, or there need to > >>      >> be virtual 5.10 etc. branches to match other modules? > >>      >> 2) What about bug tracking in JIRA? I would like to keep > >> existing issues as is, but assing > >>      >> new release numbers to items fixed in new releases > >>      > > >>      > i'll say outright that you can't be part of the qt supermodule > >> and yet > >>      > have independent releases. while that was the plan once upon a > >> time, the > >>      > whole release infrastructure simply doesn't deliver, and even > >> just > >>      > diverging branch names are a pita (proved by enginio). as a > >> product, qt > >>      > is as monolithic as ever. > >> > >>      Understood: no custom branch/tag names in official repo. > >> > >>      > > >>      > your release cycle concerns seem to be centered around the > >> webkit > >>      > backend, and you can deal with that by lowering the > >> compatibility > >>      > guarantees of patch releases at this level, i.e. take the > >> freedom to > >>      > upgrade webkit in a patch release. as long as you keep qt's > >> api/abi > >>      > compat promises, you're fine. that means that you will not be > >> able to > >>      > expose new webkit features until the next minor release if > >> they require > >>      > new api. > >> > >>      That's probably fine with me, except 2 moments that seem to require > "out of band" releases: > >> > >>      1. Something should be done with current release. As I said, > >> it's not an option to postpone > >>      it to 5.10, however it also cannot be released as 5.9.1 because > >> there are API additions > >>      which I don't want to revert (in particular because these APIs > >> were already shipped by > >>      Linux distros that chose to provide TP4 and TP5). Also there is > >> a change in QDataStream > >>      format of QWebHistory. > >> > >>      2. Security updates. WebKitGTK team provides several patch > >> releases for each stable branch, > >>      which contain only fixes for bugs and security issues, and > >> towards the end of release life cycle > >>      they became primarily security updates. I think we should be > >> able to release such updates ASAP, > >>      by making up some tag name and scheduling custom build against > newest patch release of Qt. > >> > >>      > _______________________________________________ > >>      > Development mailing list > >>      > Development at qt-project.org > >>      > http://lists.qt-project.org/mailman/listinfo/development > >> > >>      -- > >>      Regards, > >>      Konstantin > >>      _______________________________________________ > >>      Development mailing list > >>      Development at qt-project.org > >>      http://lists.qt-project.org/mailman/listinfo/development > > > > -- > > Regards, > > Konstantin > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From alexandru.croitor at qt.io Mon May 8 13:41:34 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Mon, 8 May 2017 11:41:34 +0000 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> Message-ID: <3148B9C9-60B7-47D8-B884-60B78387A209@qt.io> On 08 May 2017, at 13:33, Adalid Claure > wrote: > Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the > whole application, instead of leaving that to be done by Chromium. Hmm.. I'm not sure what you mean. How exactly should I be signing my app then? Per the MAS, I have to sign it my app with "com.apple.security.app-sandbox". I would have expected that signing without sandboxing should be possible. But if it is absolutely required, then that's unfortunate, because of the mentioned "unsupported by Chromium" territory. > Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" > entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium > code, so that access is granted to the cross-process resources. By default Chromium uses > "org.chromium.Chromium" prefix as the application group key, which results in the permission denied > issues. I see. I've been using the . entitlement for my main app, but I guess Chromium's code ignores that and uses this hard coded value? Yes, currently the chromium part of WebEngine ignores the bundle id, and just hardcodes it. > You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/ > 3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" > entitlement key. That made it work for me. Ok, I will give this a try. Thanks again for your help. On Mon, May 8, 2017 at 4:43 AM, Alexandru Croitor > wrote: Hi, Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the whole application, instead of leaving that to be done by Chromium. Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium code, so that access is granted to the cross-process resources. By default Chromium uses "org.chromium.Chromium" prefix as the application group key, which results in the permission denied issues. You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" entitlement key. That made it work for me. Regards, Alex. On 06 May 2017, at 14:46, Adalid Claure > wrote: FWIW, I tried these changes but like you said I ran into another error (though, I'm pretty sure it's one I've seen before). 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) 5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) Does this look like the other issues you were referring to? There is progress in the sense that the QtWebEngine widget is now white, instead of invisible (since it wasn't loading, I presume) like before. Of course, nothing renders inside it though. On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor > wrote: It's in the function SandboxCompiler::CompileAndApplyProfile in qt59_source/qtwebengine/src/3rdparty/chromium/content/common/sandbox_mac.mm:150 the whole if branch. But please do note my warning, even if it appears to work, it does not mean you will not have issues. Chromium has its own special sandbox profile (set of rules) that it applies to the subprocess, and it never applies it to the main process. So by simply enabling default sandboxing for both, you invite untested territories. On 04 May 2017, at 15:26, Adalid Claure > wrote: I am the one who logged the bug. Can you point me to the line of code that you commented out where you were able to get it to work? On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor > wrote: Hi, I'm actually looking into this at the moment, as per the created issue here QTBUG-60443 I haven't completely finished my investigation, which I will post to the bug report. But the gist of it is: - the WebEngine / Chromium sub process calls manually sandbox_init, which is the macOS private API for enabling the sandbox. That interferes with the sandbox which you enable via codesign entitlements, which gives the "sandbox reinit denied' issue, and crashed process. - if the above call is commented out, then you need to make sure that the Qt Application is signed with sandbox setup entitlements, and the WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I couldn't get it to work. - Both of those entitlements have to specify a valid Team ID + prefix in the entitlment com.apple.security.application-groups key. - Google Chrome itself does not enable sandboxing via codesign entitlements, but only enables it for subprocess via sandbox_init, leaving the main process without a sandbox. Thus my preliminary suggestion is not to enable codesign sandboxing for QtWebengine applications. I'm open to discussion on this though. Note that the private API use inside WebEngine, which is removed via appstore_compliant configure switch, is a separate issue from sandboxing. Regards, Alex. On 04 May 2017, at 14:45, Morten Sørvig > wrote: Hi, Not sure if I can be of much help, but: - This thread discusses and solves a similar problem: https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application - If this could be reduced to a simple sandboxed-app-with-helper-process test case (no QtWebEngine usage), that that’s something I could look at, and something we could eventually add an autotest for. Morten On 28 Apr 2017, at 18:49, Adalid Claure > wrote: I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI. When the app starts I see the following errors in Console: kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit My build process is pretty straight forward: 1. Run macdeployqt on the app, using the -appstore-compliant. 2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file. 3. Sign QtWebEngineProcess.app with the following entitlements file: com.apple.security.app-sandbox com.apple.security.inherit 4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2. I have tried numerous things all in combination with one another, including: a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility) b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. d. tried linking with Qt 5.7 e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because: ------------------------------- Your app uses or references the following non-public API(s): framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit' : NSAccessibilityUnregisterUniqueIdForUIElement : _NSAppendToKillRing : _NSDrawCarbonThemeBezel : _NSDrawCarbonThemeListBox : _NSInitializeKillRing : _NSNewKillRingSequence : _NSPrependToKillRing : _NSSetKillRingToYankedState : _NSYankFromKillRing framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices' : CGSSetDenyWindowServerConnections : CGSShutdownServerConnections : CTFontCopyDefaultCascadeList The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. ------------------------------- I have chronicled a lot of this in this thread here (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine? Thanks. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.welsch at etm.at Mon May 8 13:57:32 2017 From: christoph.welsch at etm.at (Welsch, Christoph) Date: Mon, 8 May 2017 11:57:32 +0000 Subject: [Development] Building plugins/sqldrivers with QT 5.9 on windows Message-ID: Hi, I'm trying to build the sqldriver plugins with qt 5.9. In 5.5 it was no problem to build the drivers with following qmake call: qmake INCLUDEPATH+=D:/QtBuild/Qt-Win64/Qt5-WinDeps-64bit/windeps\MySQL\include LIBS+=D:/QtBuild/Qt-Win64/Qt5-WinDeps-64bit/windeps\MySQL\lib\libmysql.lib D:/QtBuild/src/qt-everywhere-opensource-src-5.9.0-beta2/qtbase\src\plugins\sqldrivers\mysql\mysql.pro On QT 5.9 it fails with following message. Project ERROR: Library 'mysql' is not defined. When I googled the error, I found a hint, that I need to remove following line from the file mysql.pro in qtbase/src/plugins/sqldrivers/mysql: QMAKE_USE += mysql Without this line it works as usual. Is this a bug within the pro file or has the qmake call changed? Regards, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From akseli.salovaara at qt.io Mon May 8 14:07:23 2017 From: akseli.salovaara at qt.io (Akseli Salovaara) Date: Mon, 8 May 2017 12:07:23 +0000 Subject: [Development] Coin: using 64-bit Windows host for 32-bit builds In-Reply-To: References: <572531493909544@web10g.yandex.ru> <485881493932975@web7g.yandex.ru> <3250030.Gka3H93m88@tjmaciei-mobl1>, <496841493936159@web57g.yandex.ru> Message-ID: > -----Original Message----- > From: Simon Hausmann > Sent: perjantaina 5. toukokuuta 2017 09:55 > To: Konstantin Tokarev ; Akseli Salovaara > > Cc: Thiago Macieira ; development at qt- > project.org > Subject: Re: [Development] Coin: using 64-bit Windows host for 32-bit builds > > Hi, > > I believe Akseli was making progress on that front. Can you fill us briefly in on > the status? I just got patch merged to coin master branch which allows Windows 10 x86 MSVC2015 integrations on Windows 10 x64 host. Required provisioning for 32bit desktop builds on Windows 10 x64 host machines has been done already earlier. We still need to update coin production instance and change coin platform configurations on Qt5 but Qt5 5.8 and later 5.9 branch integrations has been already done successfully on background for a while. I would assume allowing MSVC2017 32bit builds on 64bit host is next step but I got last minute autotest failure from qtbase which doesn't occur when building on Windows 10 32bit machine. I need to investigate that before making next patch available. Br, Akseli > > Thanks :) > Simon > > > On 5. May 2017, at 00:16, Konstantin Tokarev wrote: > > > > > > > > 05.05.2017, 01:11, "Thiago Macieira" : > >> Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin > >> Tokarev > >> escreveu: > >>> Unfortunately, VS is the worst offender at the moment, it does not > >>> have anything like -g1, or like -g0 (i.e. option to negate > >>> previously added /Zi) > >> > >> IIRC, the 32-bit linker is a 32-bit application too if you use > >> "vcvarsall x86". > >> > >> You need a cross-compilation setup, like "vcvarsall x64_x86". > > > > Yes, use 64-bit tools while compiling for 32-bit target. That requires > > 64-bit OS image to start with. > > > >> > >> -- > >> Thiago Macieira - thiago.macieira (AT) intel.com > >> Software Architect - Intel Open Source Technology Center > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > -- > > Regards, > > Konstantin > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Mon May 8 14:11:52 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 8 May 2017 12:11:52 +0000 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <2864721493982925@web13j.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> <2864721493982925@web13j.yandex.ru> Message-ID: On 5 May 2017, at 13:15, Konstantin Tokarev > wrote: 05.05.2017, 10:04, "Tuukka Turunen" >: Hi, There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. BTW, let me bring an attention to the elephant in the room. Yes, my fork of QtWebKit existed for a while as a separate item. But it was never and "official" successor, and even me myself was warning people that it is not an official replacement as some features are not yet restored. However, now there is no valid reason to keep using QtWebKit contained in 5.9 and dev branches anymore. Feature parity is achieved to the level of drop-in replacement that can be applied system-wide. Still many people see 5.9 branch as a source of truth. Yes, we have been keeping the old code compiling, but we have not been supporting it for a while, and it hasn’t been tested since then neither. We need to convey a message to wide audience that old QtWebKit should no longer be used, and that there is a new release that should be used instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., Ubuntu 14.04). I agree here. We’ve kept the old Qt Webkit compiling against newer Qt version because of requests from the community. I think we can drop this now, and tell people to use your branch instead. It’ll certainly be better and safer than the old code base. This is why question about version numbers and related stuff is important. If this is not done, it doesn't matter at all whatever tag names will be picked and what schedules will be followed. I have no problems dropping the old qtwebkit code base and tell people to move over to use your branch. One option is that we do not provide any source package from the old code base for qtwebkit with Qt 5.9 anymore. This would free up the version numbers from 5.9 onwards. At the same time I do agree with Tuukka, that we need to reconsider the coupling between webkit/webengine and Qt releases. if current QtWebkit runs nicely on top of Qt, maybe that’s how we should keep it. This would allow us to provide source/binary packages of it on a more independent schedule. Cheers, Lars Yours, Tuukka On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" on behalf of annulen at yandex.ru> wrote: 04.05.2017, 19:35, "Oswald Buddenhagen" >: > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >> 03.05.2017, 17:27, "Sergio Martins" >: >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >> >> Remaining question is versioning. While it's fine to dub current >> >> release "5.9" (but not 5.0, because we will have another WebKit update >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >> >> or is updated >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >> >> 5.2 as of now), and can be used e.g. as security update in Linux >> >> distro that does not normally update Qt version during its life cycle. >> >> >> >> Any comments? >> > >> > If Qt and QtWebKit will have different release schedules then that >> > numbering would indeed confuse people. >> >> What about choice of new versioning scheme? >> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >> clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >> verison (7.0 etc.) >> >> Qt5 supermodule will be tracking latest available stable branch. When release branch >> is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >> >> However, I'm not sure about two things: >> 1) Is it possible to have custom branch names in qtwebkit repository, or there need to >> be virtual 5.10 etc. branches to match other modules? >> 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >> new release numbers to items fixed in new releases > > i'll say outright that you can't be part of the qt supermodule and yet > have independent releases. while that was the plan once upon a time, the > whole release infrastructure simply doesn't deliver, and even just > diverging branch names are a pita (proved by enginio). as a product, qt > is as monolithic as ever. Understood: no custom branch/tag names in official repo. > > your release cycle concerns seem to be centered around the webkit > backend, and you can deal with that by lowering the compatibility > guarantees of patch releases at this level, i.e. take the freedom to > upgrade webkit in a patch release. as long as you keep qt's api/abi > compat promises, you're fine. that means that you will not be able to > expose new webkit features until the next minor release if they require > new api. That's probably fine with me, except 2 moments that seem to require "out of band" releases: 1. Something should be done with current release. As I said, it's not an option to postpone it to 5.10, however it also cannot be released as 5.9.1 because there are API additions which I don't want to revert (in particular because these APIs were already shipped by Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream format of QWebHistory. 2. Security updates. WebKitGTK team provides several patch releases for each stable branch, which contain only fixes for bugs and security issues, and towards the end of release life cycle they became primarily security updates. I think we should be able to release such updates ASAP, by making up some tag name and scheduling custom build against newest patch release of Qt. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Mon May 8 14:22:07 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 8 May 2017 12:22:07 +0000 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> <2864721493982925@web13j.yandex.ru> <6406901494237347@web23g.yandex.ru> Message-ID: <0E1659E0-D664-47A3-8E1E-E6CD8BD69A3F@qt.io> On 8 May 2017, at 13:37, Jani Heikkinen > wrote: Couple of comments below br, Jani -----Original Message----- From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt- project.org] On Behalf Of Konstantin Tokarev Sent: maanantaina 8. toukokuuta 2017 12.56 To: Tuukka Turunen >; Oswald Buddenhagen >; development at qt-project.org Subject: Re: [Development] QtWebKit is coming back (part 2) 05.05.2017, 14:15, "Konstantin Tokarev" >: 05.05.2017, 10:04, "Tuukka Turunen" >: Hi, There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. BTW, let me bring an attention to the elephant in the room. Yes, my fork of QtWebKit existed for a while as a separate item. But it was never and "official" successor, and even me myself was warning people that it is not an official replacement as some features are not yet restored. However, now there is no valid reason to keep using QtWebKit contained in 5.9 and dev branches anymore. Feature parity is achieved to the level of drop-in replacement that can be applied system-wide. Still many people see 5.9 branch as a source of truth. We need to convey a message to wide audience that old QtWebKit should no longer be used, and that there is a new release that should be used instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., Ubuntu 14.04). This is why question about version numbers and related stuff is important. If this is not done, it doesn't matter at all whatever tag names will be picked and what schedules will be followed. Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does not exist, I think it should be to make exceptions in branch and release management policies for 5.9 and 5.9.0 branches, solely to resolve situation described above. Actually 'old ' webkit is in our builds but not part of official releases, see e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162 That is because we have agreed to keep it working and deliver src packages for the releases as well. Not part of official release but in addition. As I said in my other mail, we could easily drop those unsupported packages. Maybe quickly check whether the 5.8 packages compile against Qt 5.9. If they do, there’s no need at all to release packages that are the same, but remove the option of using the new version number for the updated engine. I propose the following plan: 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to "alpha" release, that has feature parity, but is not yet guaranteed to be polished enough. To be honest, I don't want to do this now. From release schedule point of view it is just too late, we cannot risk our Qt 5.9.0 release schedule because of this. At this point 5.10 should be enough. For me it is ok if you want to add TP/Alpha etc in http://download.qt.io/community_releases/5.9/ but being part of official ci builds in '5.9.x' it is too risky. Yes, we can’t couple this to our Qt 5.9 release. It clearly comes too late for that. In addition, I am not convinced it’s a too good idea, we were never really happy with that tight coupling for our web engine(s) in the past. So I’d propose we rather first try to figure out if we can keep those decoupled from a releasing perspective. This might create some challenges in how we handle things from a packaging/CI side, but working through those items might be helpful in the longer term, and something we could then start considering for web engine as well. Cheers, Lars 2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha release at http://download.qt.io/community_releases/5.9/ This should be OK as well 3. For dev branch, follow all necessary procedures to change status of QtWebKit and make it work for Qt 5.10 without any schedule exceptions. [1] http://doc.qt.io/qt-5/qtmodules.html Yours, Tuukka On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" on behalf of annulen at yandex.ru> wrote: 04.05.2017, 19:35, "Oswald Buddenhagen" >: > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >> 03.05.2017, 17:27, "Sergio Martins" >: >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >> >> Remaining question is versioning. While it's fine to dub current >> >> release "5.9" (but not 5.0, because we will have another WebKit update >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >> >> or is updated >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >> >> 5.2 as of now), and can be used e.g. as security update in Linux >> >> distro that does not normally update Qt version during its life cycle. >> >> >> >> Any comments? >> > >> > If Qt and QtWebKit will have different release schedules then that >> > numbering would indeed confuse people. >> >> What about choice of new versioning scheme? >> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >> clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >> verison (7.0 etc.) >> >> Qt5 supermodule will be tracking latest available stable branch. When release branch >> is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >> >> However, I'm not sure about two things: >> 1) Is it possible to have custom branch names in qtwebkit repository, or there need to >> be virtual 5.10 etc. branches to match other modules? >> 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >> new release numbers to items fixed in new releases > > i'll say outright that you can't be part of the qt supermodule and yet > have independent releases. while that was the plan once upon a time, the > whole release infrastructure simply doesn't deliver, and even just > diverging branch names are a pita (proved by enginio). as a product, qt > is as monolithic as ever. Understood: no custom branch/tag names in official repo. > > your release cycle concerns seem to be centered around the webkit > backend, and you can deal with that by lowering the compatibility > guarantees of patch releases at this level, i.e. take the freedom to > upgrade webkit in a patch release. as long as you keep qt's api/abi > compat promises, you're fine. that means that you will not be able to > expose new webkit features until the next minor release if they require > new api. That's probably fine with me, except 2 moments that seem to require "out of band" releases: 1. Something should be done with current release. As I said, it's not an option to postpone it to 5.10, however it also cannot be released as 5.9.1 because there are API additions which I don't want to revert (in particular because these APIs were already shipped by Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream format of QWebHistory. 2. Security updates. WebKitGTK team provides several patch releases for each stable branch, which contain only fixes for bugs and security issues, and towards the end of release life cycle they became primarily security updates. I think we should be able to release such updates ASAP, by making up some tag name and scheduling custom build against newest patch release of Qt. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon May 8 16:47:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 08 May 2017 07:47:19 -0700 Subject: [Development] Building plugins/sqldrivers with QT 5.9 on windows In-Reply-To: References: Message-ID: <5306331.F8QpixJujz@tjmaciei-mobl1> On Monday, 8 May 2017 04:57:32 PDT Welsch, Christoph wrote: > Without this line it works as usual. Is this a bug within the pro file or > has the qmake call changed? qmake has changed. I believe there's an open bug report about updating the instructions on how to build the plugins. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexandru.croitor at qt.io Mon May 8 17:32:55 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Mon, 8 May 2017 15:32:55 +0000 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> <3148B9C9-60B7-47D8-B884-60B78387A209@qt.io> Message-ID: On 08 May 2017, at 17:22, Adalid Claure > wrote: I changed the string like you suggested and it worked! Of course, I know this is very hack'ish. How stable do you think this is? I wouldn't know because this is the first time I tried doing it, and pretty much nobody tests for this unless they need it. I've noticed that the Electron framework (based on Chromium) documents the whole submit to Mac App Store sandbox / codesign process, so I assume it worked for some people in some scenario. To what extent, I wouldn't know. My app generates all the HTML it displays using QtWebEngine and it's nothing complicated. Do you think these changes in QtWebEngine I made per your suggestions are worth submitting to the MAS? I'm not sure what you mean by "submitting the changes to MAS". You will obviously need the changes to your application, to at least try to submit to the MAS, but you will probably fail because of the private API functions that are still used in the code. So far though, the plan is to document for Qt 5.9.0 that Qt WebEngine in its current state will not be app store compliant (because of the sandbox issue, and because of the private API usage). On Mon, May 8, 2017 at 7:41 AM, Alexandru Croitor > wrote: On 08 May 2017, at 13:33, Adalid Claure > wrote: > Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the > whole application, instead of leaving that to be done by Chromium. Hmm.. I'm not sure what you mean. How exactly should I be signing my app then? Per the MAS, I have to sign it my app with "com.apple.security.app-sandbox". I would have expected that signing without sandboxing should be possible. But if it is absolutely required, then that's unfortunate, because of the mentioned "unsupported by Chromium" territory. > Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" > entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium > code, so that access is granted to the cross-process resources. By default Chromium uses > "org.chromium.Chromium" prefix as the application group key, which results in the permission denied > issues. I see. I've been using the . entitlement for my main app, but I guess Chromium's code ignores that and uses this hard coded value? Yes, currently the chromium part of WebEngine ignores the bundle id, and just hardcodes it. > You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/ > 3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" > entitlement key. That made it work for me. Ok, I will give this a try. Thanks again for your help. On Mon, May 8, 2017 at 4:43 AM, Alexandru Croitor > wrote: Hi, Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the whole application, instead of leaving that to be done by Chromium. Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium code, so that access is granted to the cross-process resources. By default Chromium uses "org.chromium.Chromium" prefix as the application group key, which results in the permission denied issues. You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" entitlement key. That made it work for me. Regards, Alex. On 06 May 2017, at 14:46, Adalid Claure > wrote: FWIW, I tried these changes but like you said I ran into another error (though, I'm pretty sure it's one I've seen before). 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) 5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) Does this look like the other issues you were referring to? There is progress in the sense that the QtWebEngine widget is now white, instead of invisible (since it wasn't loading, I presume) like before. Of course, nothing renders inside it though. On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor > wrote: It's in the function SandboxCompiler::CompileAndApplyProfile in qt59_source/qtwebengine/src/3rdparty/chromium/content/common/sandbox_mac.mm:150 the whole if branch. But please do note my warning, even if it appears to work, it does not mean you will not have issues. Chromium has its own special sandbox profile (set of rules) that it applies to the subprocess, and it never applies it to the main process. So by simply enabling default sandboxing for both, you invite untested territories. On 04 May 2017, at 15:26, Adalid Claure > wrote: I am the one who logged the bug. Can you point me to the line of code that you commented out where you were able to get it to work? On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor > wrote: Hi, I'm actually looking into this at the moment, as per the created issue here QTBUG-60443 I haven't completely finished my investigation, which I will post to the bug report. But the gist of it is: - the WebEngine / Chromium sub process calls manually sandbox_init, which is the macOS private API for enabling the sandbox. That interferes with the sandbox which you enable via codesign entitlements, which gives the "sandbox reinit denied' issue, and crashed process. - if the above call is commented out, then you need to make sure that the Qt Application is signed with sandbox setup entitlements, and the WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I couldn't get it to work. - Both of those entitlements have to specify a valid Team ID + prefix in the entitlment com.apple.security.application-groups key. - Google Chrome itself does not enable sandboxing via codesign entitlements, but only enables it for subprocess via sandbox_init, leaving the main process without a sandbox. Thus my preliminary suggestion is not to enable codesign sandboxing for QtWebengine applications. I'm open to discussion on this though. Note that the private API use inside WebEngine, which is removed via appstore_compliant configure switch, is a separate issue from sandboxing. Regards, Alex. On 04 May 2017, at 14:45, Morten Sørvig > wrote: Hi, Not sure if I can be of much help, but: - This thread discusses and solves a similar problem: https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application - If this could be reduced to a simple sandboxed-app-with-helper-process test case (no QtWebEngine usage), that that’s something I could look at, and something we could eventually add an autotest for. Morten On 28 Apr 2017, at 18:49, Adalid Claure > wrote: I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI. When the app starts I see the following errors in Console: kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit My build process is pretty straight forward: 1. Run macdeployqt on the app, using the -appstore-compliant. 2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file. 3. Sign QtWebEngineProcess.app with the following entitlements file: com.apple.security.app-sandbox com.apple.security.inherit 4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2. I have tried numerous things all in combination with one another, including: a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility) b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. d. tried linking with Qt 5.7 e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because: ------------------------------- Your app uses or references the following non-public API(s): framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit' : NSAccessibilityUnregisterUniqueIdForUIElement : _NSAppendToKillRing : _NSDrawCarbonThemeBezel : _NSDrawCarbonThemeListBox : _NSInitializeKillRing : _NSNewKillRingSequence : _NSPrependToKillRing : _NSSetKillRingToYankedState : _NSYankFromKillRing framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices' : CGSSetDenyWindowServerConnections : CGSShutdownServerConnections : CTFontCopyDefaultCascadeList The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. ------------------------------- I have chronicled a lot of this in this thread here (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine? Thanks. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From aclaure at gmail.com Mon May 8 17:35:17 2017 From: aclaure at gmail.com (Adalid Claure) Date: Mon, 8 May 2017 11:35:17 -0400 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> <3148B9C9-60B7-47D8-B884-60B78387A209@qt.io> Message-ID: I just meant are the changes to QtWebEngine you suggested stable enough for "production". But if it's still using private API, then I guess there's no point in trying to submit it to MAS. Damn. On Mon, May 8, 2017 at 11:32 AM, Alexandru Croitor wrote: > > On 08 May 2017, at 17:22, Adalid Claure wrote: > > I changed the string like you suggested and it worked! > > Of course, I know this is very hack'ish. How stable do you think this is? > > > I wouldn't know because this is the first time I tried doing it, and > pretty much nobody tests for this unless they need it. > > I've noticed that the Electron framework (based on Chromium) documents the > whole submit to Mac App Store sandbox / codesign process, so I assume it > worked for some people in some scenario. To what extent, I wouldn't know. > > My app generates all the HTML it displays using QtWebEngine and it's > nothing complicated. Do you think these changes in QtWebEngine I made per > your suggestions are worth submitting to the MAS? > > > I'm not sure what you mean by "submitting the changes to MAS". You will > obviously need the changes to your application, to at least try to submit > to the MAS, but you will probably fail because of the private API functions > that are still used in the code. > > > So far though, the plan is to document for Qt 5.9.0 that Qt WebEngine in > its current state will not be app store compliant (because of the sandbox > issue, and because of the private API usage). > > > On Mon, May 8, 2017 at 7:41 AM, Alexandru Croitor > wrote: > >> >> On 08 May 2017, at 13:33, Adalid Claure wrote: >> >> > Well, to be fair, it seems you haven't heeded my advice, and are going >> with the approach of sandboxing the >> > whole application, instead of leaving that to be done by Chromium. >> >> Hmm.. I'm not sure what you mean. How exactly should I be signing my app >> then? Per the MAS, I have to sign it my app with " >> com.apple.security.app-sandbox". >> >> >> I would have expected that signing without sandboxing should be possible. >> But if it is absolutely required, then that's unfortunate, because of the >> mentioned "unsupported by Chromium" territory. >> >> > Regarding the issues you are seeing now, it is because of the >> "com.apple.security.application-groups" >> > entitlement key. That value (team id + "." + random domain-like suffix >> string) has to be used by Chromium >> > code, so that access is granted to the cross-process resources. By >> default Chromium uses >> > "org.chromium.Chromium" prefix as the application group key, which >> results in the permission denied >> > issues. >> >> I see. I've been using the . entitlement for my >> main app, but I guess Chromium's code ignores that and uses this hard coded >> value? >> >> >> Yes, currently the chromium part of WebEngine ignores the bundle id, and >> just hardcodes it. >> >> >> > You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/ >> > 3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the >> bundle id to your "team_id + suffix" >> > entitlement key. That made it work for me. >> >> Ok, I will give this a try. >> >> Thanks again for your help. >> >> >> On Mon, May 8, 2017 at 4:43 AM, Alexandru Croitor < >> alexandru.croitor at qt.io> wrote: >> >>> Hi, >>> >>> Well, to be fair, it seems you haven't heeded my advice, and are going >>> with the approach of sandboxing the whole application, instead of leaving >>> that to be done by Chromium. >>> >>> Regarding the issues you are seeing now, it is because of the >>> "com.apple.security.application-groups" entitlement key. That value >>> (team id + "." + random domain-like suffix string) has to be used by >>> Chromium code, so that access is granted to the cross-process resources. By >>> default Chromium uses "org.chromium.Chromium" prefix as the application >>> group key, which results in the permission denied issues. >>> >>> You can modify the "BaseBundleID" method in >>> "/qt_source/qtwebengine/src/3rdparty/chromium/base/mac/found >>> ation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" >>> entitlement key. That made it work for me. >>> >>> Regards, Alex. >>> >>> On 06 May 2017, at 14:46, Adalid Claure wrote: >>> >>> FWIW, I tried these changes but like you said I ran into another error >>> (though, I'm pretty sure it's one I've seen before). >>> >>> 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) >>> mach-lookup org.chromium.Chromium.rohitfork.5957 >>> 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) >>> mach-lookup org.chromium.Chromium.rohitfork.5957 >>> 5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR: >>> mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) >>> 5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR: >>> mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) >>> >>> Does this look like the other issues you were referring to? >>> >>> There is progress in the sense that the QtWebEngine widget is now white, >>> instead of invisible (since it wasn't loading, I presume) like before. Of >>> course, nothing renders inside it though. >>> >>> >>> >>> On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor < >>> alexandru.croitor at qt.io> wrote: >>> >>>> It's in the function SandboxCompiler::CompileAndApplyProfile in >>>> qt59_source/qtwebengine/src/3rdparty/chromium/content/common/ >>>> sandbox_mac.mm:150 >>>> the whole if branch. >>>> >>>> But please do note my warning, even if it appears to work, it does not >>>> mean you will not have issues. Chromium has its own special sandbox profile >>>> (set of rules) that it applies to the subprocess, and it never applies it >>>> to the main process. So by simply enabling default sandboxing for both, you >>>> invite untested territories. >>>> >>>> >>>> On 04 May 2017, at 15:26, Adalid Claure wrote: >>>> >>>> I am the one who logged the bug. >>>> >>>> Can you point me to the line of code that you commented out where you >>>> were able to get it to work? >>>> >>>> On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor < >>>> alexandru.croitor at qt.io> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm actually looking into this at the moment, as per the created issue >>>>> here QTBUG-60443 >>>>> >>>>> I haven't completely finished my investigation, which I will post to >>>>> the bug report. >>>>> >>>>> But the gist of it is: >>>>> - the WebEngine / Chromium sub process calls manually sandbox_init, >>>>> which is the macOS private API for enabling the sandbox. That interferes >>>>> with the sandbox which you enable via codesign entitlements, which >>>>> gives the "sandbox reinit denied' issue, and crashed process. >>>>> >>>>> - if the above call is commented out, then you need to make sure that >>>>> the Qt Application is signed with sandbox setup entitlements, and the >>>>> WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I >>>>> couldn't get it to work. >>>>> >>>>> - Both of those entitlements have to specify a valid Team ID + prefix >>>>> in the entitlment com.apple.security.application-groups >>>>> key. >>>>> >>>>> - Google Chrome itself does not enable sandboxing via codesign >>>>> entitlements, but only enables it for subprocess via sandbox_init, leaving >>>>> the main process without a sandbox. >>>>> >>>>> Thus my preliminary suggestion is not to enable codesign sandboxing >>>>> for QtWebengine applications. >>>>> >>>>> I'm open to discussion on this though. >>>>> >>>>> Note that the private API use inside WebEngine, which is removed via >>>>> appstore_compliant configure switch, is a separate issue from sandboxing. >>>>> >>>>> Regards, Alex. >>>>> >>>>> >>>>> >>>>> >>>>> On 04 May 2017, at 14:45, Morten Sørvig wrote: >>>>> >>>>> Hi, >>>>> >>>>> Not sure if I can be of much help, but: >>>>> >>>>> - This thread discusses and solves a similar problem: >>>>> https://forum.qt.io/topic/49250/solved-qtwebengineprocess-no >>>>> t-working-in-sandboxed-application >>>>> >>>>> - If this could be reduced to a simple sandboxed-app-with-helper-process >>>>> test case (no QtWebEngine usage), that that’s something I could look at, >>>>> and something we could eventually add an autotest for. >>>>> >>>>> >>>>> Morten >>>>> >>>>> >>>>> On 28 Apr 2017, at 18:49, Adalid Claure wrote: >>>>> >>>>> I have a desktop app that I have been trying to get onto the Mac App >>>>> store but I have been having problems getting it to run in sandbox mode. >>>>> For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. >>>>> >>>>> The crux seems to be QtWebEngineProcess.app refuses to run after I >>>>> codesign the bundle. As a result, my QtWebEngine component doesn't load. I >>>>> am using this QtWebEngine component as part of my app's UI. >>>>> >>>>> When the app starts I see the following errors in Console: >>>>> >>>>> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup >>>>> org.chromium.Chromium.rohitfork.20763 >>>>> kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup >>>>> org.chromium.Chromium.rohitfork.20763 >>>>> QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] >>>>> bootstrap_look_up: Permission denied (1100) >>>>> QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] >>>>> bootstrap_look_up: Permission denied (1100) >>>>> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) >>>>> forbidden-sandbox-reinit >>>>> >>>>> My build process is pretty straight forward: >>>>> >>>>> 1. Run macdeployqt on the app, using the -appstore-compliant. >>>>> 2. Sign all of the Qt Frameworks and PlugIns individually with my >>>>> app's entitlement file. >>>>> 3. Sign QtWebEngineProcess.app with the following entitlements file: >>>>> >>>>> >>>>> >>>> http://www.apple.com/DTDs/PropertyList-1.0.dtd"> >>>>> >>>>> >>>>> com.apple.security.app-sandbox >>>>> >>>>> com.apple.security.inherit >>>>> >>>>> >>>>> >>>>> >>>>> 4. Call codesign on the overall MyProgram.app bundle with the >>>>> entitlements file from Step 2. >>>>> >>>>> I have tried numerous things all in combination with one another, >>>>> including: >>>>> >>>>> a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code >>>>> (per the notes here: https://doc.qt.io/qt-5/qtweben >>>>> gine-platform-notes.html#mac-app-store-compatibility) >>>>> b. use macdeployqt's -codesign, even though the binarys have to be >>>>> signed a second time after this in order to apply the entitlements >>>>> c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to >>>>> 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle >>>>> ID. >>>>> d. tried linking with Qt 5.7 >>>>> e. tried linking with Qt 5.6.2 which *did* run but then gets rejected >>>>> by Apple because: >>>>> >>>>> ------------------------------- >>>>> Your app uses or references the following non-public API(s): >>>>> >>>>> framework: '/System/Library/Frameworks/Ap >>>>> pKit.framework/Versions/C/AppKit' >>>>> : NSAccessibilityUnregisterUniqueIdForUIElement >>>>> : _NSAppendToKillRing >>>>> : _NSDrawCarbonThemeBezel >>>>> : _NSDrawCarbonThemeListBox >>>>> : _NSInitializeKillRing >>>>> : _NSNewKillRingSequence >>>>> : _NSPrependToKillRing >>>>> : _NSSetKillRingToYankedState >>>>> : _NSYankFromKillRing >>>>> >>>>> framework: '/System/Library/Frameworks/Ap >>>>> plicationServices.framework/Versions/A/ApplicationServices' >>>>> : CGSSetDenyWindowServerConnections >>>>> : CGSShutdownServerConnections >>>>> : CTFontCopyDefaultCascadeList >>>>> >>>>> The use of non-public APIs is not permitted on the App Store as it can >>>>> lead to a poor user experience should these APIs change. >>>>> ------------------------------- >>>>> >>>>> I have chronicled a lot of this in this thread here ( >>>>> https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app >>>>> -store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. >>>>> >>>>> Does anyone have any suggestions? Does anyone know of any apps on the >>>>> Mac App Store that use QtWebEngine? >>>>> >>>>> Thanks. >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Mon May 8 17:38:03 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 8 May 2017 17:38:03 +0200 Subject: [Development] Building plugins/sqldrivers with QT 5.9 on windows In-Reply-To: <5306331.F8QpixJujz@tjmaciei-mobl1> References: <5306331.F8QpixJujz@tjmaciei-mobl1> Message-ID: Il 08/05/2017 16:47, Thiago Macieira ha scritto: > qmake has changed. I believe there's an open bug report about updating the > instructions on how to build the plugins. That would be https://bugreports.qt.io/browse/QTBUG-58372 I still maintain that this should be a P1 and a release blocker for 5.9.0 because without up-to-date documentation we're now regressing a feature. My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Mon May 8 18:24:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 08 May 2017 09:24:10 -0700 Subject: [Development] Building plugins/sqldrivers with QT 5.9 on windows In-Reply-To: References: <5306331.F8QpixJujz@tjmaciei-mobl1> Message-ID: <10036149.LfKA0VAzJE@tjmaciei-mobl1> On Monday, 8 May 2017 08:38:03 PDT Giuseppe D'Angelo wrote: > Il 08/05/2017 16:47, Thiago Macieira ha scritto: > > qmake has changed. I believe there's an open bug report about updating the > > instructions on how to build the plugins. > > That would be > > https://bugreports.qt.io/browse/QTBUG-58372 > > I still maintain that this should be a P1 and a release blocker for > 5.9.0 because without up-to-date documentation we're now regressing a > feature. Indeed, I think Ossi understood it as a different issue, that of configuring where the libraries are while compiling Qt itself. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Tue May 9 11:17:24 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 9 May 2017 09:17:24 +0000 Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files In-Reply-To: References: , , Message-ID: Hi all, Most of those change files are still under construction. Please finalize those now, we need to get RC content in place during this week to be able to get rc out as planned (see https://wiki.qt.io/Qt_5.9_Release) Open change files here: https://codereview.qt-project.org/#/q/branch:5.9.0+message:%22Add+changes+file+for+5.9.0%22,n,z br, Jani ________________________________________ From: Jani Heikkinen Sent: Friday, May 5, 2017 2:24 PM To: Simon Hausmann; development at qt-project.org Subject: Re: MAINTAINERS: your action needed: Qt 5.9.0 change files Initial change files are now created, please take those over & finalize as soon as possible br, Jani ________________________________________ From: Simon Hausmann Sent: Tuesday, May 2, 2017 5:09 PM To: Jani Heikkinen; development at qt-project.org Subject: Re: MAINTAINERS: your action needed: Qt 5.9.0 change files Hi, I'm a bit confused. The release team usually did the initial commit and maintainers edited the content. I'm fine with doing it myself, but I'm just wondering: Is there an intentional change in procedure? Simon ________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, May 2, 2017 12:26:14 PM To: development at qt-project.org Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files Hi all Maintainers! Branching from '5.9' to '5.9.0' is now ongoing and it is time to start creating change files for Qt 5.9.0. Please do the initial ones as soon as possible. And if some important change is coming in after the initial ones are in change owner can (& have to) update the change file as well. I am hoping we could get the change files now in early enough instead of fighting which these just before release (and even delaying the release because of missing ones...) br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexandru.croitor at qt.io Tue May 9 11:32:18 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Tue, 9 May 2017 09:32:18 +0000 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> <3148B9C9-60B7-47D8-B884-60B78387A209@qt.io> Message-ID: I took a look at the patches, and I think it should be safe-ish to apply them. That is only the case because the Bootstrap Sandbox which uses the private XPC API is not actually used at the moment in Qt WebEngine. The other private API patches listed there are either not relevant to WebEngine, already handled by WebEngine, or safe enough to remove. Could you please describe what's the procedure for getting the private API usage list from the MAS? On 08 May 2017, at 22:29, Adalid Claure > wrote: For the fun of it, I tried submitting my app and yeah, it was rejected: Your app uses or references the following non-public API(s): private spi symbol(s) in framework: '/usr/lib/libSystem.B.dylib' +++ : xpc_dictionary_set_mach_send +++ : xpc_mach_send_get_right I did, however find this: https://github.com/electron/libchromiumcontent/tree/master/patches-mas I may try applying those patches just to see what happens. I'll let you know. Thanks again for your help. On Mon, May 8, 2017 at 11:35 AM, Adalid Claure > wrote: I just meant are the changes to QtWebEngine you suggested stable enough for "production". But if it's still using private API, then I guess there's no point in trying to submit it to MAS. Damn. On Mon, May 8, 2017 at 11:32 AM, Alexandru Croitor > wrote: On 08 May 2017, at 17:22, Adalid Claure > wrote: I changed the string like you suggested and it worked! Of course, I know this is very hack'ish. How stable do you think this is? I wouldn't know because this is the first time I tried doing it, and pretty much nobody tests for this unless they need it. I've noticed that the Electron framework (based on Chromium) documents the whole submit to Mac App Store sandbox / codesign process, so I assume it worked for some people in some scenario. To what extent, I wouldn't know. My app generates all the HTML it displays using QtWebEngine and it's nothing complicated. Do you think these changes in QtWebEngine I made per your suggestions are worth submitting to the MAS? I'm not sure what you mean by "submitting the changes to MAS". You will obviously need the changes to your application, to at least try to submit to the MAS, but you will probably fail because of the private API functions that are still used in the code. So far though, the plan is to document for Qt 5.9.0 that Qt WebEngine in its current state will not be app store compliant (because of the sandbox issue, and because of the private API usage). On Mon, May 8, 2017 at 7:41 AM, Alexandru Croitor > wrote: On 08 May 2017, at 13:33, Adalid Claure > wrote: > Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the > whole application, instead of leaving that to be done by Chromium. Hmm.. I'm not sure what you mean. How exactly should I be signing my app then? Per the MAS, I have to sign it my app with "com.apple.security.app-sandbox". I would have expected that signing without sandboxing should be possible. But if it is absolutely required, then that's unfortunate, because of the mentioned "unsupported by Chromium" territory. > Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" > entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium > code, so that access is granted to the cross-process resources. By default Chromium uses > "org.chromium.Chromium" prefix as the application group key, which results in the permission denied > issues. I see. I've been using the . entitlement for my main app, but I guess Chromium's code ignores that and uses this hard coded value? Yes, currently the chromium part of WebEngine ignores the bundle id, and just hardcodes it. > You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/ > 3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" > entitlement key. That made it work for me. Ok, I will give this a try. Thanks again for your help. On Mon, May 8, 2017 at 4:43 AM, Alexandru Croitor > wrote: Hi, Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the whole application, instead of leaving that to be done by Chromium. Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium code, so that access is granted to the cross-process resources. By default Chromium uses "org.chromium.Chromium" prefix as the application group key, which results in the permission denied issues. You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" entitlement key. That made it work for me. Regards, Alex. On 06 May 2017, at 14:46, Adalid Claure > wrote: FWIW, I tried these changes but like you said I ran into another error (though, I'm pretty sure it's one I've seen before). 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957 5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) 5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) Does this look like the other issues you were referring to? There is progress in the sense that the QtWebEngine widget is now white, instead of invisible (since it wasn't loading, I presume) like before. Of course, nothing renders inside it though. On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor > wrote: It's in the function SandboxCompiler::CompileAndApplyProfile in qt59_source/qtwebengine/src/3rdparty/chromium/content/common/sandbox_mac.mm:150 the whole if branch. But please do note my warning, even if it appears to work, it does not mean you will not have issues. Chromium has its own special sandbox profile (set of rules) that it applies to the subprocess, and it never applies it to the main process. So by simply enabling default sandboxing for both, you invite untested territories. On 04 May 2017, at 15:26, Adalid Claure > wrote: I am the one who logged the bug. Can you point me to the line of code that you commented out where you were able to get it to work? On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor > wrote: Hi, I'm actually looking into this at the moment, as per the created issue here QTBUG-60443 I haven't completely finished my investigation, which I will post to the bug report. But the gist of it is: - the WebEngine / Chromium sub process calls manually sandbox_init, which is the macOS private API for enabling the sandbox. That interferes with the sandbox which you enable via codesign entitlements, which gives the "sandbox reinit denied' issue, and crashed process. - if the above call is commented out, then you need to make sure that the Qt Application is signed with sandbox setup entitlements, and the WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I couldn't get it to work. - Both of those entitlements have to specify a valid Team ID + prefix in the entitlment com.apple.security.application-groups key. - Google Chrome itself does not enable sandboxing via codesign entitlements, but only enables it for subprocess via sandbox_init, leaving the main process without a sandbox. Thus my preliminary suggestion is not to enable codesign sandboxing for QtWebengine applications. I'm open to discussion on this though. Note that the private API use inside WebEngine, which is removed via appstore_compliant configure switch, is a separate issue from sandboxing. Regards, Alex. On 04 May 2017, at 14:45, Morten Sørvig > wrote: Hi, Not sure if I can be of much help, but: - This thread discusses and solves a similar problem: https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application - If this could be reduced to a simple sandboxed-app-with-helper-process test case (no QtWebEngine usage), that that’s something I could look at, and something we could eventually add an autotest for. Morten On 28 Apr 2017, at 18:49, Adalid Claure > wrote: I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI. When the app starts I see the following errors in Console: kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763 QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] bootstrap_look_up: Permission denied (1100) kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit My build process is pretty straight forward: 1. Run macdeployqt on the app, using the -appstore-compliant. 2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file. 3. Sign QtWebEngineProcess.app with the following entitlements file: com.apple.security.app-sandbox com.apple.security.inherit 4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2. I have tried numerous things all in combination with one another, including: a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility) b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID. d. tried linking with Qt 5.7 e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because: ------------------------------- Your app uses or references the following non-public API(s): framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit' : NSAccessibilityUnregisterUniqueIdForUIElement : _NSAppendToKillRing : _NSDrawCarbonThemeBezel : _NSDrawCarbonThemeListBox : _NSInitializeKillRing : _NSNewKillRingSequence : _NSPrependToKillRing : _NSSetKillRingToYankedState : _NSYankFromKillRing framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices' : CGSSetDenyWindowServerConnections : CGSShutdownServerConnections : CTFontCopyDefaultCascadeList The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. ------------------------------- I have chronicled a lot of this in this thread here (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists. Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine? Thanks. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From aclaure at gmail.com Tue May 9 13:06:50 2017 From: aclaure at gmail.com (Adalid Claure) Date: Tue, 9 May 2017 07:06:50 -0400 Subject: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed In-Reply-To: References: <318B4D6A-4369-429F-BCD5-1C9DB31E5A3E@qt.io> <1C6F2AF7-A3AD-457E-9484-A60DB6FCED78@qt.io> <3148B9C9-60B7-47D8-B884-60B78387A209@qt.io> Message-ID: > Could you please describe what's the procedure for getting the private API usage list from the MAS? Unfortunately I do not know that there is one. I found these API calls only because when they rejected my app, they sent me a list of the API calls that they wouldn't allow to be used. I will spend some time over the weekend with this patch and see if I can get another version of my app submitted. I'll keep you updated. On Tue, May 9, 2017 at 5:32 AM, Alexandru Croitor wrote: > I took a look at the patches, and I think it should be safe-ish to apply > them. > > That is only the case because the Bootstrap Sandbox which uses the private > XPC API is not actually used at the moment in Qt WebEngine. > The other private API patches listed there are either not relevant to > WebEngine, already handled by WebEngine, or safe enough to remove. > > Could you please describe what's the procedure for getting the private API > usage list from the MAS? > > On 08 May 2017, at 22:29, Adalid Claure wrote: > > For the fun of it, I tried submitting my app and yeah, it was rejected: > > Your app uses or references the following non-public API(s): > > private spi symbol(s) in framework: '/usr/lib/libSystem.B.dylib' > +++ : xpc_dictionary_set_mach_send > +++ : xpc_mach_send_get_right > > I did, however find this: https://github.com/electron/libchromiumcontent/ > tree/master/patches-mas > > I may try applying those patches just to see what happens. I'll let you > know. > > Thanks again for your help. > > > > On Mon, May 8, 2017 at 11:35 AM, Adalid Claure wrote: > >> I just meant are the changes to QtWebEngine you suggested stable enough >> for "production". But if it's still using private API, then I guess there's >> no point in trying to submit it to MAS. >> >> Damn. >> >> On Mon, May 8, 2017 at 11:32 AM, Alexandru Croitor < >> alexandru.croitor at qt.io> wrote: >> >>> >>> On 08 May 2017, at 17:22, Adalid Claure wrote: >>> >>> I changed the string like you suggested and it worked! >>> >>> Of course, I know this is very hack'ish. How stable do you think this >>> is? >>> >>> >>> I wouldn't know because this is the first time I tried doing it, and >>> pretty much nobody tests for this unless they need it. >>> >>> I've noticed that the Electron framework (based on Chromium) documents >>> the whole submit to Mac App Store sandbox / codesign process, so I assume >>> it worked for some people in some scenario. To what extent, I wouldn't know. >>> >>> My app generates all the HTML it displays using QtWebEngine and it's >>> nothing complicated. Do you think these changes in QtWebEngine I made per >>> your suggestions are worth submitting to the MAS? >>> >>> >>> I'm not sure what you mean by "submitting the changes to MAS". You will >>> obviously need the changes to your application, to at least try to submit >>> to the MAS, but you will probably fail because of the private API functions >>> that are still used in the code. >>> >>> >>> So far though, the plan is to document for Qt 5.9.0 that Qt WebEngine in >>> its current state will not be app store compliant (because of the sandbox >>> issue, and because of the private API usage). >>> >>> >>> On Mon, May 8, 2017 at 7:41 AM, Alexandru Croitor < >>> alexandru.croitor at qt.io> wrote: >>> >>>> >>>> On 08 May 2017, at 13:33, Adalid Claure wrote: >>>> >>>> > Well, to be fair, it seems you haven't heeded my advice, and are >>>> going with the approach of sandboxing the >>>> > whole application, instead of leaving that to be done by Chromium. >>>> >>>> Hmm.. I'm not sure what you mean. How exactly should I be signing my >>>> app then? Per the MAS, I have to sign it my app with " >>>> com.apple.security.app-sandbox". >>>> >>>> >>>> I would have expected that signing without sandboxing should be >>>> possible. But if it is absolutely required, then that's unfortunate, >>>> because of the mentioned "unsupported by Chromium" territory. >>>> >>>> > Regarding the issues you are seeing now, it is because of the >>>> "com.apple.security.application-groups" >>>> > entitlement key. That value (team id + "." + random domain-like >>>> suffix string) has to be used by Chromium >>>> > code, so that access is granted to the cross-process resources. By >>>> default Chromium uses >>>> > "org.chromium.Chromium" prefix as the application group key, which >>>> results in the permission denied >>>> > issues. >>>> >>>> I see. I've been using the . entitlement for my >>>> main app, but I guess Chromium's code ignores that and uses this hard coded >>>> value? >>>> >>>> >>>> Yes, currently the chromium part of WebEngine ignores the bundle id, >>>> and just hardcodes it. >>>> >>>> >>>> > You can modify the "BaseBundleID" method in >>>> "/qt_source/qtwebengine/src/ >>>> > 3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the >>>> bundle id to your "team_id + suffix" >>>> > entitlement key. That made it work for me. >>>> >>>> Ok, I will give this a try. >>>> >>>> Thanks again for your help. >>>> >>>> >>>> On Mon, May 8, 2017 at 4:43 AM, Alexandru Croitor < >>>> alexandru.croitor at qt.io> wrote: >>>> >>>>> Hi, >>>>> >>>>> Well, to be fair, it seems you haven't heeded my advice, and are going >>>>> with the approach of sandboxing the whole application, instead of leaving >>>>> that to be done by Chromium. >>>>> >>>>> Regarding the issues you are seeing now, it is because of the >>>>> "com.apple.security.application-groups" entitlement key. That value >>>>> (team id + "." + random domain-like suffix string) has to be used by >>>>> Chromium code, so that access is granted to the cross-process resources. By >>>>> default Chromium uses "org.chromium.Chromium" prefix as the application >>>>> group key, which results in the permission denied issues. >>>>> >>>>> You can modify the "BaseBundleID" method in >>>>> "/qt_source/qtwebengine/src/3rdparty/chromium/base/mac/found >>>>> ation_util.mm:241" to hardcode the bundle id to your "team_id + >>>>> suffix" entitlement key. That made it work for me. >>>>> >>>>> Regards, Alex. >>>>> >>>>> On 06 May 2017, at 14:46, Adalid Claure wrote: >>>>> >>>>> FWIW, I tried these changes but like you said I ran into another error >>>>> (though, I'm pretty sure it's one I've seen before). >>>>> >>>>> 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) >>>>> mach-lookup org.chromium.Chromium.rohitfork.5957 >>>>> 5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) >>>>> mach-lookup org.chromium.Chromium.rohitfork.5957 >>>>> 5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR: >>>>> mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) >>>>> 5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR: >>>>> mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100) >>>>> >>>>> Does this look like the other issues you were referring to? >>>>> >>>>> There is progress in the sense that the QtWebEngine widget is now >>>>> white, instead of invisible (since it wasn't loading, I presume) like >>>>> before. Of course, nothing renders inside it though. >>>>> >>>>> >>>>> >>>>> On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor < >>>>> alexandru.croitor at qt.io> wrote: >>>>> >>>>>> It's in the function SandboxCompiler::CompileAndApplyProfile in >>>>>> qt59_source/qtwebengine/src/3rdparty/chromium/content/common/ >>>>>> sandbox_mac.mm:150 >>>>>> the whole if branch. >>>>>> >>>>>> But please do note my warning, even if it appears to work, it does >>>>>> not mean you will not have issues. Chromium has its own special sandbox >>>>>> profile (set of rules) that it applies to the subprocess, and it never >>>>>> applies it to the main process. So by simply enabling default sandboxing >>>>>> for both, you invite untested territories. >>>>>> >>>>>> >>>>>> On 04 May 2017, at 15:26, Adalid Claure wrote: >>>>>> >>>>>> I am the one who logged the bug. >>>>>> >>>>>> Can you point me to the line of code that you commented out where you >>>>>> were able to get it to work? >>>>>> >>>>>> On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor < >>>>>> alexandru.croitor at qt.io> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm actually looking into this at the moment, as per the created >>>>>>> issue here QTBUG-60443 >>>>>>> >>>>>>> I haven't completely finished my investigation, which I will post to >>>>>>> the bug report. >>>>>>> >>>>>>> But the gist of it is: >>>>>>> - the WebEngine / Chromium sub process calls manually sandbox_init, >>>>>>> which is the macOS private API for enabling the sandbox. That interferes >>>>>>> with the sandbox which you enable via codesign entitlements, which >>>>>>> gives the "sandbox reinit denied' issue, and crashed process. >>>>>>> >>>>>>> - if the above call is commented out, then you need to make sure >>>>>>> that the Qt Application is signed with sandbox setup entitlements, and the >>>>>>> WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I >>>>>>> couldn't get it to work. >>>>>>> >>>>>>> - Both of those entitlements have to specify a valid Team ID + >>>>>>> prefix in the entitlment com.apple.security.application-groups >>>>>>> key. >>>>>>> >>>>>>> - Google Chrome itself does not enable sandboxing via codesign >>>>>>> entitlements, but only enables it for subprocess via sandbox_init, leaving >>>>>>> the main process without a sandbox. >>>>>>> >>>>>>> Thus my preliminary suggestion is not to enable codesign sandboxing >>>>>>> for QtWebengine applications. >>>>>>> >>>>>>> I'm open to discussion on this though. >>>>>>> >>>>>>> Note that the private API use inside WebEngine, which is removed via >>>>>>> appstore_compliant configure switch, is a separate issue from sandboxing. >>>>>>> >>>>>>> Regards, Alex. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 04 May 2017, at 14:45, Morten Sørvig wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Not sure if I can be of much help, but: >>>>>>> >>>>>>> - This thread discusses and solves a similar problem: >>>>>>> https://forum.qt.io/topic/49250/solved-qtwebengineprocess-no >>>>>>> t-working-in-sandboxed-application >>>>>>> >>>>>>> - If this could be reduced to a simple sandboxed-app-with-helper-process >>>>>>> test case (no QtWebEngine usage), that that’s something I could look at, >>>>>>> and something we could eventually add an autotest for. >>>>>>> >>>>>>> >>>>>>> Morten >>>>>>> >>>>>>> >>>>>>> On 28 Apr 2017, at 18:49, Adalid Claure wrote: >>>>>>> >>>>>>> I have a desktop app that I have been trying to get onto the Mac App >>>>>>> store but I have been having problems getting it to run in sandbox mode. >>>>>>> For context I am (preferably) using Qt 5.8 running on macOS 10.11.6. >>>>>>> >>>>>>> The crux seems to be QtWebEngineProcess.app refuses to run after I >>>>>>> codesign the bundle. As a result, my QtWebEngine component doesn't load. I >>>>>>> am using this QtWebEngine component as part of my app's UI. >>>>>>> >>>>>>> When the app starts I see the following errors in Console: >>>>>>> >>>>>>> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup >>>>>>> org.chromium.Chromium.rohitfork.20763 >>>>>>> kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup >>>>>>> org.chromium.Chromium.rohitfork.20763 >>>>>>> QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] >>>>>>> bootstrap_look_up: Permission denied (1100) >>>>>>> QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] >>>>>>> bootstrap_look_up: Permission denied (1100) >>>>>>> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) >>>>>>> forbidden-sandbox-reinit >>>>>>> >>>>>>> My build process is pretty straight forward: >>>>>>> >>>>>>> 1. Run macdeployqt on the app, using the -appstore-compliant. >>>>>>> 2. Sign all of the Qt Frameworks and PlugIns individually with my >>>>>>> app's entitlement file. >>>>>>> 3. Sign QtWebEngineProcess.app with the following entitlements file: >>>>>>> >>>>>>> >>>>>>> >>>>>> http://www.apple.com/DTDs/PropertyList-1.0.dtd"> >>>>>>> >>>>>>> >>>>>>> com.apple.security.app-sandbox >>>>>>> >>>>>>> com.apple.security.inherit >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4. Call codesign on the overall MyProgram.app bundle with the >>>>>>> entitlements file from Step 2. >>>>>>> >>>>>>> I have tried numerous things all in combination with one another, >>>>>>> including: >>>>>>> >>>>>>> a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code >>>>>>> (per the notes here: https://doc.qt.io/qt-5/qtweben >>>>>>> gine-platform-notes.html#mac-app-store-compatibility) >>>>>>> b. use macdeployqt's -codesign, even though the binarys have to be >>>>>>> signed a second time after this in order to apply the entitlements >>>>>>> c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to >>>>>>> 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle >>>>>>> ID. >>>>>>> d. tried linking with Qt 5.7 >>>>>>> e. tried linking with Qt 5.6.2 which *did* run but then gets >>>>>>> rejected by Apple because: >>>>>>> >>>>>>> ------------------------------- >>>>>>> Your app uses or references the following non-public API(s): >>>>>>> >>>>>>> framework: '/System/Library/Frameworks/Ap >>>>>>> pKit.framework/Versions/C/AppKit' >>>>>>> : NSAccessibilityUnregisterUniqueIdForUIElement >>>>>>> : _NSAppendToKillRing >>>>>>> : _NSDrawCarbonThemeBezel >>>>>>> : _NSDrawCarbonThemeListBox >>>>>>> : _NSInitializeKillRing >>>>>>> : _NSNewKillRingSequence >>>>>>> : _NSPrependToKillRing >>>>>>> : _NSSetKillRingToYankedState >>>>>>> : _NSYankFromKillRing >>>>>>> >>>>>>> framework: '/System/Library/Frameworks/Ap >>>>>>> plicationServices.framework/Versions/A/ApplicationServices' >>>>>>> : CGSSetDenyWindowServerConnections >>>>>>> : CGSShutdownServerConnections >>>>>>> : CTFontCopyDefaultCascadeList >>>>>>> >>>>>>> The use of non-public APIs is not permitted on the App Store as it >>>>>>> can lead to a poor user experience should these APIs change. >>>>>>> ------------------------------- >>>>>>> >>>>>>> I have chronicled a lot of this in this thread here ( >>>>>>> https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app >>>>>>> -store-with-qt-5-8-and-qtwebengineprocess) but the problem >>>>>>> persists. >>>>>>> >>>>>>> Does anyone have any suggestions? Does anyone know of any apps on >>>>>>> the Mac App Store that use QtWebEngine? >>>>>>> >>>>>>> Thanks. >>>>>>> _______________________________________________ >>>>>>> Development mailing list >>>>>>> Development at qt-project.org >>>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Development mailing list >>>>>>> Development at qt-project.org >>>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Tue May 9 14:09:07 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 9 May 2017 12:09:07 +0000 Subject: [Development] [Announce] Qt Creator 4.3 RC1 released Message-ID: We are happy to announce the release of Qt Creator 4.3 RC1: http://blog.qt.io/blog/2017/05/09/qt-creator-4-3-rc1-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From lars.knoll at qt.io Tue May 9 15:35:52 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 9 May 2017 13:35:52 +0000 Subject: [Development] Release plan moving forward Message-ID: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> Hi everybody, I believe I have some good news to share with regards to our releases moving forward. As you all know, we had quite some trouble getting patch level releases out over the last year, going so far that we ended up not doing patch level releases for 5.8. Fortunately, things are starting to look a lot better now. You might already have noticed the rolling beta releases for 5.9, where we have pushed updated betas out every 1-2 weeks. This shows that things are now going a lot smoother and we are in a much better shape to create releases in the future. Additionally, things have improved on the CI and releasing side. It's nowadays a lot easier to get a qt5.git update through and create new packages from a successful qt5.git integration. In summer, the CI system will get a major HW upgrade giving it a much larger capacity, avoiding capacity conflicts between CI, packaging and release testing.Together with improvements to the Release Test Automation (RTA) which automatically tests our packages we're actually getting into a good position to do patch level releases with relatively little manual labor from 5.9 and onwards. This means that we should now be in a position to do much more frequent patch level releases from 5.9 onwards. Another thing that has happened is that The Qt Company has been seeing lots of requests for a new LTS release, as Qt 5.6 is starting to feel relatively old. I have also heard this request from a few places in the wider Qt community. Because of the improvements to CI/packaging and releasing, I believe we are now in a good position to make that happen. So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor releases since 5.6 and a lot of good things have happened in Qt, so this should be very good news to those of our users that don't always want to be on the bleeding edge but are looking for a stable version that's supported for a long time. So once 5.9 is out, we are planning for rather frequent patch level releases for that branch for the first 6-9 months. After that, we'll move 5.9 into strict mode where we will also release a little less often, and then have it in a very strict mode for the last year. See the draft QUIP at https://codereview.qt-project.org/#/c/178906/45//ALL,unified for more details on LTS branches. Of course, we will also continue to support 5.6 for the promised three years. We are planning to release 5.6.3 in Summer, after which 5.6 will move into the 'very strict' mode as defined in the branch policy QUIP. After 5.9, we'll be aiming at 5.10 in late autumn, 5.11 next spring. I believe that we will be doing one more final LTS release on the Qt 5 series, but most of the work after 5.11 will probably start to be aimed on working towards Qt 6. Now let's not go into discussions what Qt 6 exactly will be in this thread. I believe a lot of work towards defining what we're aiming at with Qt 6 will be for the Contributor Summit in October. But the outline above should give you good overview over the releases planned for the next 18 months. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Tue May 9 18:43:50 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 9 May 2017 16:43:50 +0000 Subject: [Development] possible API freeze exception: would like to introduce QQuickItem::setAcceptTouchEvents() in 5.9 Message-ID: <3E3CD3E5-D143-4E58-9841-44F91F8861EA@qt.io> This is of concern only to those who subclass QQuickItem in C++ and build custom items that handle touch events. There is a pretty bad API asymmetry which it’s surprising that we didn’t notice enough to try to correct it earlier. If you want to accept mouse events while any mouse button is clicked or held down or released, you call setAcceptedMouseButtons(). QQuickWindow won’t bother trying to deliver those events if you haven’t done that. Likewise if you want to handle all mouse movement events, pressed or not, you must call setAcceptHoverEvents(true). Imagine a world in which these didn’t exist: QQuickWindow would need to deliver every mouse movement to every Item. It would be unmanageable, performance would be unacceptable. The docs say that QGraphicsItem::setAcceptTouchEvents(bool) has existed since Qt 4.6. If you are handling touch events in a graphics view application, it’s required to call this. Yet for some odd reason, QQuickItem::setAcceptTouchEvents(bool) was never added. In some parts of the code, we make the assumption that if you have called setAcceptedMouseButtons(), you might want the touch events too. In other parts, we don’t check… so in the simplest case, if you create a custom item that handles touch events and stick it into your scene, you might get the touch events with no further ado, if no other item prevents it. It’s now become unmanageable to continue without adding this function. QtQuick Controls 2 has an issue that if you have a Popup with a shadow Item, you can drag via touch within the thin shadow area around the popup, and the events will go through, and you’ll be able to drag the sidebar open for example, even though there’s a translucent Item in between which is supposed to both dim the rest of the application, and catch all the events, to prevent interacting with other controls while the Popup is open. (Modal behavior.) In 5.10 we hope to introduce PointerHandlers, a big improvement on MouseArea, PinchArea and MultiPointTouchArea. This has been in the works for a couple of years now. So on the wip/pointerhandler branch, we already have the requirement that setAcceptTouchEvents() must be called if a custom Item wants to accept touch events. I thought maybe I could find a way to make it optional: to avoid changing behavior of existing custom items out in the wild, we would need it to default to true. That is, assume that every Item might handle touch events, give every item a chance… because it was that way before. Or at least, go on assuming that if it wants mouse events, maybe we should try to deliver touch events too. But along with introducing PointerHandlers, we have tried to optimize event delivery and make it more deterministic: before we start delivery, we build up a vector of all items to which delivery will be attempted, in the right order (reverse paint order). Then we build up a vector of pairs of items and their filtering parents (those which have called setFiltersChildMouseEvents - Flickable being the main example of that). So when we are doing the delivery, we no longer need to go up the parent hierarchy for each and every item that we visit, looking again and again for filtering parents. We no longer need a QSet just to keep track of items that we have visited, to avoid visiting them again. BUT: if we cannot know which items accept touch events and which don’t, this doesn’t work, because we would have to include _every_ item which has a filtering parent in that list of pairs, whether it would accept the touch event or not. And the result of that is that we will call childMouseEventFilter() too early in some cases, with the wrong item. "Hey Flickable, you’ve got a Rectangle which is your child, I’m about to send it a TouchEvent, do you want to intercept it?” Isn’t that stupid? Everybody knows Rectangle doesn’t do anything with pointing-device events. But if Flickable intercepts the event anyway, that means the MouseArea inside the Rectangle won’t get exactly the same chance it had before (even though Flickable is passive until the drag threshold is exceeded). Of course Rectangle could call setAcceptTouchEvents(false) explicitly, but that doesn’t take care of the custom items. Various Qt modules have custom items too; so we don’t want to start getting bugs about those misbehaving whenever they are used inside Flickable, for example. So to get the event delivery optimized as much as possible, it’s got to be mandatory at some point to _subscribe_ in some way for touch events if you need them. We can’t just assume, and spam every item with all events. Assuming that wanting mouse events = wanting touch events is wrong too. (It only made sense in a world in which all touch event delivery was done by synthesizing artificial mouse events from touchpoints. And that bad decision, the very worst architectural decision in all of QtQuick, has caused several years of frustration for me.) But I’ve been trying really hard to avoid changing any existing behavior, to avoid breaking any existing tests, which is why we didn’t come to this impasse sooner, I suppose. So I simply want to add the functions setAcceptTouchEvents(bool) and bool acceptTouchEvents() right now, in 5.9.0. Behavior won’t change yet; calling them will not be mandatory. But in 5.10, it might be mandatory. By the way, when we introduce PointerHandlers, the need to create custom Items to handle touch events will be mostly obsolete anyway. (Still supported of course, for now.) A PointerHandler is not an Item: it’s a lighter weight QObject which exists just to handle events. Like a behavioral facet of your visual item, rather than needing to be a full-fledged (heavy) item like MouseArea is. You will be able to have multiple PointerHandlers per Item. There will be public C++ API for them. So even in complex use cases, you should be able to create custom PointerHandlers rather than custom Items, if you don’t need to customize the visual appearance. You won’t need to call setAcceptTouchEvents() on the parent Item in order to enable the PointerHandlers, either; QQuickWindow is already aware of them, and offers them events at the appropriate time. I think that since mouse emulation has been enough for most use cases for this long, there probably aren’t that many custom items out there handling touch events directly; and for those that do, maybe it’s not too much to ask for them to make one more little function call in their constructors, before they upgrade to 5.10. But we can’t do that if the function doesn't even exist yet in 5.9, to give them a grace period. And 5.9 will be LTS… so the grace period will be quite long for those who need it to be. The change in question is https://codereview.qt-project.org/#/c/193175/ My apologies for not noticing the need for this much earlier. From annulen at yandex.ru Tue May 9 19:05:30 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 09 May 2017 20:05:30 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <0E1659E0-D664-47A3-8E1E-E6CD8BD69A3F@qt.io> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> <2864721493982925@web13j.yandex.ru> <6406901494237347@web23g.yandex.ru> <0E1659E0-D664-47A3-8E1E-E6CD8BD69A3F@qt.io> Message-ID: <8306961494349530@web28o.yandex.ru> 08.05.2017, 15:22, "Lars Knoll" : >> On 8 May 2017, at 13:37, Jani Heikkinen wrote: >> >> Couple of comments below >> >> br, >> Jani >> >>> -----Original Message----- >>> From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- >>> project.org] On Behalf Of Konstantin Tokarev >>> Sent: maanantaina 8. toukokuuta 2017 12.56 >>> To: Tuukka Turunen ; Oswald Buddenhagen >>> ; development at qt-project.org >>> Subject: Re: [Development] QtWebKit is coming back (part 2) >>> >>> 05.05.2017, 14:15, "Konstantin Tokarev" : >>>> 05.05.2017, 10:04, "Tuukka Turunen" : >>>>>  Hi, >>>>> >>>>>  There has also been some interest also for getting Qt WebEngine to be >>> released much faster cycle than Qt – exactly due to the security update need. >>> Even if we succeed in making substantially more frequent Qt patch releases >>> than before, it may still be better if user would have the option to update >>> some parts (like QWE) more frequently or out of sync. >>> >>>>>  I think what we should consider, is to perhaps carve out Qt WebEngine >>> from Qt as well. Not immediately, but for Qt 6 we should anyway consider >>> our current setup of essential and add-on modules. For the html5 engine >>> there is the matter of binary size in addition to release frequency. This is not >>> to say that we would stop developing html5 engine – just that it might be >>> beneficial to do in in different way than currently. >>> >>>>>  For new updated Qt Webkit, perhaps we could have it as a separate item >>> that works on top of Qt 5.9 for those to use it who prefer it over Qt >>> WebEngine. After it has existed for a while as a separate item, it is also easier >>> to know what would be the best way to get it into a Qt release – or is that >>> even necessary. >>> >>>> BTW, let me bring an attention to the elephant in the room. >>>> >>>> Yes, my fork of QtWebKit existed for a while as a separate item. But >>>> it was never and "official" successor, and even me myself was warning >>>> people that it is not an official replacement as some features are not yet >>> restored. >>> >>>> However, now there is no valid reason to keep using QtWebKit contained >>>> in 5.9 and dev branches anymore. Feature parity is achieved to the >>>> level of drop-in replacement that can be applied system-wide. Still many >>> people see 5.9 branch as a source of truth. >>> >>>> We need to convey a message to wide audience that old QtWebKit should >>>> no longer be used, and that there is a new release that should be used >>>> instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt >>> 5.2.x if people still use it (e.g., Ubuntu 14.04). >>> >>>> This is why question about version numbers and related stuff is >>>> important. If this is not done, it doesn't matter at all whatever tag >>>> names will be picked and what schedules will be followed. >>> >>> Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does >>> not exist, I think it should be to make exceptions in branch and release >>> management policies for >>> 5.9 and 5.9.0 branches, solely to resolve situation described above. >> >> Actually 'old ' webkit is in our builds but not part of official releases, see e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162 >> That is because we have agreed to keep it working and deliver src packages for the releases as well. Not part of official release but in addition. > > As I said in my other mail, we could easily drop those unsupported packages. Maybe quickly check whether the 5.8 packages compile against Qt 5.9. If they do, there’s no need at all to release packages that are the same, but remove the option of using the new version number for the updated engine. >>> I propose the following plan: >>> >>> 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to >>> "alpha" release, that has feature parity, but is not yet guaranteed to be >>> polished enough. >> To be honest, I don't want to do this now. From release schedule point of view it is just too late, we cannot risk our Qt 5.9.0 release schedule because of this. At this point 5.10 should be enough. For me it is ok if you want to add TP/Alpha etc in http://download.qt.io/community_releases/5.9/ but being part of official ci builds in '5.9.x' it is too risky. > > Yes, we can’t couple this to our Qt 5.9 release. It clearly comes too late for that. In the light of your announcement about 5.9 becoming LTS, I think it's especially important to get QtWebKit update in 5.9 branch. See below. > > In addition, I am not convinced it’s a too good idea, we were never really happy with that tight coupling for our web engine(s) in the past. So I’d propose we rather first try to figure out if we can keep those decoupled from a releasing perspective. This might create some challenges in how we handle things from a packaging/CI side, but working through those items might be helpful in the longer term, and something we could then start considering for web engine as well. QtTools module, that uses QtWebKit for Assistant, requires QtWebKit to be present in Qt5 superbuild. Yes, official builds use QtTextBrowser currenly, but 1) configuration with QtWebKit is in CI and 2) it was a source of many complaints, because people used to rely on availability of rich HTML renderer in Assistant. QtWebView module requires QtWebEngine on Linux and Windows in the same manner. Besides that, QtWebView currently does not support Windows/MinGW, as well as non-Linux POSIXish systems, that somewhat breaks its premise about providing browser component that works everywhere. Adding QtWebKit backend would fill this gap. So, while web engines don't need tight coupling with the rest of Qt, they are not leaf products and therefore have to be part of the superbuild, which implies being submodules of qt5.git with current state of things. And, taking into account Oswald's reply about our inability to use custom branch names in qt5 submodules, leads to requirement of updating 5.9 branch in qtwebkit in order to avoid proliferation of obsolete code. >From my side, I promise to investigate all possible problems in CI resulting from wip/next -> 5.9 merge as soon as possible, and do final release polishing before Qt 5.9.1 freeze. > > Cheers, > Lars > >>> 2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha >>> release at http://download.qt.io/community_releases/5.9/ >> This should be OK as well >> >>> 3. For dev branch, follow all necessary procedures to change status of >>> QtWebKit and make it work for Qt 5.10 without any schedule exceptions. >>> >>> [1] http://doc.qt.io/qt-5/qtmodules.html >>> >>>>>  Yours, >>>>> >>>>>          Tuukka >>>>> >>>>>  On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" >>> >> annulen at yandex.ru> wrote: >>> >>>>>      04.05.2017, 19:35, "Oswald Buddenhagen" >>> : >>>>>      > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev >>> wrote: >>>>>      >> 03.05.2017, 17:27, "Sergio Martins" : >>>>>      >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >>>>>      >> >> Remaining question is versioning. While it's fine to dub >>>>> current >>>>>      >> >> release "5.9" (but not 5.0, because we will have another >>>>> WebKit update >>>>>      >> >> in 5.10 time frame), using Qt versions in QtWebKit has >>> downsides: >>>>>      >> >> >>>>>      >> >> 1. It is not clear if 5.N+1 ships with the same WebKit >>>>> branch as 5.N, >>>>>      >> >> or is updated >>>>>      >> >> 2. It makes people believe that QtWebKit 5.N should be >>>>> used with Qt >>>>>      >> >> 5.N only. QtWebKit supports wide range of Qt versions >>>>> (starting from >>>>>      >> >> 5.2 as of now), and can be used e.g. as security update in >>>>> Linux >>>>>      >> >> distro that does not normally update Qt version during its life >>> cycle. >>>>>      >> >> >>>>>      >> >> Any comments? >>>>>      >> > >>>>>      >> > If Qt and QtWebKit will have different release schedules >>>>> then that >>>>>      >> > numbering would indeed confuse people. >>>>>      >> >>>>>      >> What about choice of new versioning scheme? >>>>>      >> >>>>>      >> I'm leaning towards "6.0.0" number, because it's larger than >>>>> any 5.x and makes it >>>>>      >> clear that versioning is different now. Bug fixes will >>>>> increment patch version (6.0.x), >>>>>      >> WebKit updates minor version (6.1.x etc), API/ABI breaking >>>>> changes - major >>>>>      >> verison (7.0 etc.) >>>>>      >> >>>>>      >> Qt5 supermodule will be tracking latest available stable >>>>> branch. When release branch >>>>>      >> is created (e.g. 5.10.0), corresponding patch release branch >>>>> is created in qtwebkit >>>>>      >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt >>> release branches. >>>>>      >> >>>>>      >> However, I'm not sure about two things: >>>>>      >> 1) Is it possible to have custom branch names in qtwebkit >>>>> repository, or there need to >>>>>      >> be virtual 5.10 etc. branches to match other modules? >>>>>      >> 2) What about bug tracking in JIRA? I would like to keep >>>>> existing issues as is, but assing >>>>>      >> new release numbers to items fixed in new releases >>>>>      > >>>>>      > i'll say outright that you can't be part of the qt supermodule >>>>> and yet >>>>>      > have independent releases. while that was the plan once upon a >>>>> time, the >>>>>      > whole release infrastructure simply doesn't deliver, and even >>>>> just >>>>>      > diverging branch names are a pita (proved by enginio). as a >>>>> product, qt >>>>>      > is as monolithic as ever. >>>>> >>>>>      Understood: no custom branch/tag names in official repo. >>>>> >>>>>      > >>>>>      > your release cycle concerns seem to be centered around the >>>>> webkit >>>>>      > backend, and you can deal with that by lowering the >>>>> compatibility >>>>>      > guarantees of patch releases at this level, i.e. take the >>>>> freedom to >>>>>      > upgrade webkit in a patch release. as long as you keep qt's >>>>> api/abi >>>>>      > compat promises, you're fine. that means that you will not be >>>>> able to >>>>>      > expose new webkit features until the next minor release if >>>>> they require >>>>>      > new api. >>>>> >>>>>      That's probably fine with me, except 2 moments that seem to require >>> "out of band" releases: >>> >>>>>      1. Something should be done with current release. As I said, >>>>> it's not an option to postpone >>>>>      it to 5.10, however it also cannot be released as 5.9.1 because >>>>> there are API additions >>>>>      which I don't want to revert (in particular because these APIs >>>>> were already shipped by >>>>>      Linux distros that chose to provide TP4 and TP5). Also there is >>>>> a change in QDataStream >>>>>      format of QWebHistory. >>>>> >>>>>      2. Security updates. WebKitGTK team provides several patch >>>>> releases for each stable branch, >>>>>      which contain only fixes for bugs and security issues, and >>>>> towards the end of release life cycle >>>>>      they became primarily security updates. I think we should be >>>>> able to release such updates ASAP, >>>>>      by making up some tag name and scheduling custom build against >>> newest patch release of Qt. >>> >>>>>      > _______________________________________________ >>>>>      > Development mailing list >>>>>      > Development at qt-project.org >>>>>      > http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>>      -- >>>>>      Regards, >>>>>      Konstantin >>>>>      _______________________________________________ >>>>>      Development mailing list >>>>>      Development at qt-project.org >>>>>      http://lists.qt-project.org/mailman/listinfo/development >>>> >>>> -- >>>> Regards, >>>> Konstantin >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Regards, >>> Konstantin >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From annulen at yandex.ru Tue May 9 19:13:38 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 09 May 2017 20:13:38 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <362941493925967@web48j.yandex.ru> <669E5717-6011-48A6-AC9A-EFF137EFBEF4@qt.io> <2864721493982925@web13j.yandex.ru> Message-ID: <8179041494350018@web31g.yandex.ru> An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Wed May 10 07:37:54 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 10 May 2017 05:37:54 +0000 Subject: [Development] JIra update and downtime on 10 May (starting 7:00 CEST) In-Reply-To: References: Message-ID: Just as a reminder, this work is currently in progress. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Alex Blasche > Sent: Monday, 1 May 2017 13:48 > To: development at qt-project.org > Cc: Andrey Leman > Subject: [Development] JIra update and downtime on 10 May (starting 7:00 > CEST) > > Hi, > > It's been some time since we gave Jira a more general update. It's time for the > next round. We will update from Jira 6.3 to Jira 7.3. The update will bring along > bug fixes and a minor face lift. In general it enables us to catch-up to Jira 's > general release cycle. > > We will upgrade Jira on 10 May starting at 7:00 am CEST. Current expectation is > that Jira will be back in business about 2 hrs later. I apologize for any > inconvenience that this downtime might bring along. > > If you have any questions beforehand or after the update, please contact Andrey > Leman (on CC) or me. > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Uwe.Rathmann at tigertal.de Wed May 10 09:00:22 2017 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Wed, 10 May 2017 07:00:22 +0000 (UTC) Subject: [Development] Release plan moving forward References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> Message-ID: On Tue, 09 May 2017 13:35:52 +0000, Lars Knoll wrote: > So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor > releases since 5.6 and a lot of good things have happened in Qt, so this > should be very good news to those of our users that don't always want to > be on the bleeding edge but are looking for a stable version that's > supported for a long time. Having more LTS releases is great, but I hope this does not mean, that support for previous LTS releases will end ? F.e. we have chosen 5.6 because of being a LTS release, hoping for "long" being something long. ciao, Uwe From andre.hartmann at iseg-hv.de Wed May 10 09:21:37 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Wed, 10 May 2017 09:21:37 +0200 Subject: [Development] Release plan moving forward In-Reply-To: References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> Message-ID: <28c0df84-b68c-6add-a882-6e7f676cfc95@iseg-hv.de> Hi Uwe, > On Tue, 09 May 2017 13:35:52 +0000, Lars Knoll wrote: > >> So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor >> releases since 5.6 and a lot of good things have happened in Qt, so this >> should be very good news to those of our users that don't always want to >> be on the bleeding edge but are looking for a stable version that's >> supported for a long time. > > Having more LTS releases is great, but I hope this does not mean, that > support for previous LTS releases will end ? > > F.e. we have chosen 5.6 because of being a LTS release, hoping for "long" > being something long. From Lars original mail: > Of course, we will also continue to support 5.6 for the promised > three years. We are planning to release 5.6.3 in Summer, after which > 5.6 will move into the 'very strict' mode as defined in the branch > policy QUIP. André > > ciao, > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Best regards / Mit freundlichen Grüßen André Hartmann, Dipl.-Ing. (FH) Software Project Manager iseg Spezialelektronik GmbH | phone: ++49 (0)351 26996-43 Bautzner Landstr. 23 | fax: ++49 (0)351 26996-21 D-01454 Radeberg / Rossendorf | web: www.iseg-hv.com Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID: DE812508942 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From alexander.blasche at qt.io Wed May 10 09:36:14 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 10 May 2017 07:36:14 +0000 Subject: [Development] JIra update and downtime on 10 May (starting 7:00 CEST) In-Reply-To: References: Message-ID: The upgrade just finished. Happy bugfixing. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Alex Blasche > Sent: Wednesday, 10 May 2017 07:38 > To: development at qt-project.org > Cc: Andrey Leman > Subject: Re: [Development] JIra update and downtime on 10 May (starting 7:00 > CEST) > > Just as a reminder, this work is currently in progress. > > -- > Alex > > > -----Original Message----- > > From: Development [mailto:development- > > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Alex > > bounces+Blasche > > Sent: Monday, 1 May 2017 13:48 > > To: development at qt-project.org > > Cc: Andrey Leman > > Subject: [Development] JIra update and downtime on 10 May (starting > > 7:00 > > CEST) > > > > Hi, > > > > It's been some time since we gave Jira a more general update. It's > > time for the next round. We will update from Jira 6.3 to Jira 7.3. The > > update will bring along bug fixes and a minor face lift. In general it > > enables us to catch-up to Jira 's general release cycle. > > > > We will upgrade Jira on 10 May starting at 7:00 am CEST. Current > > expectation is that Jira will be back in business about 2 hrs later. I > > apologize for any inconvenience that this downtime might bring along. > > > > If you have any questions beforehand or after the update, please > > contact Andrey Leman (on CC) or me. > > > > -- > > Alex > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Wed May 10 09:53:26 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 10 May 2017 07:53:26 +0000 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <20170504163513.GX2928@troll08> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru>,<20170504163513.GX2928@troll08> Message-ID: Oswald Buddenhagen (4 May 2017 18:35) > i'll say outright that you can't be part of the qt supermodule and yet > have independent releases. while that was the plan once upon a time, the > whole release infrastructure simply doesn't deliver, and even just > diverging branch names are a pita (proved by enginio). Can you elaborate on the pain here ? I note, in particular, that we do have sub-sub-modules on branches with eccentric names, or none (that is, what we use isn't obviously following any branch I can see). We seem to cope. I do confess life would be easier with uniform branch names, but git submodule should take care of most complications,. What would we need to do to our release infrastructure to make it cope with (as originally planned) independent release cycles for distinct components ? Eddy. From Uwe.Rathmann at tigertal.de Wed May 10 10:56:48 2017 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Wed, 10 May 2017 08:56:48 +0000 (UTC) Subject: [Development] Release plan moving forward References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> <28c0df84-b68c-6add-a882-6e7f676cfc95@iseg-hv.de> Message-ID: On Wed, 10 May 2017 09:21:37 +0200, André Hartmann wrote: > From Lars original mail: > > > Of course, we will also continue to support 5.6 for the promised > > three years. We are planning to release 5.6.3 in Summer, after which > > 5.6 will move into the 'very strict' mode as defined in the branch > > policy QUIP. Ah sorry - I missed that part. But when looking into the QUIP I read it as 5.6 is about to enter 'very strict' in the 3rd year - what would be summer 2018 considering the release of 5.6.0 ( March 2016 ) being the starting point, right ? So the announcement is about to cut the 'strict' stage by almost one year - what basically means a stop of fixing P0/P1 bugs 1 year before, what had been promised. Lars explains it because of new features in more recent versions. But being outdated is in the nature of any LTS release and IMHO can't be an argument for not taking the 5.6 promise seriously. ciao, Uwe From lars.knoll at qt.io Wed May 10 11:25:09 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 10 May 2017 09:25:09 +0000 Subject: [Development] Release plan moving forward In-Reply-To: References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> <28c0df84-b68c-6add-a882-6e7f676cfc95@iseg-hv.de> Message-ID: Hi Uwe, thanks for the feedback on the plan. So far this is the general outline, and some fine tuning can certainly be done. Would be good to hear more feedback from others as well. > On 10 May 2017, at 10:56, Uwe Rathmann wrote: > > On Wed, 10 May 2017 09:21:37 +0200, André Hartmann wrote: > >> From Lars original mail: >> >>> Of course, we will also continue to support 5.6 for the promised >>> three years. We are planning to release 5.6.3 in Summer, after which >>> 5.6 will move into the 'very strict' mode as defined in the branch >>> policy QUIP. > > Ah sorry - I missed that part. > > But when looking into the QUIP I read it as 5.6 is about to enter 'very > strict' in the 3rd year - what would be summer 2018 considering the > release of 5.6.0 ( March 2016 ) being the starting point, right ? > > So the announcement is about to cut the 'strict' stage by almost one year > - what basically means a stop of fixing P0/P1 bugs 1 year before, what > had been promised. 5.6.3 is planned for Summer (current plan is August), close to 18 months after the first release. So yes, the 'very strict’ mode would be coming somewhat early, but more by 6 months than a full year. I am in favour of getting onto the ‘very strict’ path a bit faster than mentioned in the QUIP for this version, but this will of course also depend on the feedback and bug reports we get on 5.6.3 once it’s out. Cheers, Lars > > Lars explains it because of new features in more recent versions. But > being outdated is in the nature of any LTS release and IMHO can't be an > argument for not taking the 5.6 promise seriously. > > ciao, > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tero.kojo at qt.io Wed May 10 12:47:17 2017 From: tero.kojo at qt.io (Tero Kojo) Date: Wed, 10 May 2017 10:47:17 +0000 Subject: [Development] Calls for Presentations open for Qt World Summit 2017 and Meeting C++ Message-ID: Hello, I'd like to remind everybody that we have the Call for Presentations for Qt World Summit 2017 open. https://www.qtworldsummit.com/call-for-presentations/ If you have anything that might be interesting to the Qt world, please take the time to submit your proposal. Topics can range from very technical to quite high level. And while I'm at it, Meeting C++ 2017 has their Call for Talks open too. And they are looking for especially new speakers: http://meetingcpp.com/index.php/newsreader/items/reaching-out-for-new-speakers-at-meeting-c-2017.html So if your topic is C++ related, and would be of interest to that audience, consider that as another possible venue. Best, Tero -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.burchell at crimson.no Wed May 10 12:51:10 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Wed, 10 May 2017 12:51:10 +0200 Subject: [Development] possible API freeze exception: would like to introduce QQuickItem::setAcceptTouchEvents() in 5.9 In-Reply-To: <3E3CD3E5-D143-4E58-9841-44F91F8861EA@qt.io> References: <3E3CD3E5-D143-4E58-9841-44F91F8861EA@qt.io> Message-ID: <1494413470.62789.971882832.4751A997@webmail.messagingengine.com> Hi, Let me start off by saying that I agree with you that this is a bad asymmetry, both for the end user, and for our own internal purposes -- which appears to be your primary motivator. I'm happy to see this addressed. On the other hand, this is a rather large change in behavior (whereby as I understand it, touch will stop working for custom items, and I know that there are a lot of them out there that take touch events) that will require code changes to adapt to. Not everyone can adapt their code -- some projects don't change after they release, some projects have other priorities, etc. In my opinion, requiring this kind of a change with only one minor release's notice is not something we should be doing given our focus on backwards compatibility. I'd be interested in hearing other opinions on list, so far I think I'm a tentative -1 to the idea. You mention that this is required due to optimizing the way that event delivery works internally in QQuickWindow -- have you considered restoring the old behavior there (despite it not being ideal, I think there's no disagreement there) possibly behind QT_MAJOR_VERSION guards, and switch it over to requiring registration for Qt 6? The reason that I ask is that I haven't ever seen what I would call a significant portion of time being taken up in the transversal part of event delivery -- it is of course non-zero, but the event handlers themselves (e.g. an onClicked handler in a MouseArea) are way, way more expensive which dwarf that cost in my experience... Robin -- Robin Burchell robin at crimson.no On Tue, May 9, 2017, at 06:43 PM, Shawn Rutledge wrote: > This is of concern only to those who subclass QQuickItem in C++ and build > custom items that handle touch events. > > There is a pretty bad API asymmetry which it’s surprising that we didn’t > notice enough to try to correct it earlier. If you want to accept mouse > events while any mouse button is clicked or held down or released, you > call setAcceptedMouseButtons(). QQuickWindow won’t bother trying to > deliver those events if you haven’t done that. Likewise if you want to > handle all mouse movement events, pressed or not, you must call > setAcceptHoverEvents(true). Imagine a world in which these didn’t exist: > QQuickWindow would need to deliver every mouse movement to every Item. > It would be unmanageable, performance would be unacceptable. > > The docs say that QGraphicsItem::setAcceptTouchEvents(bool) has existed > since Qt 4.6. If you are handling touch events in a graphics view > application, it’s required to call this. > > Yet for some odd reason, QQuickItem::setAcceptTouchEvents(bool) was never > added. > > In some parts of the code, we make the assumption that if you have called > setAcceptedMouseButtons(), you might want the touch events too. In other > parts, we don’t check… so in the simplest case, if you create a custom > item that handles touch events and stick it into your scene, you might > get the touch events with no further ado, if no other item prevents it. > > It’s now become unmanageable to continue without adding this function. > QtQuick Controls 2 has an issue that if you have a Popup with a shadow > Item, you can drag via touch within the thin shadow area around the > popup, and the events will go through, and you’ll be able to drag the > sidebar open for example, even though there’s a translucent Item in > between which is supposed to both dim the rest of the application, and > catch all the events, to prevent interacting with other controls while > the Popup is open. (Modal behavior.) > > In 5.10 we hope to introduce PointerHandlers, a big improvement on > MouseArea, PinchArea and MultiPointTouchArea. This has been in the works > for a couple of years now. So on the wip/pointerhandler branch, we > already have the requirement that setAcceptTouchEvents() must be called > if a custom Item wants to accept touch events. I thought maybe I could > find a way to make it optional: to avoid changing behavior of existing > custom items out in the wild, we would need it to default to true. That > is, assume that every Item might handle touch events, give every item a > chance… because it was that way before. Or at least, go on assuming that > if it wants mouse events, maybe we should try to deliver touch events > too. But along with introducing PointerHandlers, we have tried to > optimize event delivery and make it more deterministic: before we start > delivery, we build up a vector of all items to which delivery will be > attempted, in the right order (reverse paint order). Then we build up a > vector of pairs of items and their filtering parents (those which have > called setFiltersChildMouseEvents - Flickable being the main example of > that). So when we are doing the delivery, we no longer need to go up the > parent hierarchy for each and every item that we visit, looking again and > again for filtering parents. We no longer need a QSet just to keep track > of items that we have visited, to avoid visiting them again. BUT: if we > cannot know which items accept touch events and which don’t, this doesn’t > work, because we would have to include _every_ item which has a filtering > parent in that list of pairs, whether it would accept the touch event or > not. And the result of that is that we will call childMouseEventFilter() > too early in some cases, with the wrong item. "Hey Flickable, you’ve got > a Rectangle which is your child, I’m about to send it a TouchEvent, do > you want to intercept it?” Isn’t that stupid? Everybody knows Rectangle > doesn’t do anything with pointing-device events. But if Flickable > intercepts the event anyway, that means the MouseArea inside the > Rectangle won’t get exactly the same chance it had before (even though > Flickable is passive until the drag threshold is exceeded). Of course > Rectangle could call setAcceptTouchEvents(false) explicitly, but that > doesn’t take care of the custom items. Various Qt modules have custom > items too; so we don’t want to start getting bugs about those misbehaving > whenever they are used inside Flickable, for example. > > So to get the event delivery optimized as much as possible, it’s got to > be mandatory at some point to _subscribe_ in some way for touch events if > you need them. We can’t just assume, and spam every item with all > events. Assuming that wanting mouse events = wanting touch events is > wrong too. (It only made sense in a world in which all touch event > delivery was done by synthesizing artificial mouse events from > touchpoints. And that bad decision, the very worst architectural > decision in all of QtQuick, has caused several years of frustration for > me.) But I’ve been trying really hard to avoid changing any existing > behavior, to avoid breaking any existing tests, which is why we didn’t > come to this impasse sooner, I suppose. > > So I simply want to add the functions setAcceptTouchEvents(bool) and bool > acceptTouchEvents() right now, in 5.9.0. Behavior won’t change yet; > calling them will not be mandatory. But in 5.10, it might be mandatory. > > By the way, when we introduce PointerHandlers, the need to create custom > Items to handle touch events will be mostly obsolete anyway. (Still > supported of course, for now.) A PointerHandler is not an Item: it’s a > lighter weight QObject which exists just to handle events. Like a > behavioral facet of your visual item, rather than needing to be a > full-fledged (heavy) item like MouseArea is. You will be able to have > multiple PointerHandlers per Item. There will be public C++ API for > them. So even in complex use cases, you should be able to create custom > PointerHandlers rather than custom Items, if you don’t need to customize > the visual appearance. You won’t need to call setAcceptTouchEvents() on > the parent Item in order to enable the PointerHandlers, either; > QQuickWindow is already aware of them, and offers them events at the > appropriate time. > > I think that since mouse emulation has been enough for most use cases for > this long, there probably aren’t that many custom items out there > handling touch events directly; and for those that do, maybe it’s not too > much to ask for them to make one more little function call in their > constructors, before they upgrade to 5.10. But we can’t do that if the > function doesn't even exist yet in 5.9, to give them a grace period. And > 5.9 will be LTS… so the grace period will be quite long for those who > need it to be. > > The change in question is https://codereview.qt-project.org/#/c/193175/ > > My apologies for not noticing the need for this much earlier. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From robin.burchell at crimson.no Wed May 10 13:05:20 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Wed, 10 May 2017 13:05:20 +0200 Subject: [Development] Release plan moving forward In-Reply-To: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> Message-ID: <1494414320.944147.971895448.72705C2C@webmail.messagingengine.com> Hi, Responding to just the LTS news: I think that this is tentatively good news. I worry, though, on a releasing front whether it is realistic to consider supporting now two LTS branches, plus potentially 2-3 normal branches at the same time, especially since we don't yet have firm proof that we are able to even maintain a constant release cadence with the branches we have now. Can we get into a position where we can make a patch release every second month, say, so that security issues and high priority fixes don't have to wait half a year or more? The part of this that worries me is that I see 89 patches on just qtdeclarative/5.6 that aren't yet released, some of the highlights of the top of the commit log being: * Fix heap buffer overflow * Fixed assertion failure * Fix for dangling pointers (x 2) * Fix crash when ... ... and this was without looking for more than a minute or two. Right now, I honestly find it a bit difficult to recommend any given version -- right now, 5.6 is too old to offer a number of the things I would like to have, lags behind in performance, and has a number of unreleased fixes, but both 5.7 and 5.8 had their own share of problems in my opinion, and 5.9 isn't yet released. Just my (personal) $0.02... -- Robin Burchell robin at crimson.no On Tue, May 9, 2017, at 03:35 PM, Lars Knoll wrote: > Hi everybody, > > I believe I have some good news to share with regards to our releases > moving forward. As you all know, we had quite some trouble getting patch > level releases out over the last year, going so far that we ended up not > doing patch level releases for 5.8. > > Fortunately, things are starting to look a lot better now. You might > already have noticed the rolling beta releases for 5.9, where we have > pushed updated betas out every 1-2 weeks. This shows that things are now > going a lot smoother and we are in a much better shape to create releases > in the future. > > Additionally, things have improved on the CI and releasing side. It's > nowadays a lot easier to get a qt5.git update through and create new > packages from a successful qt5.git integration. In summer, the CI system > will get a major HW upgrade giving it a much larger capacity, avoiding > capacity conflicts between CI, packaging and release testing.Together > with improvements to the Release Test Automation (RTA) which > automatically tests our packages we're actually getting into a good > position to do patch level releases with relatively little manual labor > from 5.9 and onwards. This means that we should now be in a position to > do much more frequent patch level releases from 5.9 onwards. > > Another thing that has happened is that The Qt Company has been seeing > lots of requests for a new LTS release, as Qt 5.6 is starting to feel > relatively old. I have also heard this request from a few places in the > wider Qt community. Because of the improvements to CI/packaging and > releasing, I believe we are now in a good position to make that happen. > > So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor > releases since 5.6 and a lot of good things have happened in Qt, so this > should be very good news to those of our users that don't always want to > be on the bleeding edge but are looking for a stable version that's > supported for a long time. > > So once 5.9 is out, we are planning for rather frequent patch level > releases for that branch for the first 6-9 months. After that, we'll move > 5.9 into strict mode where we will also release a little less often, and > then have it in a very strict mode for the last year. See the draft QUIP > at https://codereview.qt-project.org/#/c/178906/45//ALL,unified for more > details on LTS branches. > > Of course, we will also continue to support 5.6 for the promised three > years. We are planning to release 5.6.3 in Summer, after which 5.6 will > move into the 'very strict' mode as defined in the branch policy QUIP. > > After 5.9, we'll be aiming at 5.10 in late autumn, 5.11 next spring. I > believe that we will be doing one more final LTS release on the Qt 5 > series, but most of the work after 5.11 will probably start to be aimed > on working towards Qt 6. > > Now let's not go into discussions what Qt 6 exactly will be in this > thread. I believe a lot of work towards defining what we're aiming at > with Qt 6 will be for the Contributor Summit in October. But the outline > above should give you good overview over the releases planned for the > next 18 months. > > Cheers, > Lars > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From alarrosa at suse.com Wed May 10 13:51:12 2017 From: alarrosa at suse.com (Antonio Larrosa) Date: Wed, 10 May 2017 13:51:12 +0200 Subject: [Development] Release plan moving forward In-Reply-To: References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> <28c0df84-b68c-6add-a882-6e7f676cfc95@iseg-hv.de> Message-ID: <618b6d07-13b8-89e0-b9a0-aa77ca998ac9@suse.com> On 10/05/17 11:25, Lars Knoll wrote: > Hi, > So we are now planning to make Qt 5.9 a LTS release. It's been 3 > minor releases since 5.6 and a lot of good things have happened in > Qt, so this should be very good news to those of our users that don't > always want to be on the bleeding edge but are looking for a stable > version that's supported for a long time. > This is really good news. We're now preparing the SLE-15 release for 2018 and I wanted to propose internally in SUSE to upgrade from the current Qt 5.6 to Qt 5.9. Since SLE aims for maximum stability, LTS releases are preferred, and making Qt 5.9 one would help to make the decision to upgrade a no-brainer. If we can fit the schedule (and I'm confident we'll be able to do so if 5.9 is not delayed), that would mean all SLE-15-based products would have Qt 5.9.x and thus, openSUSE Leap 15 (which is based on SLE) would also include Qt 5.9.x instead of Qt 5.6, which in turns would mean that we can upgrade Plasma in Leap to the next Plasma LTS release (since the latest Plasma release already requires at least Qt 5.7). So in short, Qt 5.9 being a LTS release is excellent news for us at SUSE/openSUSE and our users. (Just for completeness, note that we're already packaging/testing Qt 5.9 betas for openSUSE Tumbleweed so we'll probably publish that in Tumbleweed soon after it's officially release. This mail is mainly about the SLE/openSUSE Leap stable distributions). Greetings, -- Antonio Larrosa From Uwe.Rathmann at tigertal.de Wed May 10 14:19:10 2017 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Wed, 10 May 2017 12:19:10 +0000 (UTC) Subject: [Development] Release plan moving forward References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> <28c0df84-b68c-6add-a882-6e7f676cfc95@iseg-hv.de> Message-ID: Hi Lars, > 5.6.3 is planned for Summer (current plan is August), close to 18 months > after the first release. So yes, the 'very strict’ mode would be coming > somewhat early, but more by 6 months than a full year. Or to put it this way: 5.6 LTS guarantees, that all serious bugs found during the 5.9 ( guess also 5.10 ) cycle will make their way into 5.6. > I am in favour of getting onto the ‘very strict’ path a bit faster ... Coming from the user point of view I would vote for at least not dropping support for any LTS version until the following one goes into 'strict’ mode. So in this case 5.6 would not go into 'very strict’ before 5.10 is released. But you already gave a promise for 5.6: breaking it easily, compromises LTS promises in general - also the one you would like to make for 5.9. ciao, Uwe From Shawn.Rutledge at qt.io Wed May 10 14:23:39 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 10 May 2017 12:23:39 +0000 Subject: [Development] possible API freeze exception: would like to introduce QQuickItem::setAcceptTouchEvents() in 5.9 In-Reply-To: <1494413470.62789.971882832.4751A997@webmail.messagingengine.com> References: <3E3CD3E5-D143-4E58-9841-44F91F8861EA@qt.io> <1494413470.62789.971882832.4751A997@webmail.messagingengine.com> Message-ID: <139682BB-730A-4CF0-9222-D4DFE11D360C@qt.io> On May 10, 2017, at 12:51, Robin Burchell wrote: > You mention that this is required due to optimizing the way that event > delivery works internally in QQuickWindow -- have you considered > restoring the old behavior there (despite it not being ideal, I think > there's no disagreement there) possibly behind QT_MAJOR_VERSION guards, > and switch it over to requiring registration for Qt 6? I finally got enough hacks added to this https://codereview.qt-project.org/#/c/193245/ that all the tests passed. So yeah, that’s where we are headed now: we will add the accessors in 5.10, and probably require the use of them in Qt 6, unless we end up needing to do it sooner than that. From lars.knoll at qt.io Wed May 10 15:29:53 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 10 May 2017 13:29:53 +0000 Subject: [Development] Release plan moving forward In-Reply-To: <1494414320.944147.971895448.72705C2C@webmail.messagingengine.com> References: <171D8F75-0BC1-43EE-ABF2-B3D88B37F860@qt.io> <1494414320.944147.971895448.72705C2C@webmail.messagingengine.com> Message-ID: Hi, > On 10 May 2017, at 13:05, Robin Burchell wrote: > > Hi, > > Responding to just the LTS news: I think that this is tentatively good > news. I worry, though, on a releasing front whether it is realistic to > consider supporting now two LTS branches, plus potentially 2-3 normal > branches at the same time, especially since we don't yet have firm proof > that we are able to even maintain a constant release cadence with the > branches we have now. It’s not that bad. Once 5.9 is out, it’ll be the 5.9 and 5.6 branch we need to support, plus dev to maintain. Once 5.10 is out, 5.6 is starting to get two years old, so by then we should start being rather selective in the patches we still back-port. So I don’t see us having to maintain a lot more branches than we currently do. The 5.9 beta process shows some of the improvements. But yes, we’ll need to show proof that we can get more patch level releases out. > > Can we get into a position where we can make a patch release every > second month, say, so that security issues and high priority fixes don't > have to wait half a year or more? Yes, I believe we will be able to have those with 5.9 and later. > The part of this that worries me is > that I see 89 patches on just qtdeclarative/5.6 that aren't yet > released, some of the highlights of the top of the commit log being: > > * Fix heap buffer overflow > * Fixed assertion failure > * Fix for dangling pointers (x 2) > * Fix crash when ... > > ... and this was without looking for more than a minute or two. > > Right now, I honestly find it a bit difficult to recommend any given > version -- right now, 5.6 is too old to offer a number of the things I > would like to have, lags behind in performance, and has a number of > unreleased fixes, but both 5.7 and 5.8 had their own share of problems > in my opinion, and 5.9 isn't yet released. Agree, right now we don’t have a great release to recommend people to use. That’s what I hope we can change until summer with having 5.9 with regular patch level releases and an update to 5.6. Cheers, Lars > > Just my (personal) $0.02... > > -- > Robin Burchell > robin at crimson.no > > On Tue, May 9, 2017, at 03:35 PM, Lars Knoll wrote: >> Hi everybody, >> >> I believe I have some good news to share with regards to our releases >> moving forward. As you all know, we had quite some trouble getting patch >> level releases out over the last year, going so far that we ended up not >> doing patch level releases for 5.8. >> >> Fortunately, things are starting to look a lot better now. You might >> already have noticed the rolling beta releases for 5.9, where we have >> pushed updated betas out every 1-2 weeks. This shows that things are now >> going a lot smoother and we are in a much better shape to create releases >> in the future. >> >> Additionally, things have improved on the CI and releasing side. It's >> nowadays a lot easier to get a qt5.git update through and create new >> packages from a successful qt5.git integration. In summer, the CI system >> will get a major HW upgrade giving it a much larger capacity, avoiding >> capacity conflicts between CI, packaging and release testing.Together >> with improvements to the Release Test Automation (RTA) which >> automatically tests our packages we're actually getting into a good >> position to do patch level releases with relatively little manual labor >> from 5.9 and onwards. This means that we should now be in a position to >> do much more frequent patch level releases from 5.9 onwards. >> >> Another thing that has happened is that The Qt Company has been seeing >> lots of requests for a new LTS release, as Qt 5.6 is starting to feel >> relatively old. I have also heard this request from a few places in the >> wider Qt community. Because of the improvements to CI/packaging and >> releasing, I believe we are now in a good position to make that happen. >> >> So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor >> releases since 5.6 and a lot of good things have happened in Qt, so this >> should be very good news to those of our users that don't always want to >> be on the bleeding edge but are looking for a stable version that's >> supported for a long time. >> >> So once 5.9 is out, we are planning for rather frequent patch level >> releases for that branch for the first 6-9 months. After that, we'll move >> 5.9 into strict mode where we will also release a little less often, and >> then have it in a very strict mode for the last year. See the draft QUIP >> at https://codereview.qt-project.org/#/c/178906/45//ALL,unified for more >> details on LTS branches. >> >> Of course, we will also continue to support 5.6 for the promised three >> years. We are planning to release 5.6.3 in Summer, after which 5.6 will >> move into the 'very strict' mode as defined in the branch policy QUIP. >> >> After 5.9, we'll be aiming at 5.10 in late autumn, 5.11 next spring. I >> believe that we will be doing one more final LTS release on the Qt 5 >> series, but most of the work after 5.11 will probably start to be aimed >> on working towards Qt 6. >> >> Now let's not go into discussions what Qt 6 exactly will be in this >> thread. I believe a lot of work towards defining what we're aiming at >> with Qt 6 will be for the Contributor Summit in October. But the outline >> above should give you good overview over the releases planned for the >> next 18 months. >> >> 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 jani.heikkinen at qt.io Thu May 11 14:07:31 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 11 May 2017 12:07:31 +0000 Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files In-Reply-To: References: , , Message-ID: Hi all, Really many change files are still under construction/without any actions from maintainers. Please make sure those will be in latest tomorrow. Otherwise RC is most probably delayed because of missing change files br, Jani ________________________________________ From: Jani Heikkinen Sent: Friday, May 5, 2017 2:24 PM To: Simon Hausmann; development at qt-project.org Subject: Re: MAINTAINERS: your action needed: Qt 5.9.0 change files Initial change files are now created, please take those over & finalize as soon as possible br, Jani ________________________________________ From: Simon Hausmann Sent: Tuesday, May 2, 2017 5:09 PM To: Jani Heikkinen; development at qt-project.org Subject: Re: MAINTAINERS: your action needed: Qt 5.9.0 change files Hi, I'm a bit confused. The release team usually did the initial commit and maintainers edited the content. I'm fine with doing it myself, but I'm just wondering: Is there an intentional change in procedure? Simon ________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, May 2, 2017 12:26:14 PM To: development at qt-project.org Subject: [Development] MAINTAINERS: your action needed: Qt 5.9.0 change files Hi all Maintainers! Branching from '5.9' to '5.9.0' is now ongoing and it is time to start creating change files for Qt 5.9.0. Please do the initial ones as soon as possible. And if some important change is coming in after the initial ones are in change owner can (& have to) update the change file as well. I am hoping we could get the change files now in early enough instead of fighting which these just before release (and even delaying the release because of missing ones...) br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Thu May 11 15:09:49 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 11 May 2017 15:09:49 +0200 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> Message-ID: <20170511130949.GK2928@troll08> On Wed, May 10, 2017 at 09:53:26AM +0200, Edward Welbourne wrote: > Oswald Buddenhagen (4 May 2017 18:35) > > i'll say outright that you can't be part of the qt supermodule and yet > > have independent releases. while that was the plan once upon a time, the > > whole release infrastructure simply doesn't deliver, and even just > > diverging branch names are a pita (proved by enginio). > > Can you elaborate on the pain here ? > when the branch names are not uniform, they need to be derived from the repositories' actual contents (.qmake.conf, in particular). and that has historically been a mess because of lagging states due to late module additions, tardy version updates, and delayed merges and qt5 integrations. from the user perspective, diverging versions are a mess, because you never know what belongs together. that was particularly annoying with enginio, because there was no _reason_ for this being so. > I note, in particular, that we do have sub-sub-modules on branches > with eccentric names, or none > these sub-modules' branches are completely desynchronized with qt, so dealing with them is not part of the qt release cycle. qt simply pins sha1s, and the modules are not directly in our CI. > What would we need to do to our release infrastructure to make it > cope with (as originally planned) independent release cycles for > distinct components ? > i don't see how that would be logically possible at all as long as the rest of qt is released as a monolithic product and at the same time some qt modules depend on the prospective outliers. you would have to view the outlier as an external dependency, but that doesn't work because it depends on other qt modules, so it's circular. for additional illustration, consider jira: due to the differing versioning, you cannot use components for the outliers, but need separate products. as atomizing the release of most qt modules is totally unrealistic and counterproductive, there isn't a way forward to arrive at a consistent model which would accomodate that. oh, and then there are the processes for creating an actual release. have fun "forking" these for separate products ... From annulen at yandex.ru Thu May 11 15:28:14 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 11 May 2017 16:28:14 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <20170511130949.GK2928@troll08> References: <1711331493820157@web18j.yandex.ru> <401401493905905@web24j.yandex.ru> <20170504163513.GX2928@troll08> <20170511130949.GK2928@troll08> Message-ID: <1169251494509294@web4j.yandex.ru> 11.05.2017, 16:10, "Oswald Buddenhagen" : > On Wed, May 10, 2017 at 09:53:26AM +0200, Edward Welbourne wrote: >>     Oswald Buddenhagen (4 May 2017 18:35) >>     > i'll say outright that you can't be part of the qt supermodule and yet >>     > have independent releases. while that was the plan once upon a time, the >>     > whole release infrastructure simply doesn't deliver, and even just >>     > diverging branch names are a pita (proved by enginio). >> >>     Can you elaborate on the pain here ? > > when the branch names are not uniform, they need to be derived from the > repositories' actual contents (.qmake.conf, in particular). and that has > historically been a mess because of lagging states due to late module > additions, tardy version updates, and delayed merges and qt5 integrations. > > from the user perspective, diverging versions are a mess, because you > never know what belongs together. that was particularly annoying with > enginio, because there was no _reason_ for this being so. > >>     I note, in particular, that we do have sub-sub-modules on branches >>     with eccentric names, or none > > these sub-modules' branches are completely desynchronized with qt, so > dealing with them is not part of the qt release cycle. qt simply pins > sha1s, and the modules are not directly in our CI. > >>     What would we need to do to our release infrastructure to make it >>     cope with (as originally planned) independent release cycles for >>     distinct components ? > > i don't see how that would be logically possible at all as long as the > rest of qt is released as a monolithic product and at the same time some > qt modules depend on the prospective outliers. you would have to view > the outlier as an external dependency, but that doesn't work because it > depends on other qt modules, so it's circular. I would be possible to pin sha1 in qt5.git from the tip of current stable branch of the module, in the same manner as it's done now (except branch name will be different and may be upgraded between Qt's patch releases) As long as superbuild works, I don't see any technical problem with the "circular" dependency. > > for additional illustration, consider jira: due to the differing > versioning, you cannot use components for the outliers, but need > separate products. That's true. > > as atomizing the release of most qt modules is totally unrealistic and > counterproductive, there isn't a way forward to arrive at a consistent > model which would accomodate that. Why? For example, GNOME has a platform consisting of lots of libraries with independent versioning and release schedules, and it works because these libraries provide certain API/ABI guarantees > > oh, and then there are the processes for creating an actual release. > have fun "forking" these for separate products ... > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Thu May 11 19:23:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 May 2017 10:23:42 -0700 Subject: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit? In-Reply-To: <5106876.IVyibe7A3X@tjmaciei-mobl1> References: <1691504.8p7tJBIcV1@bola> <1930463.8hztgAgGOn@tjmaciei-mobl1> <5106876.IVyibe7A3X@tjmaciei-mobl1> Message-ID: <8844431.A5e0MFfMfc@tjmaciei-mobl1> On Saturday, 6 May 2017 13:06:59 PDT Thiago Macieira wrote: > On Saturday, 6 May 2017 12:48:57 PDT Thiago Macieira wrote: > > First, because the CI stops at the moment the first problem happens. So we > > don't know where else it may have happened. We only know where it did > > happen. > > > > Second, compiling to ARM requires cross-compilation. Since the problem > > happens because of cross-compilation, it happens for all ARM builds. > > Ok, here you go: I've just removed the ability to cross-compile QtDBus, > which in turn removes the need for a bootstrapped QtDBus and its tools in > the first place. > > https://codereview.qt-project.org/193827 > > Since I'm the maintainer for QtDBus, I've used my own maintainer privilege > and self-approved. This change wasn't necessary and I've abandoned it. The patches for 5.8 applied cleanly to 5.9.0 and were integrated, without change. That also means the fix for 5.6 is not valid. I've abandoned the 5.6 originals and will not backport. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Morten.Sorvig at qt.io Fri May 12 14:59:31 2017 From: Morten.Sorvig at qt.io (=?iso-8859-1?Q?Morten_S=F8rvig?=) Date: Fri, 12 May 2017 12:59:31 +0000 Subject: [Development] QUIP 8: High-DPI Support Message-ID: <1CA45ADA-5302-4F95-B49A-6E7573B7D043@qt.io> Hi all, A draft of QUIP 8: High-DPI Support is now available: https://codereview.qt-project.org/#/c/194524 Comments are welcome! Either here or on codereview. The plan is to write this up in there parts: 1) High-DPI terms and overview of other platforms 2) High-DPI support rationale for Qt 3) Documentation for the devicePixelRatio implementation The first part is available as a draft now and is intended to be a fairly neutral overview. Following parts will have increasing opinionatedness towards a specific approach and implementation. Morten From Simon.Hausmann at qt.io Sat May 13 12:15:54 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sat, 13 May 2017 10:15:54 +0000 Subject: [Development] CI down Message-ID: <52A9A795-473C-458E-8AA8-756314AB6405@qt.io> Hi, Due to severe problems in our data center the CI will be down until Monday :/ Simon From Eike.Ziller at qt.io Mon May 15 10:43:57 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 15 May 2017 08:43:57 +0000 Subject: [Development] Nominating Vikas Pachdha for Approver status Message-ID: Hereby I nominate Vikas Pachdha for Approver status. He has been defacto maintaining iOS support in Qt Creator since a year. https://codereview.qt-project.org/#/q/owner:%22Vikas+Pachdha%22+status:merged,n,z Br, -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Tobias.Hunger at qt.io Mon May 15 10:56:24 2017 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Mon, 15 May 2017 08:56:24 +0000 Subject: [Development] Nominating Vikas Pachdha for Approver status In-Reply-To: References: Message-ID: +1 from my side. I have been reviewing Vikas patches since he started. 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, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ________________________________________ From: Development on behalf of Eike Ziller Sent: Monday, May 15, 2017 10:43:57 AM To: Cc: qt-creator Subject: [Development] Nominating Vikas Pachdha for Approver status Hereby I nominate Vikas Pachdha for Approver status. He has been defacto maintaining iOS support in Qt Creator since a year. https://codereview.qt-project.org/#/q/owner:%22Vikas+Pachdha%22+status:merged,n,z Br, -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Riitta-Leena.Miettinen at qt.io Mon May 15 11:10:57 2017 From: Riitta-Leena.Miettinen at qt.io (Riitta-Leena Miettinen) Date: Mon, 15 May 2017 09:10:57 +0000 Subject: [Development] Nominating Vikas Pachdha for Approver status In-Reply-To: References: Message-ID: +1 Leena > -----Original Message----- > From: Qt-creator [mailto:qt-creator-bounces+riitta-leena.miettinen=qt.io at qt- > project.org] On Behalf Of Tobias Hunger > Sent: Montag, 15. Mai 2017 10:56 > To: Eike Ziller ; > > Cc: qt-creator > Subject: Re: [Qt-creator] Nominating Vikas Pachdha for Approver status > > +1 from my side. I have been reviewing Vikas patches since he started. > > 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, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 > B > > > ________________________________________ > From: Development project.org> on behalf of Eike Ziller > Sent: Monday, May 15, 2017 10:43:57 AM > To: > Cc: qt-creator > Subject: [Development] Nominating Vikas Pachdha for Approver status > > Hereby I nominate Vikas Pachdha for Approver status. He has been defacto > maintaining iOS support in Qt Creator since a year. > > https://codereview.qt- > project.org/#/q/owner:%22Vikas+Pachdha%22+status:merged,n,z > > Br, > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator From andy.shaw at qt.io Mon May 15 11:26:01 2017 From: andy.shaw at qt.io (Andy Shaw) Date: Mon, 15 May 2017 09:26:01 +0000 Subject: [Development] Nominating Katja Marttila for Approver status In-Reply-To: <98639F3B-238B-45F1-8B39-F5454A0B455A@qt.io> References: <2ae1ae6c-457b-3083-32bf-1aa5e32fcf9c@qt.io> <98639F3B-238B-45F1-8B39-F5454A0B455A@qt.io> Message-ID: <77E8E030-C219-4ADD-96B5-B196DFFB53EA@qt.io> Since it has been long past the 15 working days needed for this and no one objected, assuming it hasn’t already been done can someone fix the rights for Katja? Andy Andy Shaw skrev følgende den 05.04.2017, 10.08: +1 from me. Andy Development på vegne av Samuli Piippo skrev følgende den 05.04.2017, 09.07: Hi, I'd like to nominate Katja Marttila for Approver status. Katja has been working among other things as the maintainer for Qt Installer Framework for a while now. Her gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Katja+Marttila%22+status:+merged,n,z -samuli _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Mon May 15 12:43:44 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 15 May 2017 10:43:44 +0000 Subject: [Development] Nominating Katja Marttila for Approver status In-Reply-To: <77E8E030-C219-4ADD-96B5-B196DFFB53EA@qt.io> References: <2ae1ae6c-457b-3083-32bf-1aa5e32fcf9c@qt.io> <98639F3B-238B-45F1-8B39-F5454A0B455A@qt.io>, <77E8E030-C219-4ADD-96B5-B196DFFB53EA@qt.io> Message-ID: I tried twice to contact Katja on this topic as there were some questions around her accounts. Without this description I cannot proceed. The ball is clearly in Katja's corner. -- Alex ________________________________________ From: Development on behalf of Andy Shaw Sent: Monday, 15 May 2017 11:26:01 AM To: development at qt-project.org Subject: Re: [Development] Nominating Katja Marttila for Approver status Since it has been long past the 15 working days needed for this and no one objected, assuming it hasn’t already been done can someone fix the rights for Katja? Andy Andy Shaw skrev følgende den 05.04.2017, 10.08: +1 from me. Andy Development på vegne av Samuli Piippo skrev følgende den 05.04.2017, 09.07: Hi, I'd like to nominate Katja Marttila for Approver status. Katja has been working among other things as the maintainer for Qt Installer Framework for a while now. Her gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Katja+Marttila%22+status:+merged,n,z -samuli _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marten.nordheim at qt.io Mon May 15 14:49:19 2017 From: marten.nordheim at qt.io (=?Windows-1252?Q?M=E5rten_Nordheim?=) Date: Mon, 15 May 2017 12:49:19 +0000 Subject: [Development] Introducing discussion about QStringFormatter Message-ID: This discussion's about a proposed 'QStringFormatter' class (for which I put up an early WIP for here: https://codereview.qt-project.org/#/c/192873/ ) QStringFormatter is currently intended as a class to format strings and replace placeholders, like QString::arg does. But without the issues that QString::arg has. Such as the lack of an end-delimiter (enabling issues such as QString("%2%1").arg(1).arg(1) == "1"), having to parse the string multiple times (if using .arg-chaining). However, it also adds new features: - More formatting options, currently QString::arg only has a few options, with QStringFormatter we should initially match the options from QString and then extend the amount of options/features available. - Instead of only taking formatting options as arguments as in QString::arg, QStringFormatter will support taking formatting options as either in-string formatting or later (exact implementation not yet decided (see notes further down)) - Python: '{:>30}'.format('right aligned') - C#: String.Format("{0,30}", "right aligned"); - fmt(c++) fmt::format("{:>30}", "right aligned"); - Currently the WIP-version uses '$' as a separator between options and the identifier (i.e. "{1$>30}"), but this may change to match others such as python and fmt. - New, but familiar syntax. In various languages and libraries the curly braces are used to delimit replacement fields when formatting strings, for example: - Python: 'Hello, {0}'.format('World') - C#: String.Format("Hello, {0}", "World"); - fmt(c++): fmt::format("Hello, {0}", "World"); - Note: To print a curly brace they have to be doubled (same as in all of the above) ( "{{", "}}" ) - Named replacement fields. i.e. QStringFormatter("Hello, {name}").arg("name", "World"); - Python: 'Hello, {name}'.format(name='world') - C#: string name = "World"; $"Hello, {name}"; // uses string interpolation - fmt(c++): fmt::format("Hello, {name}, fmt::arg("name", "World")); While this makes it a 'replacement' for QString::arg, we are not going to remove QString::arg (at least not until *much* later.) 1. Why do we [not] want QStringFormatter in the library? 2. If QStringFormatter gets implemented, what are its hard requirements? 3. What are its soft requirements? And here are some notes I made for myself during the last week: - In-string formatting options are fine, but can not be the only way to specify formatting (bad for i18n because it becomes part of the text to translate) - Because of this I could implement a function, i.e. "setFormatting(QString id, QString options)" where 'options' gets parsed the same way as it would if it was in-string - (would also need an overload which takes 'int' for id) - could also have a separate function for each formatting option, e.g. "setPadding(id, amount)" - And/or add an overload of the ::arg functions with an extra argument for formatting, i.e "arg(id, string, format-string)" - wouldn't work work because of arg(QString, QString, QString) - Backwards compatibility with QString::arg - Since users would have to make source changes to start using QStringFormatter anyway I propose putting this BC-functionality behind a constructor-argument. - This should also disable parsing replacement fields with the '{...}'-syntax - Would avoid forcing them to change the string in case they already have curly-braces in any strings - Alternatively: put all BC functionality behind 'arg' and use another function-name for the new formatting style/functionality (e.g. '.format', '.subs') - pros: - clear distinction between the functions - the BC arg-overloads won't cause any issues with new functionality - No need to disable/enable anything - cons: - ??? (can’t think of any at the moment) - This is probably the better choice of the two.. - ::arg needs to return/be assignable to a QString (can be done using an implicit cast operator or by adding a new (non-explicit) constructor to QString) - i18n could be in a separate class/child-class - but it should be kept in mind during the design and implementation of this class to make i18n easier to implement - Mårten Nordheim -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Mon May 15 14:59:24 2017 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 15 May 2017 14:59:24 +0200 Subject: [Development] Calls for Presentations open for Qt World Summit 2017 and Meeting C++ In-Reply-To: References: Message-ID: <1534816.l7Z84bsULM@milian-kdab2> On Wednesday, May 10, 2017 12:47:17 PM CEST Tero Kojo wrote: > Hello, > > I'd like to remind everybody that we have the Call for Presentations for Qt > World Summit 2017 open. > https://www.qtworldsummit.com/call-for-presentations/ > If you have anything that might be interesting to the Qt world, please take > the time to submit your proposal. Topics can range from very technical to > quite high level. Tero, your decision to use surveymonkey for this has lead to a big problem: When I handed in one talk, I cannot easily hand in a second talk. The software tells me "You have already taken this survey." with no apparent way around this. Can you please tell me, and anyone else who may run into this situation, on how we can circumvent this obvious tool limitation? Thanks -- 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 marc.mutz at kdab.com Mon May 15 15:16:10 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 15 May 2017 15:16:10 +0200 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: Message-ID: <201705151516.10923.marc.mutz@kdab.com> On Monday 15 May 2017 14:49:19 Mårten Nordheim wrote: > 1. Why do we [not] want QStringFormatter in the library? con: already have enough formatters in Qt, better work on those than introducing something else _again_. pro: have too many formatters in Qt, add one that can encompass and replace all of them > 2. If QStringFormatter gets implemented, what are its hard requirements? To reach the 'pro' above, imo these are essential: Strictly More Featureful - Every formatting that can be implemented with the existing tools, QStringFormatter must support too. Not Less Performant - For every formatting that can be implemented with the existing tools, QStringFormatter's version must not be slower. > 3. What are its soft requirements? Not Less Concise - For every formatting that can be implemented with the existing tools, QStringFormatter's version must not be (much more) verbose. Open For Extension - Users can add formatting for their own types (like QStringBuilder allows, but using documented API). QDateTime, etc support to be added as examples. Compile-Time Checks - Like asprintf (on GCC) and QStringBuilder, the correctness is checked at compile-time (unlike arg()). Blend In - It should interoperate with the existing formatters until such a day as it replaces them. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From szehowe.koh at gmail.com Mon May 15 15:38:38 2017 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Mon, 15 May 2017 21:38:38 +0800 Subject: [Development] List of available Qt mirrors Message-ID: A user from China has reported that the Chinese mirrors are no longer visible to him [1]. I also don't see any when I visit http://download.qt.io/online/qtsdkrepository/windows_x86/root/qt/Updates.xml.mirrorlist (from Australia) Now, from my experience (which is a few years old and possibly outdated), the Chinese mirrors tend to perform quite poorly, even for users within China [2]. Nonetheless, I'm still surprised to see that they have vanished from the list; at least one server seems up to date [3]. Is this behaviour expected? Has the mirror management system been updated to hide mirrors that don't meet certain performance criteria or something like that? Regards, Sze-Howe [1] https://github.com/JKSH/QtSdkRepoChooser/issues/5 [2] http://lists.qt-project.org/pipermail/interest/2013-December/010336.html [3] http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Mon May 15 23:52:07 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 15 May 2017 23:52:07 +0200 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From tero.kojo at qt.io Tue May 16 09:23:44 2017 From: tero.kojo at qt.io (Tero Kojo) Date: Tue, 16 May 2017 07:23:44 +0000 Subject: [Development] Calls for Presentations open for Qt World Summit 2017 and Meeting C++ In-Reply-To: <1534816.l7Z84bsULM@milian-kdab2> References: <1534816.l7Z84bsULM@milian-kdab2> Message-ID: Thanks Milian, Looks like by default the option for multiple responses is turned off. Reading the manual helped, it should now be turned on. If it still doesn't work ping me directly. Best, Tero > -----Original Message----- > From: milian On Behalf Of Milian Wolff > Sent: 15 May 2017 15:59 > To: development at qt-project.org > Cc: Tero Kojo ; interest at qt-project.org > Subject: Re: [Development] Calls for Presentations open for Qt World Summit > 2017 and Meeting C++ > > On Wednesday, May 10, 2017 12:47:17 PM CEST Tero Kojo wrote: > > Hello, > > > > I'd like to remind everybody that we have the Call for Presentations for Qt > > World Summit 2017 open. > > https://www.qtworldsummit.com/call-for-presentations/ > > If you have anything that might be interesting to the Qt world, please take > > the time to submit your proposal. Topics can range from very technical to > > quite high level. > > Tero, > > your decision to use surveymonkey for this has lead to a big problem: When I > handed in one talk, I cannot easily hand in a second talk. The software tells > me "You have already taken this survey." with no apparent way around this. > > Can you please tell me, and anyone else who may run into this situation, on > how we can circumvent this obvious tool limitation? > > Thanks > > -- > 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 From edward.welbourne at qt.io Tue May 16 10:12:28 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 16 May 2017 08:12:28 +0000 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: , Message-ID: Jason H (15 May 2017 23:52): > Having worked with Python's format(), I much prefer the alterative {} > syntax, where {} defers to the next paramter. > '{}{}{}'.format('a', 'b', 'c) == 'abc' > Which makes maintence much easier, However, it can be problematic for translation; some languages shall change word order, which is why it's desirable to provide *some* way for the order of substitutions to depart from the order of appearance in the format string. > partocuclarly when adding a parameter to the beginning. Otherwose your > statements get all out of whack: > '{3}{1}{2}'.format('b', 'c', 'a') == 'abc' where, I take it, the real-world example has lots of text between the formatters, 'the {3} brown {1} jumped over the lazy {2}' % ('fox', 'dog', 'quick') and renumbering the formatters to 'the {1} brown {2} jumped over the lazy {3}' % ('quick', 'fox', 'dog') gets to be tedious and susceptible to errors, particularly when the renumbering has to be propagated to every translation. None the less, it's a small price to pay for being translatable. > I's like the named formatter to take a QVariantMap (JS Object): > QVariantMap object; > object["name"]="World"; or object= {"name: 'World'} // from QML > QStringFormatter("Hello, {name}").arg(object); > > I'd also like to see QML get fomr formatting love as well. The named approach is, indeed, the best of both worlds; translation adapts naturally and additions don't require re-indexing. I suspect C++ programmers shall find it a bit heavy-weight (needing a hash, of some variety, to do simple formatting) but it likely feels much more natural at the QML level (just as it does in python). Eddy. From Eike.Ziller at qt.io Tue May 16 11:58:32 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Tue, 16 May 2017 09:58:32 +0000 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: Message-ID: > On May 16, 2017, at 10:12 AM, Edward Welbourne wrote: > > Jason H (15 May 2017 23:52): >> Having worked with Python's format(), I much prefer the alterative {} >> syntax, where {} defers to the next paramter. >> '{}{}{}'.format('a', 'b', 'c) == 'abc' >> Which makes maintence much easier, > > However, it can be problematic for translation; some languages shall > change word order, which is why it's desirable to provide *some* way for > the order of substitutions to depart from the order of appearance in the > format string. > >> partocuclarly when adding a parameter to the beginning. Otherwose your >> statements get all out of whack: >> '{3}{1}{2}'.format('b', 'c', 'a') == 'abc' > > where, I take it, the real-world example has lots of text between the > formatters, 'the {3} brown {1} jumped over the lazy {2}' % ('fox', > 'dog', 'quick') and renumbering the formatters to 'the {1} brown {2} > jumped over the lazy {3}' % ('quick', 'fox', 'dog') gets to be tedious > and susceptible to errors, particularly when the renumbering has to be > propagated to every translation. None the less, it's a small price to > pay for being translatable. > >> I's like the named formatter to take a QVariantMap (JS Object): >> QVariantMap object; >> object["name"]="World"; or object= {"name: 'World'} // from QML >> QStringFormatter("Hello, {name}").arg(object); >> >> I'd also like to see QML get fomr formatting love as well. > > The named approach is, indeed, the best of both worlds; translation > adapts naturally and additions don't require re-indexing. I suspect C++ > programmers shall find it a bit heavy-weight (needing a hash, of some > variety, to do simple formatting) but it likely feels much more natural > at the QML level (just as it does in python). With C++11 this can be written as QStringFormatter(“Hello, {name}”).arg({{“name”, “World”}}); which is at least still relatively concise. -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From announce at qt-project.org Tue May 16 14:20:18 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 16 May 2017 12:20:18 +0000 Subject: [Development] [Announce] Qt 5.9 beta4 available Message-ID: Hi all, Qt 5.9 beta4 is available. As earlier you can update it at the top of your Qt 5.9 beta(3) online installation or do clean installation by using qt online installer. Detailed instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer Beta4 should be last beta release & rc should be out quite soon. Original target was 17th May but currently we are targeting to get Qt 5.9.0 rc out at the beginning of next week. br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jani.heikkinen at qt.io Tue May 16 14:39:42 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 16 May 2017 12:39:42 +0000 Subject: [Development] Qt 5.9 beta4 available Message-ID: Hi all, Qt 5.9 beta4 is now available. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to beta3 can be found as an attachment. Please test the release and report your effort via https://wiki.qt.io/Qt59_release_testing. Beta4 should be last beta release & rc should be out quite soon. Original target was 17th May but currently we are targeting to get Qt 5.9.0 rc out at the beginning of next week. br, Jani Heikkinen Release Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.9.0-beta3-delta-beta4 Type: application/octet-stream Size: 33556 bytes Desc: qt5.9.0-beta3-delta-beta4 URL: From marc.mutz at kdab.com Tue May 16 15:14:39 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 16 May 2017 15:14:39 +0200 Subject: [Development] Dropping the option to disable QStringBuilder in 5.10? Message-ID: <201705161514.39790.marc.mutz@kdab.com> Hi, I'd like to suggest to drop the option to disable QStringBuilder-backed op+ in Qt 5.10. We have been compiling Qt itself with QStringBuilder-backed op+ and have seen very little breakages (mainly in qmake, with its own string type). The reason to drop it is that QStringBuilder is a lot more maintainable than op+, since adding a new supported type is O(1) instead of O(N), N = #of existing supported types: You just specialise QConcatenable, instead of adding { op+(new, old), op+(old, new) | old \in already-supported-types } And we have been adding a lot of such types for 5.10: char16_t, char16_t*, char16_t[N], QStringView, and there are obvious next candidates: std:: (u16)string, wchar_t{,*,[N]}, std::(u16)string_view, CFString, NSString, ... Any objections? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From photonlili at gmail.com Tue May 16 15:36:30 2017 From: photonlili at gmail.com (Li Xu) Date: Tue, 16 May 2017 21:36:30 +0800 Subject: [Development] List of available Qt mirrors In-Reply-To: References: Message-ID: hi, I got 4 mirrors from the link from China mainland, http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/windows_x86/root/qt/Updates.xml (cn, prio 100) http://mirrors.tuna.tsinghua.edu.cn/qt/online/qtsdkrepository/windows_x86/root/qt/Updates.xml (cn, prio 100) http://mirror.bit.edu.cn/qtproject/online/qtsdkrepository/windows_x86/root/qt/Updates.xml (cn, prio 100) http://mirrors.neusoft.edu.cn/qt/online/qtsdkrepository/windows_x86/root/qt/Updates.xml (cn, prio 100) I don't think they are vanished from list, mb they were just not there when you were not located in China. Regards, Li On Mon, May 15, 2017 at 9:38 PM, Sze Howe Koh wrote: > A user from China has reported that the Chinese mirrors are no longer > visible to him [1]. I also don't see any when I visit > http://download.qt.io/online/qtsdkrepository/windows_x86/root/qt/Updates. > xml.mirrorlist (from Australia) > > Now, from my experience (which is a few years old and possibly outdated), > the Chinese mirrors tend to perform quite poorly, even for users within > China [2]. Nonetheless, I'm still surprised to see that they have vanished > from the list; at least one server seems up to date [3]. > > Is this behaviour expected? Has the mirror management system been updated > to hide mirrors that don't meet certain performance criteria or something > like that? > > > Regards, > Sze-Howe > > [1] https://github.com/JKSH/QtSdkRepoChooser/issues/5 > [2] http://lists.qt-project.org/pipermail/interest/2013- > December/010336.html > [3] http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/ > > _______________________________________________ > 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 jhihn at gmx.com Tue May 16 15:50:18 2017 From: jhihn at gmx.com (Jason H) Date: Tue, 16 May 2017 15:50:18 +0200 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: Message-ID: I'm not saying one or the other, python supports both, I'm saying let the developer choose. If positions change, but arg order doesn't, then by all means you must use numbered args. But if the developer doesn't need that then don't make the developer have to maintain it. "Code less. Create more." I also wonder about the SQL bound parameter interface? That formatting is a mash of :? or :name or something else (":1"?). I think for consistency, that should be able to use whatever the rest of the toolkit does too. *Apologies to Edward. First reply was not "to-all". > Sent: Tuesday, May 16, 2017 at 4:12 AM > From: "Edward Welbourne" > To: "Jason H" , "Mårten Nordheim" > Cc: "development at qt-project.org" > Subject: Re: [Development] Introducing discussion about QStringFormatter > > Jason H (15 May 2017 23:52): > > Having worked with Python's format(), I much prefer the alterative {} > > syntax, where {} defers to the next paramter. > > '{}{}{}'.format('a', 'b', 'c) == 'abc' > > Which makes maintence much easier, > > However, it can be problematic for translation; some languages shall > change word order, which is why it's desirable to provide *some* way for > the order of substitutions to depart from the order of appearance in the > format string. > > > partocuclarly when adding a parameter to the beginning. Otherwose your > > statements get all out of whack: > > '{3}{1}{2}'.format('b', 'c', 'a') == 'abc' > > where, I take it, the real-world example has lots of text between the > formatters, 'the {3} brown {1} jumped over the lazy {2}' % ('fox', > 'dog', 'quick') and renumbering the formatters to 'the {1} brown {2} > jumped over the lazy {3}' % ('quick', 'fox', 'dog') gets to be tedious > and susceptible to errors, particularly when the renumbering has to be > propagated to every translation. None the less, it's a small price to > pay for being translatable. > > > I's like the named formatter to take a QVariantMap (JS Object): > > QVariantMap object; > > object["name"]="World"; or object= {"name: 'World'} // from QML > > QStringFormatter("Hello, {name}").arg(object); > > > > I'd also like to see QML get fomr formatting love as well. > > The named approach is, indeed, the best of both worlds; translation > adapts naturally and additions don't require re-indexing. I suspect C++ > programmers shall find it a bit heavy-weight (needing a hash, of some > variety, to do simple formatting) but it likely feels much more natural > at the QML level (just as it does in python). > > Eddy. > From robin.burchell at crimson.no Tue May 16 15:55:45 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Tue, 16 May 2017 15:55:45 +0200 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: Message-ID: <1494942945.3102311.978345936.35137921@webmail.messagingengine.com> On Mon, May 15, 2017, at 02:49 PM, Mårten Nordheim wrote: > 3. What are its soft requirements? One very low priority item floating around on my wishlist would be formatting for QByteArray as well, though this is of course a bit of a task. But it would be useful for cases when you want to avoid the conversion penalty. -- Robin Burchell robin at crimson.no From Shawn.Rutledge at qt.io Tue May 16 16:15:55 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 16 May 2017 14:15:55 +0000 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: <201705151516.10923.marc.mutz@kdab.com> References: <201705151516.10923.marc.mutz@kdab.com> Message-ID: <9B874A30-0C9C-4466-9619-6F4FD5109660@qt.io> > On 15 May 2017, at 15:16, Marc Mutz wrote: > > Open For Extension - Users can add formatting for their own types (like > QStringBuilder allows, but using documented API). QDateTime, etc support to > be added as examples. We’ve been writing QDebug operator<<(QDebug debug, const QType &o) a lot. I wish we could rather write something which generates a string, for each Qt type, and then reuse it for debug operators, for string concatenation, for formatting like this, and also make sure that console.log() in QML uses it. Same pattern as toString() in Java, but maybe in C++ an operator makes more sense, as long as it’s not clumsy to use. From t.artikov at gmail.com Tue May 16 18:43:36 2017 From: t.artikov at gmail.com (=?UTF-8?B?0KLQuNC80YPRgCDQkNGA0YLQuNC60L7Qsg==?=) Date: Tue, 16 May 2017 23:43:36 +0700 Subject: [Development] Qt 5.9 beta4 available In-Reply-To: References: Message-ID: Hi, I believe, QTBUG-60547 should be fixed before the release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.burchell at crimson.no Tue May 16 19:14:03 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Tue, 16 May 2017 19:14:03 +0200 Subject: [Development] Qt 5.9 beta4 available In-Reply-To: References: Message-ID: <1494954843.4029733.978596944.35B2EE3F@webmail.messagingengine.com> Thanks for the report. I'll take a look at finishing this tonight. -- Robin Burchell robin at crimson.no On Tue, May 16, 2017, at 06:43 PM, Тимур Артиков wrote: > Hi, > I believe, QTBUG-60547 should be fixed before the release. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue May 16 19:14:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 May 2017 10:14:26 -0700 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: Message-ID: <3721235.bBHMokTBBM@tjmaciei-mobl1> On terça-feira, 16 de maio de 2017 06:50:18 PDT Jason H wrote: > I also wonder about the SQL bound parameter interface? That formatting is a > mash of :? or :name or something else (":1"?). I think for consistency, > that should be able to use whatever the rest of the toolkit does too. Choose one only. I don't think the :1 syntax offers any advantage over %1, so it's out of consideration: it's only as good as what we already have. I'd prefer we kept the % syntax which we already have, but from the discussion, it looks like it won't work. We need a syntax that has a clear open and close so that more options can be placed inside the placeholder. On {}{}: I think that's an acceptable shorthand, just like we have "%1 is %1" today. A bracket without any digits has higher replacement precedence than {0}: "The {0} brown {} jumped over the {2} {3}" % ("fox", "quick", "dog", "lazy") {} gets replaced ahead of {0}, then {0}, then {2} because {1} is missing, then {3}. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From robin.burchell at crimson.no Tue May 16 19:20:55 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Tue, 16 May 2017 19:20:55 +0200 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: <3721235.bBHMokTBBM@tjmaciei-mobl1> References: <3721235.bBHMokTBBM@tjmaciei-mobl1> Message-ID: <1494955255.4030958.978602336.66F52B0A@webmail.messagingengine.com> On Tue, May 16, 2017, at 07:14 PM, Thiago Macieira wrote: > I'd prefer we kept the % syntax which we already have, but from the > discussion, it looks like it won't work. We need a syntax that has a > clear > open and close so that more options can be placed inside the placeholder. A potential additional advantage of using braces (which you include in your examples) is that they are familiar from use elsewhere: https://msdn.microsoft.com/en-us/library/txafckwd(v=vs.110).aspx. -- Robin Burchell robin at crimson.no From thiago.macieira at intel.com Tue May 16 19:23:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 May 2017 10:23:42 -0700 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: Message-ID: <15906223.KDZOOGEy79@tjmaciei-mobl1> On segunda-feira, 15 de maio de 2017 05:49:19 PDT Mårten Nordheim wrote: > - Note: To print a curly brace they have to be doubled (same > as in all of the above) ( "{{", "}}" ) Why do we need a double closing curly brace? This is not a valid sequence: "Closing Brace: }" Or would the formatter complain if it found that? > - Backwards compatibility with QString::arg > - Since users would have to make source changes to start > using QStringFormatter anyway I propose putting this > BC-functionality behind a constructor-argument. > - This should also disable parsing > replacement fields with the '{...}'-syntax > - Would avoid forcing them to > change the string in case > they already have > curly-braces in any strings I think it's a good idea to choose one or the other, but not both. That allows us to avoid having multiply-escaped tokens or anything weird. > - Alternatively: put all BC functionality > behind 'arg' and use another function-name > for the new formatting style/functionality > (e.g. '.format', '.subs') The choice of whether to use a constructor or a differently-named function will depend on the design choice for your API. So it's up to you. Please consider, in terms of Qt API design (ease of use, surprise factor, etc.) just what the following should do: QStringFormatter("%1 is {1}").arg("foo").subs("bar") > - i18n could be in a separate class/child-class > - but it should be kept in mind during the design and > implementation of this class to make i18n easier to > implement No, the MAIN purpose of the formatter is i18n. Therefore, this needs to be in the base class and designed from the get-go. Formatted output to files is a secondary goal (we already have QTextStream). Formatted output to the console is a tertiary goal, or even a non-goal. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 16 19:30:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 May 2017 10:30:06 -0700 Subject: [Development] Dropping the option to disable QStringBuilder in 5.10? In-Reply-To: <201705161514.39790.marc.mutz@kdab.com> References: <201705161514.39790.marc.mutz@kdab.com> Message-ID: <298999810.O7SkVZNtR1@tjmaciei-mobl1> On Tuesday, 16 May 2017 06:14:39 PDT Marc Mutz wrote: > Hi, > > I'd like to suggest to drop the option to disable QStringBuilder-backed op+ > in Qt 5.10. We have been compiling Qt itself with QStringBuilder-backed op+ > and have seen very little breakages (mainly in qmake, with its own string > type). > > The reason to drop it is that QStringBuilder is a lot more maintainable than > op+, since adding a new supported type is O(1) instead of O(N), N = #of > existing supported types: You just specialise QConcatenable, instead of > adding > > { op+(new, old), op+(old, new) | old \in already-supported-types } > > And we have been adding a lot of such types for 5.10: char16_t, char16_t*, > char16_t[N], QStringView, and there are obvious next candidates: std:: > (u16)string, wchar_t{,*,[N]}, std::(u16)string_view, CFString, NSString, ... It's a source-incompatible change: template void f(T); QString s = "Hello"; f((s + " %1").arg("World")); The above has problems with QStringBuilder and QStringArgBuilder: when the op+ is enabled, s + " %1" is not a QString, it's a QStringBuilder and that's a type that does not have .arg(). When QStringArgBuilder is enabled, the result from .arg() is not a QString, but a QStringArgBuilder (which derives from QString, so it has .left()), but then the template function is called with the wrong type. If you dropped the .arg, it would be calling the wrong template function. And in the presence of C++11 auto, the problem exists elsewhere too. So I think this needs to be left as a Qt 6.0 change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oleg.yadrov at qt.io Tue May 16 19:45:49 2017 From: oleg.yadrov at qt.io (Oleg Yadrov) Date: Tue, 16 May 2017 17:45:49 +0000 Subject: [Development] Qt 5.9 beta4 available In-Reply-To: <1494954843.4029733.978596944.35B2EE3F@webmail.messagingengine.com> References: <1494954843.4029733.978596944.35B2EE3F@webmail.messagingengine.com> Message-ID: <678FC6F8-EE3D-4BA4-98C1-334AA634E401@qt.io> There is also another regression QTBUG-59704 which is still unsolved. -- Oleg Yadrov oleg.yadrov at qt.io > On May 16, 2017, at 1:14 PM, Robin Burchell wrote: > > Thanks for the report. I'll take a look at finishing this tonight. > > -- > Robin Burchell > robin at crimson.no > > On Tue, May 16, 2017, at 06:43 PM, Тимур Артиков wrote: >> Hi, >> I believe, QTBUG-60547 should be fixed before the release. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From chgans at gna.org Wed May 17 01:37:42 2017 From: chgans at gna.org (Ch'Gans) Date: Wed, 17 May 2017 11:37:42 +1200 Subject: [Development] List of available Qt mirrors In-Reply-To: References: Message-ID: On 17 May 2017 at 01:36, Li Xu wrote: > hi, > > I got 4 mirrors from the link from China mainland, > > http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/windows_x86/root/qt/Updates.xml > (cn, prio 100) > http://mirrors.tuna.tsinghua.edu.cn/qt/online/qtsdkrepository/windows_x86/root/qt/Updates.xml > (cn, prio 100) > http://mirror.bit.edu.cn/qtproject/online/qtsdkrepository/windows_x86/root/qt/Updates.xml > (cn, prio 100) > http://mirrors.neusoft.edu.cn/qt/online/qtsdkrepository/windows_x86/root/qt/Updates.xml > (cn, prio 100) >From New Zealand, I do not see the Chinese servers. I get 2 Japanese one at the top of the list, and then some European ones followed by Brazil and Canada. Chris > > I don't think they are vanished from list, mb they were just not there when > you were not located in China. > > Regards, > Li > > On Mon, May 15, 2017 at 9:38 PM, Sze Howe Koh wrote: >> >> A user from China has reported that the Chinese mirrors are no longer >> visible to him [1]. I also don't see any when I visit >> http://download.qt.io/online/qtsdkrepository/windows_x86/root/qt/Updates.xml.mirrorlist >> (from Australia) >> >> Now, from my experience (which is a few years old and possibly outdated), >> the Chinese mirrors tend to perform quite poorly, even for users within >> China [2]. Nonetheless, I'm still surprised to see that they have vanished >> from the list; at least one server seems up to date [3]. >> >> Is this behaviour expected? Has the mirror management system been updated >> to hide mirrors that don't meet certain performance criteria or something >> like that? >> >> >> Regards, >> Sze-Howe >> >> [1] https://github.com/JKSH/QtSdkRepoChooser/issues/5 >> [2] >> http://lists.qt-project.org/pipermail/interest/2013-December/010336.html >> [3] http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/ >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > > -- > 宇宙本身是靜止的，變化乃是幻覺，一種有趣的幻覺... > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From thiago.macieira at intel.com Wed May 17 18:19:13 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 May 2017 09:19:13 -0700 Subject: [Development] Stepping down as QtDBus maintainer Message-ID: <3424774.UGqyRmCA22@tjmaciei-mobl1> With https://codereview.qt-project.org/194893 getting integrated, this signals my inability to keep QtDBus working for 4 minor releases in a row (5.6 through 5.9, inclusive). Obviously, the patch that this change reverted is required and it is the only way I've supported QtDBus in the last 1½ years, but we don't seem to be able to make it work. Since I am unable to fulfill my duties as maintainer, I am stepping down and opening the way up for someone else. Good luck. I've just abandoned all my pending changes related to QtDBus. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Thu May 18 10:58:23 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 18 May 2017 11:58:23 +0300 Subject: [Development] QList In-Reply-To: <5004229.iNTmZlkdfe@tjmaciei-mobl1> References: <630451493242736@web49j.yandex.ru> <5004229.iNTmZlkdfe@tjmaciei-mobl1> Message-ID: On 27 April 2017 at 17:57, Thiago Macieira wrote: > On Thursday, 27 April 2017 01:19:16 -03 Marc Mutz wrote: >> On 2017-04-26 23:38, Konstantin Tokarev wrote: >> > 26.04.2017, 08:04, "Marc Mutz" : >> >> Users >> >> that need a queue can use std::deque. If you don't iterate over it, >> >> it's >> >> a more than acceptable container. >> > >> > std::deque is not a contiguous container, unlike QList or QVector >> >> Here's news for you: QList is not a contiguous container. > > Sometimes it is. Not relevant to this post, but the QUIP is here for review: https://codereview.qt-project.org/#/c/194984/ From marten.nordheim at qt.io Thu May 18 11:39:36 2017 From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=) Date: Thu, 18 May 2017 11:39:36 +0200 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: <15906223.KDZOOGEy79@tjmaciei-mobl1> References: <15906223.KDZOOGEy79@tjmaciei-mobl1> Message-ID: On 16.05.2017 19:23, Thiago Macieira wrote: > On segunda-feira, 15 de maio de 2017 05:49:19 PDT Mårten Nordheim wrote: >> - Note: To print a curly brace they have to be doubled (same >> as in all of the above) ( "{{", "}}" ) > Why do we need a double closing curly brace? This is not a valid sequence: > > "Closing Brace: }" > > Or would the formatter complain if it found that? This is enforced for consistency, not because it would cause a problem for the formatter: "{{ABC}" vs "{{abs}}" As well as the fact that it is also done this way in other libraries (I originally had '\\{' for escaping, but changed it.) >> - Alternatively: put all BC functionality >> behind 'arg' and use another function-name >> for the new formatting style/functionality >> (e.g. '.format', '.subs') > The choice of whether to use a constructor or a differently-named function > will depend on the design choice for your API. So it's up to you. > > Please consider, in terms of Qt API design (ease of use, surprise factor, > etc.) just what the following should do: > > QStringFormatter("%1 is {1}").arg("foo").subs("bar") Hm, hadn't thought that far ahead, thanks. I guess that would be hard to guess without reading the docs. In this case a constructor parameter is the better choice for BC. >> - i18n could be in a separate class/child-class >> - but it should be kept in mind during the design and >> implementation of this class to make i18n easier to >> implement > No, the MAIN purpose of the formatter is i18n. Therefore, this needs to be in > the base class and designed from the get-go. > > Formatted output to files is a secondary goal (we already have QTextStream). > Formatted output to the console is a tertiary goal, or even a non-goal. I'll have to look into and get back to this -- Mårten Nordheim From marten.nordheim at qt.io Thu May 18 11:57:43 2017 From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=) Date: Thu, 18 May 2017 11:57:43 +0200 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: <3721235.bBHMokTBBM@tjmaciei-mobl1> References: <3721235.bBHMokTBBM@tjmaciei-mobl1> Message-ID: <7975da6a-aef3-67c6-fd92-a2252eb4daee@qt.io> On 16.05.2017 19:14, Thiago Macieira wrote: > On {}{}: I think that's an acceptable shorthand, just like we have "%1 is %1" > today. A bracket without any digits has higher replacement precedence than > {0}: > > "The {0} brown {} jumped over the {2} {3}" % ("fox", "quick", "dog", "lazy") > > {} gets replaced ahead of {0}, then {0}, then {2} because {1} is missing, then > {3}. Hm, interesting approach to it, other approaches I've seen is: - {} gets assigned the first unused number (in your example it'd be equivalent to {1}) - No mixing between numbered and unnumbered placeholders But to clarify, in your scenario "{}{}" % ("a", "b") would be "ab", correct? -- Mårten Nordheim From sergio.martins at kdab.com Thu May 18 12:01:08 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 18 May 2017 11:01:08 +0100 Subject: [Development] Stepping down as QtDBus maintainer In-Reply-To: <3424774.UGqyRmCA22@tjmaciei-mobl1> References: <3424774.UGqyRmCA22@tjmaciei-mobl1> Message-ID: On 2017-05-17 17:19, Thiago Macieira wrote: > Since I am unable to fulfill my duties as maintainer, I am stepping > down and > opening the way up for someone else. Hi Thiago, Do you have an overview on what's the current state of the module ? Just so the next maintainer gets an idea of where to start. Anyway, thanks for the hours you've spent on it. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From lars.knoll at qt.io Thu May 18 12:46:12 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 18 May 2017 10:46:12 +0000 Subject: [Development] Stepping down as QtDBus maintainer In-Reply-To: <3424774.UGqyRmCA22@tjmaciei-mobl1> References: <3424774.UGqyRmCA22@tjmaciei-mobl1> Message-ID: Hi Thiago, thanks for all the efforts you’ve been putting into it over the years. > On 17 May 2017, at 18:19, Thiago Macieira wrote: > > With https://codereview.qt-project.org/194893 getting integrated, this signals > my inability to keep QtDBus working for 4 minor releases in a row (5.6 through > 5.9, inclusive). Obviously, the patch that this change reverted is required > and it is the only way I've supported QtDBus in the last 1½ years, but we > don't seem to be able to make it work. This is more showing that a situation where we only have one person working on (and knowing) a module is not sustainable. The changes you did were clearly going into the right direction, and will need to be picked up in one way or another. > > Since I am unable to fulfill my duties as maintainer, I am stepping down and > opening the way up for someone else. I’m currently trying to find someone else who can step up and get to know the module. It would be great if you could help that person get up to speed (once I found him/her). Lars > > Good luck. > > I've just abandoned all my pending changes related to QtDBus. > -- > 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 frederik.gladhorn at qt.io Thu May 18 12:58:19 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 18 May 2017 12:58:19 +0200 Subject: [Development] Stepping down as QtDBus maintainer In-Reply-To: <3424774.UGqyRmCA22@tjmaciei-mobl1> References: <3424774.UGqyRmCA22@tjmaciei-mobl1> Message-ID: <1690137.IIimfEr2lL@frederik-thinkcentre-m93p> Hello Thiago, Thanks a lot for all the great work on QtDBus! Cheers, Frederik On onsdag 17. mai 2017 09.19.13 CEST Thiago Macieira wrote: > With https://codereview.qt-project.org/194893 getting integrated, this > signals my inability to keep QtDBus working for 4 minor releases in a row > (5.6 through 5.9, inclusive). Obviously, the patch that this change > reverted is required and it is the only way I've supported QtDBus in the > last 1½ years, but we don't seem to be able to make it work. > > Since I am unable to fulfill my duties as maintainer, I am stepping down and > opening the way up for someone else. > > Good luck. > > I've just abandoned all my pending changes related to QtDBus. Isn't that a bit premature? Maybe someone could use these as inspiration. I'd like to see us (as in The Qt Project) be more flexible when it comes to ownership of patches - maybe someone feels inspired to take over some of the work that has been started and expand on it. From tony.sarajarvi at qt.io Thu May 18 14:42:58 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 18 May 2017 12:42:58 +0000 Subject: [Development] CI is down again In-Reply-To: References: Message-ID: Update: We're unsure why we a going at crawling speed on some parts of our infra. We could be facing hardware issues since we have restarted almost everything we have. Investigations are ongoing, and I can't give an ETA currently as to when we come back online. We need to find the reason first. -Tony --------------------------- We seem to have hardware issues which are under investigation. We'll be back online as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu May 18 17:43:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 May 2017 08:43:00 -0700 Subject: [Development] Stepping down as QtDBus maintainer In-Reply-To: <1690137.IIimfEr2lL@frederik-thinkcentre-m93p> References: <3424774.UGqyRmCA22@tjmaciei-mobl1> <1690137.IIimfEr2lL@frederik-thinkcentre-m93p> Message-ID: <2300637.PUflgxlDMf@tjmaciei-mobl1> On Thursday, 18 May 2017 03:58:19 PDT Frederik Gladhorn wrote: > Isn't that a bit premature? Maybe someone could use these as inspiration. > I'd like to see us (as in The Qt Project) be more flexible when it comes to > ownership of patches - maybe someone feels inspired to take over some of > the work that has been started and expand on it. They can always pick them up. I can un-abandon if they want to use the same reviews, or they can cherry-pick and re-submit. I did that for the qEnvironmentVariable change, for example. It was open for over 6 months because I was asked to let someone reuse the change. (I closed yesterday because no one was working on it) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 18 18:18:02 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 May 2017 09:18:02 -0700 Subject: [Development] Stepping down as QtDBus maintainer In-Reply-To: References: <3424774.UGqyRmCA22@tjmaciei-mobl1> Message-ID: <37382090.JDykJDu0zu@tjmaciei-mobl1> On Thursday, 18 May 2017 03:01:08 PDT Sergio Martins wrote: > On 2017-05-17 17:19, Thiago Macieira wrote: > > Since I am unable to fulfill my duties as maintainer, I am stepping > > down and > > opening the way up for someone else. > > Hi Thiago, > > Do you have an overview on what's the current state of the module ? Just > so the next maintainer gets an idea of where to start. Currently, the ONE important thing that QtDBus needs is to solve that crash- on-exit bug. It's been P1 since the new threading model was released in 5.6.0. After that, the module could be declared Done. It doesn't need much update and works almost just fine. There may be a couple of other issues that need to be addressed relating to the threading model, but I haven't received any reports recently. The biggest problem is that QDBusConnectionManager is a thread that runs until application exit and it outlives QCoreApplication (that's why QDaemonThread exists). And this runs into a problem with Windows: whenever ExitProcess is called, before each DLL's static destructors are run, the threads simply disappear. So global destructors may try to lock mutexes that are held by threads that are no longer running and, thus, cause a deadlock. That is the source of the deadlock that we've been seeing on the CI. Aside from that, my (dropped) patches were meant to clean up QtDBus. There are a couple of poor design choices that I made in 2006 that are still present. But mostly, they were meant to first constrain libdbus-1 requirements to a few places, as opposed to how they permeate all of QDBusMessage. This is already done, though there is one regression I know of for a bug that was fixed after I started developing back in 5.4 and 5.5 days. Eventually, the goal was to drop the libdbus-1 requirement and implement the protocol entirely in Qt code. Andreas Hartmetz has a number of patches on top of mine that go in that direction. But I never reviewed his contributions because they depended on getting mine out and mine depended on that P1 being fixed. I also developed a file-descriptor passing functionality for QNativeSocketEngine but haven't upstreamed that yet. QtDBus would then use QNativeSocketEngine directly (not QLocalSocket) and Andreas's marshalling and demarshalling code. So, as you can see, everything goes back to the problems that happen at exit, during global destruction, because QDBusConnectionManager must outlive QCoreApplication. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 18 18:20:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 May 2017 09:20:39 -0700 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: References: <15906223.KDZOOGEy79@tjmaciei-mobl1> Message-ID: <5667333.DVWLGCvmFf@tjmaciei-mobl1> On Thursday, 18 May 2017 02:39:36 PDT Mårten Nordheim wrote: > > Please consider, in terms of Qt API design (ease of use, surprise factor, > > etc.) just what the following should do: > > > > QStringFormatter("%1 is {1}").arg("foo").subs("bar") > > Hm, hadn't thought that far ahead, thanks. I guess that would be hard to > guess without reading the docs. In this case a constructor parameter is > the better choice for BC. That's exactly my point: please think of what would be the least surprise. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 18 18:22:14 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 May 2017 09:22:14 -0700 Subject: [Development] Introducing discussion about QStringFormatter In-Reply-To: <7975da6a-aef3-67c6-fd92-a2252eb4daee@qt.io> References: <3721235.bBHMokTBBM@tjmaciei-mobl1> <7975da6a-aef3-67c6-fd92-a2252eb4daee@qt.io> Message-ID: <7479605.6M2BTNHF3k@tjmaciei-mobl1> On Thursday, 18 May 2017 02:57:43 PDT Mårten Nordheim wrote: > But to clarify, in your scenario > "{}{}" % ("a", "b") > would be "ab", correct? That's what I would expect, yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tony.sarajarvi at qt.io Thu May 18 19:01:48 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 18 May 2017 17:01:48 +0000 Subject: [Development] CI is down again In-Reply-To: References: Message-ID: Update: Dell is investigating problems with the Compellent (our backend storage system). We're seeing huge latencies over our fiber optics there and the system can't be used atm. Their 24/7 crew is working on it as their P1. -Tony ---------------------- Update: We're unsure why we a going at crawling speed on some parts of our infra. We could be facing hardware issues since we have restarted almost everything we have. Investigations are ongoing, and I can't give an ETA currently as to when we come back online. We need to find the reason first. -Tony --------------------------- We seem to have hardware issues which are under investigation. We'll be back online as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Thu May 18 19:17:08 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 18 May 2017 17:17:08 +0000 Subject: [Development] CI problems Message-ID: Hi Seems my earlier 2 mails haven't reached you. I hope this one does. We've suffered hardware malfunction today. Our CI environment began behaving oddly aprox 20 hours ago and early this morning we noticed that not everything was OK. To prevent data loss and further problems, we shut down the CI. It took a lot of time to narrow the problem down, and we still aren't 100% sure where the problem is, but we have a good suspect currently. We have 24/7 teams on this issue trying to get everything fixed. Bear with us. We'll be back as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Thu May 18 22:46:07 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Thu, 18 May 2017 20:46:07 +0000 Subject: [Development] CI problems In-Reply-To: References: Message-ID: (Apparently it was just my own inbox not being updated 😉) It now looks like we have a running CI again! I started Coin and everything seems to be running as normal. I’ll keep watching it for a while longer and then resume work in the morning. Thanks for your patience. -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: torstaina 18. toukokuuta 2017 20.17 To: development at qt-project.org Subject: [Development] CI problems Hi Seems my earlier 2 mails haven’t reached you. I hope this one does. We’ve suffered hardware malfunction today. Our CI environment began behaving oddly aprox 20 hours ago and early this morning we noticed that not everything was OK. To prevent data loss and further problems, we shut down the CI. It took a lot of time to narrow the problem down, and we still aren’t 100% sure where the problem is, but we have a good suspect currently. We have 24/7 teams on this issue trying to get everything fixed. Bear with us. We’ll be back as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Thu May 18 23:53:59 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 18 May 2017 21:53:59 +0000 Subject: [Development] CI problems Message-ID: Awesome. Thanks, Tony (and others who worked to get this resolved quickly)! Yours, Tuukka From: Development on behalf of Tony Sarajärvi Date: Thursday, 18 May 2017 at 22.46 To: "development at qt-project.org" Subject: Re: [Development] CI problems (Apparently it was just my own inbox not being updated 😉) It now looks like we have a running CI again! I started Coin and everything seems to be running as normal. I’ll keep watching it for a while longer and then resume work in the morning. Thanks for your patience. -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: torstaina 18. toukokuuta 2017 20.17 To: development at qt-project.org Subject: [Development] CI problems Hi Seems my earlier 2 mails haven’t reached you. I hope this one does. We’ve suffered hardware malfunction today. Our CI environment began behaving oddly aprox 20 hours ago and early this morning we noticed that not everything was OK. To prevent data loss and further problems, we shut down the CI. It took a lot of time to narrow the problem down, and we still aren’t 100% sure where the problem is, but we have a good suspect currently. We have 24/7 teams on this issue trying to get everything fixed. Bear with us. We’ll be back as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.lemire at kdab.com Fri May 19 10:35:18 2017 From: paul.lemire at kdab.com (paul.lemire at kdab.com) Date: Fri, 19 May 2017 10:35:18 +0200 Subject: [Development] Qt3D git branch for VR experiments Message-ID: Hi, Could we have a new branch on the Qt3D repository so that we can push our experiments with VR headsets? Thanks, Paul From tony.sarajarvi at qt.io Fri May 19 11:16:43 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Fri, 19 May 2017 09:16:43 +0000 Subject: [Development] CI problems In-Reply-To: References: Message-ID: Hi again ☹ Something hit the fan again, and all CI systems came to a halt. IT has been contacted who will contact Dell immediately. I’ll keep you updated as I have receive info. -Tony From: Tuukka Turunen Sent: perjantaina 19. toukokuuta 2017 0.54 To: Tony Sarajärvi ; development at qt-project.org Subject: Re: [Development] CI problems Awesome. Thanks, Tony (and others who worked to get this resolved quickly)! Yours, Tuukka From: Development > on behalf of Tony Sarajärvi > Date: Thursday, 18 May 2017 at 22.46 To: "development at qt-project.org" > Subject: Re: [Development] CI problems (Apparently it was just my own inbox not being updated 😉) It now looks like we have a running CI again! I started Coin and everything seems to be running as normal. I’ll keep watching it for a while longer and then resume work in the morning. Thanks for your patience. -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: torstaina 18. toukokuuta 2017 20.17 To: development at qt-project.org Subject: [Development] CI problems Hi Seems my earlier 2 mails haven’t reached you. I hope this one does. We’ve suffered hardware malfunction today. Our CI environment began behaving oddly aprox 20 hours ago and early this morning we noticed that not everything was OK. To prevent data loss and further problems, we shut down the CI. It took a lot of time to narrow the problem down, and we still aren’t 100% sure where the problem is, but we have a good suspect currently. We have 24/7 teams on this issue trying to get everything fixed. Bear with us. We’ll be back as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Fri May 19 13:22:21 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 19 May 2017 11:22:21 +0000 Subject: [Development] Qt3D git branch for VR experiments In-Reply-To: References: Message-ID: <9A50C769-8534-4DAC-B69F-EEBF28A0F98D@qt.io> > On 19 May 2017, at 10:35, paul.lemire at kdab.com wrote: > > Hi, > > Could we have a new branch on the Qt3D repository so that we can push our experiments with VR headsets? +1 From oswald.buddenhagen at qt.io Fri May 19 14:53:23 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 19 May 2017 14:53:23 +0200 Subject: [Development] Qt3D git branch for VR experiments In-Reply-To: References: Message-ID: <20170519125323.GE30138@troll08> On Fri, May 19, 2017 at 10:35:18AM +0200, paul.lemire at kdab.com wrote: > Could we have a new branch on the Qt3D repository so that we can push > our experiments with VR headsets? > that's not how a branch request is supposed to look like. first read https://wiki.qt.io/Branch_Guidelines#Guidelines_for_your_own_branches then provide: - a justification why you actually need a branch at all - the branch type (mergable or throw-away) - ci use (if not implied by the previous point) - an actual name - a parent commit-ish also, there is no point in doing this in public unless you actually want to invite participation. From tony.sarajarvi at qt.io Fri May 19 20:36:45 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Fri, 19 May 2017 18:36:45 +0000 Subject: [Development] CI problems In-Reply-To: References: Message-ID: Better new this time. Aprox 3 hours ago I got green light to start the CI again. An hour into the run I stumbled upon a non-infra related small issue, which got fixed by a simple quick restart. After that builds have been running OK and as I saw first green results and commits being merged I felt confident to send this e-mail. So, all seem to be working again. (Fingers crossed) We have extra pair of eyes on the system this weekend, and I’ll keep you informed if it goes to a halt again. Thanks for your patience -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: perjantaina 19. toukokuuta 2017 12.17 To: development at qt-project.org Subject: Re: [Development] CI problems Hi again ☹ Something hit the fan again, and all CI systems came to a halt. IT has been contacted who will contact Dell immediately. I’ll keep you updated as I have receive info. -Tony From: Tuukka Turunen Sent: perjantaina 19. toukokuuta 2017 0.54 To: Tony Sarajärvi >; development at qt-project.org Subject: Re: [Development] CI problems Awesome. Thanks, Tony (and others who worked to get this resolved quickly)! Yours, Tuukka From: Development > on behalf of Tony Sarajärvi > Date: Thursday, 18 May 2017 at 22.46 To: "development at qt-project.org" > Subject: Re: [Development] CI problems (Apparently it was just my own inbox not being updated 😉) It now looks like we have a running CI again! I started Coin and everything seems to be running as normal. I’ll keep watching it for a while longer and then resume work in the morning. Thanks for your patience. -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: torstaina 18. toukokuuta 2017 20.17 To: development at qt-project.org Subject: [Development] CI problems Hi Seems my earlier 2 mails haven’t reached you. I hope this one does. We’ve suffered hardware malfunction today. Our CI environment began behaving oddly aprox 20 hours ago and early this morning we noticed that not everything was OK. To prevent data loss and further problems, we shut down the CI. It took a lot of time to narrow the problem down, and we still aren’t 100% sure where the problem is, but we have a good suspect currently. We have 24/7 teams on this issue trying to get everything fixed. Bear with us. We’ll be back as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Fri May 19 23:59:12 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 19 May 2017 21:59:12 +0000 Subject: [Development] CI problems In-Reply-To: References: , Message-ID: Thanks for the update and getting things back on track. Yours, Tuukka ________________________________ From: Development on behalf of Tony Sarajärvi Sent: Friday, May 19, 2017 9:36:45 PM To: development at qt-project.org Subject: Re: [Development] CI problems Better new this time. Aprox 3 hours ago I got green light to start the CI again. An hour into the run I stumbled upon a non-infra related small issue, which got fixed by a simple quick restart. After that builds have been running OK and as I saw first green results and commits being merged I felt confident to send this e-mail. So, all seem to be working again. (Fingers crossed) We have extra pair of eyes on the system this weekend, and I’ll keep you informed if it goes to a halt again. Thanks for your patience -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: perjantaina 19. toukokuuta 2017 12.17 To: development at qt-project.org Subject: Re: [Development] CI problems Hi again ☹ Something hit the fan again, and all CI systems came to a halt. IT has been contacted who will contact Dell immediately. I’ll keep you updated as I have receive info. -Tony From: Tuukka Turunen Sent: perjantaina 19. toukokuuta 2017 0.54 To: Tony Sarajärvi >; development at qt-project.org Subject: Re: [Development] CI problems Awesome. Thanks, Tony (and others who worked to get this resolved quickly)! Yours, Tuukka From: Development > on behalf of Tony Sarajärvi > Date: Thursday, 18 May 2017 at 22.46 To: "development at qt-project.org" > Subject: Re: [Development] CI problems (Apparently it was just my own inbox not being updated 😉) It now looks like we have a running CI again! I started Coin and everything seems to be running as normal. I’ll keep watching it for a while longer and then resume work in the morning. Thanks for your patience. -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: torstaina 18. toukokuuta 2017 20.17 To: development at qt-project.org Subject: [Development] CI problems Hi Seems my earlier 2 mails haven’t reached you. I hope this one does. We’ve suffered hardware malfunction today. Our CI environment began behaving oddly aprox 20 hours ago and early this morning we noticed that not everything was OK. To prevent data loss and further problems, we shut down the CI. It took a lot of time to narrow the problem down, and we still aren’t 100% sure where the problem is, but we have a good suspect currently. We have 24/7 teams on this issue trying to get everything fixed. Bear with us. We’ll be back as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Mon May 22 11:25:24 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 22 May 2017 09:25:24 +0000 Subject: [Development] CI down for maintenance Message-ID: Hi, The CI is down again, but this time for maintenance (adding disk space). Based on the current progress it seems that it will take another ~3 hours for the RAID rebuild to complete. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon May 22 12:04:10 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 22 May 2017 12:04:10 +0200 Subject: [Development] QUIP 6: removing top-level const from return types Message-ID: <201705221204.10619.marc.mutz@kdab.com> Hi, Removing top-level const from return types is a QUIP-6 Cat-A SiC, but was missing from the examples. https://codereview.qt-project.org/195285 proposes to add it to the QUIP. Precedence: E.g. https://codereview.qt-project.org/93161 Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Mon May 22 16:14:59 2017 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 22 May 2017 16:14:59 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <201705221204.10619.marc.mutz@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> Message-ID: <6182085.yAN09V0Lnr@maurice> Am Montag, 22. Mai 2017, 12:04:10 CEST schrieb Marc Mutz: > Hi, > > Removing top-level const from return types is a QUIP-6 Cat-A SiC, but was > missing from the examples. > > https://codereview.qt-project.org/195285 proposes to add it to the QUIP. > > Precedence: E.g. https://codereview.qt-project.org/93161 I think it's fine to break SiC in this case. Maybe we can have a QT_RETURNED_CONST_TYPE macro that would be defined to "const" iff Q_COMPILER_MANGLES_RETURN_TYPE is defined, or nothing otherwise. That way one would just write: QT_RETURNED_CONST_TYPE QPixmap pixmap() const; and we would avoid any #ifdef -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Mon May 22 17:54:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 May 2017 08:54:06 -0700 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <201705221204.10619.marc.mutz@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> Message-ID: <2205336.JKBrmnnpiH@tjmaciei-mobl1> On Monday, 22 May 2017 03:04:10 PDT Marc Mutz wrote: > Hi, > > Removing top-level const from return types is a QUIP-6 Cat-A SiC, but was > missing from the examples. > > https://codereview.qt-project.org/195285 proposes to add it to the QUIP. > > Precedence: E.g. https://codereview.qt-project.org/93161 I have yet to read the QUIP, but this seems like unimportant enough to be left alone until Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Mon May 22 19:42:05 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 22 May 2017 19:42:05 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <201705221204.10619.marc.mutz@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> Message-ID: <20170522174205.GA1540@klara.mpi.htwm.de> On Mon, May 22, 2017 at 12:04:10PM +0200, Marc Mutz wrote: > Hi, > > Removing top-level const from return types is a QUIP-6 Cat-A SiC, but was > missing from the examples. > > https://codereview.qt-project.org/195285 proposes to add it to the QUIP. I'd like to postpone this discussion until we have clarified the scope of QUIP-6. I don't have a fundamental problem of allowing removal of toplevel const in general, but I don't like to see wanton source incompatible changes that "can be worked around in user code without introducing Qt version checks" allowed, specifically not such that can behavioral changes in user code, or such that provide no observable gain and can easily be postponed until Qt 6. I'll try to come up with a request to clarify the scope of the QUIP, and depending on the outcome we could add removal of toplevel const to e.g. a whitelist of acceptable changes. > Precedence: E.g. https://codereview.qt-project.org/93161 I personally would not present my own changes as precedence for acceptable changes in discussion on whether my changes are acceptable. > Thanks, > Marc You are welcome. Andre' From apoenitz at t-online.de Mon May 22 20:14:01 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 22 May 2017 20:14:01 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <6182085.yAN09V0Lnr@maurice> References: <201705221204.10619.marc.mutz@kdab.com> <6182085.yAN09V0Lnr@maurice> Message-ID: <20170522181401.GB1540@klara.mpi.htwm.de> On Mon, May 22, 2017 at 04:14:59PM +0200, Olivier Goffart wrote: > Am Montag, 22. Mai 2017, 12:04:10 CEST schrieb Marc Mutz: > > Hi, > > > > Removing top-level const from return types is a QUIP-6 Cat-A SiC, but was > > missing from the examples. > > > > https://codereview.qt-project.org/195285 proposes to add it to the QUIP. > > > > Precedence: E.g. https://codereview.qt-project.org/93161 > > I think it's fine to break SiC in this case. > > Maybe we can have a QT_RETURNED_CONST_TYPE macro that would be defined to > "const" iff Q_COMPILER_MANGLES_RETURN_TYPE is defined, or nothing otherwise. > > That way one would just write: > > QT_RETURNED_CONST_TYPE QPixmap pixmap() const; > > and we would avoid any #ifdef That would be sensible and at least would remove part of the cosmetical atrocity this patch introduces. Note, however, that it was not this change that caused the current controversy, but https://codereview.qt-project.org/#/c/195229/ i.e. -const QPixmap QSplashScreen::pixmap() const +#if !defined(Q_QDOC) && defined(Q_COMPILER_MANGLES_RETURN_TYPE) && QT_VERSION < QT_VERSION_CHECK(6, 0, 0) +const +#endif ++QPixmap QSplashScreen::pixmap() const This introduces three lines of compiler-dependent #ifdef-ery - in a rarely used function - in a not-exactly-widely-used class - for absolutely no user-visible gain. I do not want the Qt code base develop into a direction where common activities like "declaring a trivial getter" are hidden behind a Jmulti-line preprocessor mess. If *that* code style is considered acceptable we do have a serious problem. Andre' From lars.knoll at qt.io Mon May 22 21:54:02 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 22 May 2017 19:54:02 +0000 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <20170522181401.GB1540@klara.mpi.htwm.de> References: <201705221204.10619.marc.mutz@kdab.com> <6182085.yAN09V0Lnr@maurice> <20170522181401.GB1540@klara.mpi.htwm.de> Message-ID: <7572A890-5025-4AC5-80E1-4FAFE28838C4@qt.io> On 22 May 2017, at 20:14, André Pönitz > wrote: On Mon, May 22, 2017 at 04:14:59PM +0200, Olivier Goffart wrote: Am Montag, 22. Mai 2017, 12:04:10 CEST schrieb Marc Mutz: Hi, Removing top-level const from return types is a QUIP-6 Cat-A SiC, but was missing from the examples. https://codereview.qt-project.org/195285 proposes to add it to the QUIP. Precedence: E.g. https://codereview.qt-project.org/93161 I think it's fine to break SiC in this case. Maybe we can have a QT_RETURNED_CONST_TYPE macro that would be defined to "const" iff Q_COMPILER_MANGLES_RETURN_TYPE is defined, or nothing otherwise. That way one would just write: QT_RETURNED_CONST_TYPE QPixmap pixmap() const; and we would avoid any #ifdef That would be sensible and at least would remove part of the cosmetical atrocity this patch introduces. Note, however, that it was not this change that caused the current controversy, but https://codereview.qt-project.org/#/c/195229/ i.e. -const QPixmap QSplashScreen::pixmap() const +#if !defined(Q_QDOC) && defined(Q_COMPILER_MANGLES_RETURN_TYPE) && QT_VERSION < QT_VERSION_CHECK(6, 0, 0) +const +#endif ++QPixmap QSplashScreen::pixmap() const This introduces three lines of compiler-dependent #ifdef-ery - in a rarely used function - in a not-exactly-widely-used class - for absolutely no user-visible gain. I do not want the Qt code base develop into a direction where common activities like "declaring a trivial getter" are hidden behind a Jmulti-line preprocessor mess. If *that* code style is considered acceptable we do have a serious problem. I have to agree with Andre here. The three line #ifdef'ery above is something I would only want to do if there is no other solution to a real problem getting Qt to compile. Removing the const from the returned pixmap here is mainly cosmetic, and I really haven't seen any reason why we couldn't delay changing this to Qt 6. We can of prepare already now by adding a macro that expands to const in Qt 5 and will trigger a compile error (or expand to empty) in Qt 6. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon May 22 23:05:46 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 22 May 2017 23:05:46 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <7572A890-5025-4AC5-80E1-4FAFE28838C4@qt.io> References: <201705221204.10619.marc.mutz@kdab.com> <6182085.yAN09V0Lnr@maurice> <20170522181401.GB1540@klara.mpi.htwm.de> <7572A890-5025-4AC5-80E1-4FAFE28838C4@qt.io> Message-ID: <830824717a50a8597cfbf8eef428f607@kdab.com> On 2017-05-22 21:54, Lars Knoll wrote: >> On 22 May 2017, at 20:14, André Pönitz >> wrote: >> >> On Mon, May 22, 2017 at 04:14:59PM +0200, Olivier Goffart wrote: >> Am Montag, 22. Mai 2017, 12:04:10 CEST schrieb Marc Mutz: >> Hi, >> >> Removing top-level const from return types is a QUIP-6 Cat-A SiC, >> but was >> missing from the examples. >> >> https://codereview.qt-project.org/195285 [1] proposes to add it to >> the QUIP. >> >> Precedence: E.g. https://codereview.qt-project.org/93161 [2] >> >> I think it's fine to break SiC in this case. >> >> Maybe we can have a QT_RETURNED_CONST_TYPE macro that would be >> defined to >> "const" iff Q_COMPILER_MANGLES_RETURN_TYPE is defined, or nothing >> otherwise. >> >> That way one would just write: >> >> QT_RETURNED_CONST_TYPE QPixmap pixmap() const; >> >> and we would avoid any #ifdef > > That would be sensible and at least would remove part of the > cosmetical > atrocity this patch introduces. > > Note, however, that it was not this change that caused the current > controversy, but https://codereview.qt-project.org/#/c/195229/ [3] > i.e. > > -const QPixmap QSplashScreen::pixmap() const > +#if !defined(Q_QDOC) && defined(Q_COMPILER_MANGLES_RETURN_TYPE) && > QT_VERSION < QT_VERSION_CHECK(6, 0, 0) > +const > +#endif > ++QPixmap QSplashScreen::pixmap() const > > This introduces three lines of compiler-dependent #ifdef-ery > - in a rarely used function > - in a not-exactly-widely-used class > - for absolutely no user-visible gain. > > I do not want the Qt code base develop into a direction where common > activities like "declaring a trivial getter" are hidden behind a > Jmulti-line preprocessor mess. > > If *that* code style is considered acceptable we do have a serious > problem. > > I have to agree with Andre here. The three line #ifdef'ery above is > something I would only want to do if there is no other solution to a > real problem getting Qt to compile. > > Removing the const from the returned pixmap here is mainly cosmetic, > and I really haven't seen any reason why we couldn't delay changing > this to Qt 6. We can of prepare already now by adding a macro that > expands to const in Qt 5 and will trigger a compile error (or expand > to empty) in Qt 6. The point is that this completely foils the purpose of QUIP-6, namely to have objective rules for (acceptable) SiCs. So we do _not_ have to deal with this unproductive subjective nonsense all the time. As one of the very few who actually deals with such API bugs, I can tell you that these opinionated "discussions" are a real drag on both productivity and motivation. These three lines _will_ _be_ _gone_ by Qt 6. Friedemann had certainly no problem reviewing them. There's really no reason for making such a fuss about it. None whatsoever. I look 5-10 years into the future. I suggest others to start doing the same. Maybe then you will come to the same conclusion, namely that that bit of temporary ifdefery is perfectly ok, esp. if the work has _already_ _been_ _done_. As for the macro, yeah, let's add it. We have Q_DECLARE_SHARED_NOT_MOVABLE_UNTIL_QT6, after all. The question is, of course, how many users that macro will see. Without more users, that will only move he #ifdefs to somewhere else. Because I, for one, will most certainly _not_ touch const return values anymore after this. And everyone else doesn't care. Thanks, Marc From thiago.macieira at intel.com Tue May 23 00:48:53 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 May 2017 15:48:53 -0700 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <830824717a50a8597cfbf8eef428f607@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> <7572A890-5025-4AC5-80E1-4FAFE28838C4@qt.io> <830824717a50a8597cfbf8eef428f607@kdab.com> Message-ID: <3249143.KQHYzqoKaS@tjmaciei-mobl1> On Monday, 22 May 2017 14:05:46 PDT Marc Mutz wrote: > The point is that this completely foils the purpose of QUIP-6, namely to > have objective rules for (acceptable) SiCs. So we do _not_ have to deal > with this unproductive subjective nonsense all the time Then we are right now concluding this kind of change should not be in that part of the QUIP. If there's no significant gain and if there is a significant loss in redability, and more importantly if there's a chance of existing code breaking, then it shouldn't be done. Period. Let's remove this from Category A. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue May 23 07:26:38 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 23 May 2017 07:26:38 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <3249143.KQHYzqoKaS@tjmaciei-mobl1> References: <201705221204.10619.marc.mutz@kdab.com> <830824717a50a8597cfbf8eef428f607@kdab.com> <3249143.KQHYzqoKaS@tjmaciei-mobl1> Message-ID: <201705230726.39402.marc.mutz@kdab.com> On Tuesday 23 May 2017 00:48:53 Thiago Macieira wrote: > Then we are right now concluding this kind of change should not be in that > part of the QUIP. The QUIP gives an _algorithm_ to categorise SiCs, it's not a listing. There's a list, yes. It's called _examples_. > if there's a chance of existing code breaking How can removing top-level const from a return type "break" existing code any more than adding a function overload? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From lars.knoll at qt.io Tue May 23 08:36:00 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 23 May 2017 06:36:00 +0000 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <201705230726.39402.marc.mutz@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> <830824717a50a8597cfbf8eef428f607@kdab.com> <3249143.KQHYzqoKaS@tjmaciei-mobl1> <201705230726.39402.marc.mutz@kdab.com> Message-ID: <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> > On 23 May 2017, at 07:26, Marc Mutz wrote: > > On Tuesday 23 May 2017 00:48:53 Thiago Macieira wrote: >> Then we are right now concluding this kind of change should not be in that >> part of the QUIP. > > The QUIP gives an _algorithm_ to categorise SiCs, it's not a listing. There's > a list, yes. It's called _examples_. > >> if there's a chance of existing code breaking > > How can removing top-level const from a return type "break" existing code any > more than adding a function overload? Probably not more than that, you are right. But what I dislike is the fact that we get different signatures on different platforms (because we can't change this on MSVC without breaking BC). That can cause some unwanted side effects (a detach happening on Linux, but not on MSVC), and incompatibilities in Qt between different platforms (code that compiles on Linux doesn't compile on MSVC). These are side effects of such a change that we need to take into account when considering whether it's worth changing this in 5.x. Cheers, Lars From olivier at woboq.com Tue May 23 08:59:12 2017 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 23 May 2017 08:59:12 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> References: <201705221204.10619.marc.mutz@kdab.com> <201705230726.39402.marc.mutz@kdab.com> <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> Message-ID: <18465731.lvChsIOdNs@maurice> Am Dienstag, 23. Mai 2017, 08:36:00 CEST schrieb Lars Knoll: > > On 23 May 2017, at 07:26, Marc Mutz wrote: > > > > On Tuesday 23 May 2017 00:48:53 Thiago Macieira wrote: > >> Then we are right now concluding this kind of change should not be in > >> that > >> part of the QUIP. > > > > The QUIP gives an _algorithm_ to categorise SiCs, it's not a listing. > > There's a list, yes. It's called _examples_. > > > >> if there's a chance of existing code breaking > > > > How can removing top-level const from a return type "break" existing code > > any more than adding a function overload? > > Probably not more than that, you are right. > > But what I dislike is the fact that we get different signatures on different > platforms (because we can't change this on MSVC without breaking BC). That > can cause some unwanted side effects (a detach happening on Linux, but not > on MSVC), and incompatibilities in Qt between different platforms (code > that compiles on Linux doesn't compile on MSVC). These are side effects of > such a change that we need to take into account when considering whether > it's worth changing this in 5.x. Another difference is that if one call QPixmap pix; //... pix = splashScreen->pixmap(); This would call the copy operator if the function return a const QPixmap, but the move operator if there is no const. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Andre.Poenitz at qt.io Tue May 23 09:10:35 2017 From: Andre.Poenitz at qt.io (Andre Poenitz) Date: Tue, 23 May 2017 07:10:35 +0000 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: References: <201705221204.10619.marc.mutz@kdab.com> <830824717a50a8597cfbf8eef428f607@kdab.com> <3249143.KQHYzqoKaS@tjmaciei-mobl1>, <201705230726.39402.marc.mutz@kdab.com>, Message-ID: marc.mutz wrote: > On Tuesday 23 May 2017 00:48:53 Thiago Macieira wrote: > > Then we are right now concluding this kind of change should not be in that > > part of the QUIP. > > The QUIP gives an _algorithm_ to categorise SiCs, it's not a listing. There's > a list, yes. It's called _examples_. > > > if there's a chance of existing code breaking > > How can removing top-level const from a return type "break" existing code any > more than adding a function overload? "Any more" is an interesting, but unrelated question. In general, both kinds of changes are able to introduce regressions in code size and cycles spent, and therefore should not be done carelessly. Compare #include const QVector constFoo(); int useConstFoo() { return constFoo()[0]; } _Z11useConstFoov: pushq %rbx subq $16, %rsp movq %rsp, %rdi call _Z8constFoov at PLT movq (%rsp), %rdi movq 16(%rdi), %rax movl (%rdi,%rax), %ebx movl (%rdi), %edx testl %edx, %edx je .L6 cmpl $-1, %edx je .L3 lock subl $1, (%rdi) je .L9 .L3: addq $16, %rsp movl %ebx, %eax popq %rbx ret .L9: movq (%rsp), %rdi .L6: movl $8, %edx movl $4, %esi call _ZN10QArrayData10deallocateEPS_mm at PLT addq $16, %rsp movl %ebx, %eax popq %rbx ret -- vs -- QVector nonConstFoo(); int useNonConstFoo() { return nonConstFoo()[0]; } _Z14useNonConstFoov: pushq %rbx subq $16, %rsp movq %rsp, %rdi call _Z11nonConstFoov at PLT movq (%rsp), %rax movl (%rax), %edx cmpl $1, %edx jbe .L31 movl 8(%rax), %edx andl $2147483647, %edx je .L32 movl 4(%rax), %esi xorl %ecx, %ecx movq %rsp, %rdi call _ZN7QVectorIiE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE at PLT movq (%rsp), %rdx .L23: movq 16(%rdx), %rax movl (%rdx,%rax), %ebx movl (%rdx), %ecx testl %ecx, %ecx je .L29 .L25: cmpl $-1, %ecx je .L26 lock subl $1, (%rdx) je .L29 .L26: addq $16, %rsp movl %ebx, %eax popq %rbx ret .L32: xorl %edx, %edx movl $2, %ecx movl $8, %esi movl $4, %edi call _ZN10QArrayData8allocateEmmm6QFlagsINS_16AllocationOptionEE at PLT movq %rax, %rdx movq %rax, (%rsp) movq 16(%rdx), %rax movl (%rdx,%rax), %ebx movl (%rdx), %ecx testl %ecx, %ecx jne .L25 .L29: movq (%rsp), %rdi movl $8, %edx movl $4, %esi call _ZN10QArrayData10deallocateEPS_mm at PLT addq $16, %rsp movl %ebx, %eax popq %rbx ret .L31: movq %rax, %rdx jmp .L23 I hope you agree that the version with removed top-level const is worse in this case. But again, the reason for refusing the QSplashScreen::pixmap() change was the ugliness of the code and the introduction of a compiler dependency. The patch does not even what it claims to do, namely to fix the supposed API problem in Qt 5. The proper solution here would have been to do the change for Qt 6. Neither the macro ugliness would be needed in this case nor would we have a compiler dependency. If you insist that such a change is allowed by QUIP-6 (and actually I agree that it is by the current wording) then QUIP-6 should be amended to disallow such undesirable changes. > Thanks, > Marc You are welcome, Andre' From marc.mutz at kdab.com Tue May 23 09:58:42 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 23 May 2017 09:58:42 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> References: <201705221204.10619.marc.mutz@kdab.com> <201705230726.39402.marc.mutz@kdab.com> <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> Message-ID: <201705230958.43203.marc.mutz@kdab.com> On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote: > But what I dislike is the fact that we get different signatures on > different platforms (because we can't change this on MSVC without breaking > BC). So... if MSVC mangles the return type, does that mean that we can _overload_ const QPixmap pixmap() const; QPixmap pixmap() const; ? The we can keep the old function in the DLL, but new code only sees the new signature. BTW: https://codereview.qt-project.org/164690 BTW2: Please free this discussion from the fact that the change is on QSplashScreen. We're talking about removing TLC from return types, and that would also disallow the QStringBuilder change and https://codereview.qt- project.org/93161, too, which clearly have had a higher (positive) impact than the QSplashScreen change. But allowing the change for QRegion and QStringBuilder, but not for QSplashScreen is the worst-possible outcome, as it would not help direct such decisions in the future. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Tue May 23 10:39:46 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 23 May 2017 10:39:46 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> References: <201705221204.10619.marc.mutz@kdab.com> <201705230726.39402.marc.mutz@kdab.com> <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> Message-ID: <201705231039.47140.marc.mutz@kdab.com> On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote: > (a detach happening on Linux, but not on MSVC) Don't fall for FUD. QPixmap does not have functions that are overloaded on const/non-const. Neither does QRegion. Well, except for the special member functions, which is the whole point of the exercise. And for QStringBuilder, the change enabled calling the rvalue overload of toXyz() functions in the first place, which re- use storage, saving an allocation. To summarize: there is no negative impact of any of these changes. And if MSVC does something stupid, it deserves to continue to be pessimised. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Tue May 23 10:44:11 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 23 May 2017 11:44:11 +0300 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <201705231039.47140.marc.mutz@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> <201705230726.39402.marc.mutz@kdab.com> <9B4775B6-C9BF-42FA-8EDE-CA4BE200F9CA@qt.io> <201705231039.47140.marc.mutz@kdab.com> Message-ID: On 23 May 2017 at 11:39, Marc Mutz wrote: > On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote: >> (a detach happening on Linux, but not on MSVC) > > Don't fall for FUD. > > QPixmap does not have functions that are overloaded on const/non-const. > Neither does QRegion. Well, except for the special member functions, which is > the whole point of the exercise. And for QStringBuilder, the change enabled > calling the rvalue overload of toXyz() functions in the first place, which re- > use storage, saving an allocation. > > To summarize: there is no negative impact of any of these changes. And if MSVC > does something stupid, it deserves to continue to be pessimised. Maybe, but I have some questions: the review for removing top-level consts from QRegion says "It has no effect and inhibits move semantics." How does it inhibit move semantics? How is this even a SiC? What _positive_ impact do these changes have? From marc.mutz at kdab.com Tue May 23 11:00:19 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 23 May 2017 11:00:19 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: References: <201705221204.10619.marc.mutz@kdab.com> <201705231039.47140.marc.mutz@kdab.com> Message-ID: <201705231100.19683.marc.mutz@kdab.com> On Tuesday 23 May 2017 10:44:11 Ville Voutilainen wrote: > On 23 May 2017 at 11:39, Marc Mutz wrote: > > On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote: > >> (a detach happening on Linux, but not on MSVC) > > > > Don't fall for FUD. > > > > QPixmap does not have functions that are overloaded on const/non-const. > > Neither does QRegion. Well, except for the special member functions, > > which is the whole point of the exercise. And for QStringBuilder, the > > change enabled calling the rvalue overload of toXyz() functions in the > > first place, which re- use storage, saving an allocation. > > > > To summarize: there is no negative impact of any of these changes. And if > > MSVC does something stupid, it deserves to continue to be pessimised. > > Maybe, but I have some questions: the review for removing top-level consts > from QRegion says "It has no effect and inhibits move semantics." How does > it inhibit move semantics? How is this even a SiC? What _positive_ impact > do these changes have? See Olivier's example: QPixmap pix; pix = splash.pixmap(); with const QPixmap pixmap() const; calls the copy assignment operator, while with QPixmap pixmap() const; it calls, as expected, the _move_ assignment operator. Similarly, in the QStringBuilder case, when const QString resolved() const; then (string % builder % expression).toUpper() calls QString QString::toUpper() const & which always allocates a new buffer, while with QString resolved() const; it calls QString QString::toUpper() && which in many cases can re-use the buffer allocated for *this to store the result and leave *this empty. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Tue May 23 11:06:14 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 23 May 2017 11:06:14 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: References: <201705221204.10619.marc.mutz@kdab.com> <201705231039.47140.marc.mutz@kdab.com> Message-ID: <201705231106.14668.marc.mutz@kdab.com> On Tuesday 23 May 2017 10:44:11 Ville Voutilainen wrote: > How is this even a SiC? Just as you can detect whether a function is overloaded (taking the address without cast fails), you can detect the const on the return value. Andre shows the difference for QVector. A user could write something like: const QVector foo(); for (auto e : foo()) // foo() returns const, no need to prevent detaching .... and with dropping the const, it would suddenly detach. Of course, if you receive a CoWed container, you should not rely on a const return type, but enforce const on the call site: const auto foos = foo(); for (auto e: foos) .... This is what makes it a QUIP-6 Cat-A SiC: the latter works with both Qt versions, and, arguably, is what should have been written from the get-go. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Tue May 23 11:17:32 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 23 May 2017 12:17:32 +0300 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <201705231100.19683.marc.mutz@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> <201705231039.47140.marc.mutz@kdab.com> <201705231100.19683.marc.mutz@kdab.com> Message-ID: On 23 May 2017 at 12:00, Marc Mutz wrote: >> Maybe, but I have some questions: the review for removing top-level consts >> from QRegion says "It has no effect and inhibits move semantics." How does >> it inhibit move semantics? How is this even a SiC? What _positive_ impact >> do these changes have? > > See Olivier's example: > > QPixmap pix; > pix = splash.pixmap(); > > with > > const QPixmap pixmap() const; > > calls the copy assignment operator, while with > > QPixmap pixmap() const; > > it calls, as expected, the _move_ assignment operator. Ok, yeah, I was using constructors, not assignment operators so I failed to see the issue. So, we are doing this to improve performance of otherwise valid code, but not making this change doesn't make anything worse, right? From olivier at woboq.com Tue May 23 13:08:43 2017 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 23 May 2017 13:08:43 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: References: <201705221204.10619.marc.mutz@kdab.com> <201705231100.19683.marc.mutz@kdab.com> Message-ID: <4907129.vHgH5r6pyu@maurice> Am Dienstag, 23. Mai 2017, 11:17:32 CEST schrieb Ville Voutilainen: > On 23 May 2017 at 12:00, Marc Mutz wrote: > >> Maybe, but I have some questions: the review for removing top-level > >> consts > >> from QRegion says "It has no effect and inhibits move semantics." How > >> does > >> it inhibit move semantics? How is this even a SiC? What _positive_ impact > >> do these changes have? > > > > See Olivier's example: > > QPixmap pix; > > pix = splash.pixmap(); > > > > with > > > > const QPixmap pixmap() const; > > > > calls the copy assignment operator, while with > > > > QPixmap pixmap() const; > > > > it calls, as expected, the _move_ assignment operator. > > Ok, yeah, I was using constructors, not assignment operators so I > failed to see the > issue. > > So, we are doing this to improve performance of otherwise valid code, > but not making this > change doesn't make anything worse, right? Someone could have written: const QPixmap (QSplashScreen::*hello)() = &QSlpashScreen::pixmap; or static_assert(std::is_constpixmap())>::value); But that's unlikely and just a theoretical construct. I'd say that the risk that this change breaks anything is less than for most of the other changes we do to the API, including adding functions to classes. From olivier at woboq.com Tue May 23 13:56:52 2017 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 23 May 2017 13:56:52 +0200 Subject: [Development] QList In-Reply-To: References: <5004229.iNTmZlkdfe@tjmaciei-mobl1> Message-ID: <2113093.zhT74SXtvi@maurice> Am Donnerstag, 18. Mai 2017, 10:58:23 CEST schrieb Ville Voutilainen: > [...] the QUIP is here for review: > https://codereview.qt-project.org/#/c/194984/ Thanks, (Sorry for not replying to the QUIP, but discussions on gerrit are not so easy to follow) Here are what what are the characteristics of QList: a. Amortized O(1) append b. Amortized O(1) prepend c. Relatively fast insert even if elements are expensive to copy/move d. Implicitly shared (copy-on-write) e. Should expand to less binary code than QVector or other container because most operation are done in qlist.cpp, common for very type. (I don't think this was mentioned before) f. The pointers to elements are kept valid on append/prepend/insert if the list is not shared (detach) and the type is big enough. g. It is inefficient because of the many allocations and bad cache behaviour. In Qt 4.0, QList was made the default container for most purposes because of the points a,b,c,d,e which where believed to be good characteristics for a default sequence containers. I don't think f was an intended characteristic. (Actually, I believe that people who rely on it just rely on an accidental implementation detail / undefined behavior.) And g was somehow ignored for some reason, or maybe it was tough that c was more important for the default container. The question is what to do in Qt 5.x and in Qt 6? QList being used everywhere means people might rely on any of these point. It was suggested to simply replace making QList being an alias to QVector in Qt6. But we'd loose characteristics b,c,e,f. We could get b. back if we make it possible for QVector to reserve memory in front on prepend. We could ignore c. as this might be less of a problem with move semantic nowadays. We could also ignore e. But not having f. might introduce nasty bugs that might not be seen easily in big project while porting. So Marc suggested adding a QArrayList alias to annotate code today that we know are relying on f. as a porting aide. I think QArrayList does not solve the problem because I'd say most people will not use it, they might not even know they rely on it. Their code works now, and if we replace QList by QVector it will introduce subtle bugs anyway. Another solution could be to keep QList as it, but deprecate it, and use QVector everywhere in the API. We'd need to introduce implicit conversion between QList and QVector to reduce the amount of source incompatibilities. An alternative could be to develop a new data structure that keep the good part of QList, while keeping good cache behavior. Maybe something modeled around std::deque. In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) in QVector. And change the API to use QVector everywhere, with QList being a deprecated alias to it. Ignore the fact that people can keep pointers to the items. (Small behavior change that should not impact many usages.) (For functions that do not take ownership of the vector, I'd make a new a QArrayView.) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Tue May 23 16:17:46 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 May 2017 07:17:46 -0700 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <201705230726.39402.marc.mutz@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> <3249143.KQHYzqoKaS@tjmaciei-mobl1> <201705230726.39402.marc.mutz@kdab.com> Message-ID: <2567172.CjyHbfLQxV@tjmaciei-mobl1> On Monday, 22 May 2017 22:26:38 PDT Marc Mutz wrote: > > if there's a chance of existing code breaking > > How can removing top-level const from a return type "break" existing code > any more than adding a function overload? I thought we were discussing Source Incompatible Changes. If it doesn't break anything, it isn't SIC. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 23 16:27:46 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 May 2017 07:27:46 -0700 Subject: [Development] QList In-Reply-To: <2113093.zhT74SXtvi@maurice> References: <2113093.zhT74SXtvi@maurice> Message-ID: <1706186.7l5m6VU2rZ@tjmaciei-mobl1> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote: > In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) in > QVector. That is not very difficult once we move the begin pointer out of the d pointer and into the main QVector class. We need to add an interface to QArrayData to shrink and expand the buffer without relocating it. With that, we practically hide the allocated capacity information from QVector too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue May 23 20:22:46 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 23 May 2017 20:22:46 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <2567172.CjyHbfLQxV@tjmaciei-mobl1> References: <201705221204.10619.marc.mutz@kdab.com> <3249143.KQHYzqoKaS@tjmaciei-mobl1> <201705230726.39402.marc.mutz@kdab.com> <2567172.CjyHbfLQxV@tjmaciei-mobl1> Message-ID: <8014754e2870cee7c8b8bccb31211d25@kdab.com> On 2017-05-23 16:17, Thiago Macieira wrote: > On Monday, 22 May 2017 22:26:38 PDT Marc Mutz wrote: >> > if there's a chance of existing code breaking >> >> How can removing top-level const from a return type "break" existing >> code >> any more than adding a function overload? > > I thought we were discussing Source Incompatible Changes. If it doesn't > break > anything, it isn't SIC. So you still didn't read the QUIP? https://quips-qt-io.herokuapp.com/quip-0006.html (warning: outdated, which means I have no clue where the current one is supposed to be, except in Git). Every change can break existing code. One bug-fix breaks the work-around, the other fixes behaviour that people unrightfully depended on (see https://bugreports.qt.io/browse/QTBUG-60914 as the latest example). Adding a function overload breaks taking the function's address. Adding a function template overloading a function breaks it in such a way as to make it impossible (afaics) to take the address of the non-template function (QTimer::setInterval vs. qOverload issue). Removing an unnecessary #include breaks TUs that incorrectly depended on this indirect include. And removing the const of a return value breaks code that tries to store the function into a pointer-to-function with the old signature. So they are all SiC. The point is that these are all qualitatively different from, say, incompatibly changing (or removing) an inline, non-exported, public function, which is BC, but SiC. This division into the two qualities of SiCs (acceptable and not) is what QUIP-6 is all about. These are acceptable because they affect only more-or-less broken code. And since they are acceptable, we ought to be able to perform them freely, without a discussion every time. We don't discuss adding function overloads. We weren't even aware that there's an issue. We used to discuss removing unneeded #includes or adding explicit to ctors, both of which used to be effectively banned, until the discussion leading to QUIP-6 culminated in the decision that these are acceptable. Unfortunately, this thread slowly eats away all the productivity gain we have enjoyed due to reduced debates since then. Thanks, Marc From thiago.macieira at intel.com Tue May 23 23:56:15 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 May 2017 14:56:15 -0700 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <8014754e2870cee7c8b8bccb31211d25@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> <2567172.CjyHbfLQxV@tjmaciei-mobl1> <8014754e2870cee7c8b8bccb31211d25@kdab.com> Message-ID: <2875487.pWGtXr2rgi@tjmaciei-mobl1> On Tuesday, 23 May 2017 11:22:46 PDT Marc Mutz wrote: > These are acceptable because they affect only more-or-less broken code. > And since they are acceptable, we ought to be able to perform them > freely, without a discussion every time. We don't discuss adding > function overloads. We weren't even aware that there's an issue. We used > to discuss removing unneeded #includes or adding explicit to ctors, both > of which used to be effectively banned, until the discussion leading to > QUIP-6 culminated in the decision that these are acceptable. > Unfortunately, this thread slowly eats away all the productivity gain we > have enjoyed due to reduced debates since then. Ok, I got it: we're not arguing the compatibility issue. We are arguing whether the change makes the code uglier and is worth that ugliness. I'm not sold on that. Leave those const behind until Qt 6, unless you can show that engaging the move constructor is important. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dangelog at gmail.com Wed May 24 00:35:50 2017 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 24 May 2017 00:35:50 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <2875487.pWGtXr2rgi@tjmaciei-mobl1> References: <201705221204.10619.marc.mutz@kdab.com> <2567172.CjyHbfLQxV@tjmaciei-mobl1> <8014754e2870cee7c8b8bccb31211d25@kdab.com> <2875487.pWGtXr2rgi@tjmaciei-mobl1> Message-ID: On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira wrote: > > We are arguing whether the change makes the code uglier and is worth that > ugliness. I'm not sold on that. Leave those const behind until Qt 6, unless > you can show that engaging the move constructor is important. What about defining a (private) macro centrally and using it in those places, as it has been proposed? -- Giuseppe D'Angelo From lars.knoll at qt.io Wed May 24 11:04:36 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 24 May 2017 09:04:36 +0000 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: References: <201705221204.10619.marc.mutz@kdab.com> <2567172.CjyHbfLQxV@tjmaciei-mobl1> <8014754e2870cee7c8b8bccb31211d25@kdab.com> <2875487.pWGtXr2rgi@tjmaciei-mobl1> Message-ID: <4436B1A2-CFB9-4972-B427-73447A7A0D73@qt.io> > On 24 May 2017, at 00:35, Giuseppe D'Angelo wrote: > > On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira > wrote: >> >> We are arguing whether the change makes the code uglier and is worth that >> ugliness. I'm not sold on that. Leave those const behind until Qt 6, unless >> you can show that engaging the move constructor is important. > > What about defining a (private) macro centrally and using it in those > places, as it has been proposed? +1 on that. It avoids the uglyness of having a complicated #ifdef that we'd probably have in multiple places. It'll also ensure we can do the changes now and the we won't forget to fix it when we move over to Qt 6. Cheers, Lars From jani.heikkinen at qt.io Wed May 24 12:48:15 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 24 May 2017 10:48:15 +0000 Subject: [Development] Qt 5.9.0 RC released Message-ID: Hi all, Qt 5.9.0 RC is now available. Diff to beta4 can be found as an attachment. You can update RC at the top of existing online installation by using maintenance tool or do clean installation. Instructions how to get the release via online installer are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. At this time there is also offline installers available, see http://download.qt.io/development_releases/qt/5.9/5.9.0-rc/ Please test the release as soon as possible and report your effort via https://wiki.qt.io/Qt59_release_testing. We are planning to release Qt 5.9.0 final Wed 31.5.2017. br, Jani Heikkinen Release Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.9.0-beta4-delta-rc Type: application/octet-stream Size: 11466 bytes Desc: qt5.9.0-beta4-delta-rc URL: From announce at qt-project.org Wed May 24 12:48:58 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 24 May 2017 10:48:58 +0000 Subject: [Development] [Announce] Qt 5.9.0 RC released Message-ID: Hi all, We have released Qt 5.9.0 RC today. You can update it at the top of your Qt 5.9 beta(4) online installation or do clean installation by using qt online installer. Detailed instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer . Qt 5.9.0 RC is also available as offline installers which you can download from your qt account or from https://info.qt.io/download-qt-for-application-development br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From announce at qt-project.org Wed May 24 13:07:53 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 24 May 2017 11:07:53 +0000 Subject: [Development] [Announce] Qt Creator 4.3.0 released Message-ID: We are happy to announce the release of Qt Creator 4.3.0! https://blog.qt.io/blog/2017/05/24/qt-creator-4-3-0-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From enmarantispam at gmail.com Wed May 24 14:48:48 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 24 May 2017 15:48:48 +0300 Subject: [Development] QList In-Reply-To: <1706186.7l5m6VU2rZ@tjmaciei-mobl1> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> Message-ID: A semi-sane idea that I think no one has suggested yet: What if, starting from Qt6, QList becomes a wrapper for QArrayList with a contructor from this type? After all making existing code slightly _slower_ because of the wrapping overhead is way less problematic than breaking it outright. It will nudge the users of QLists that need to be fast to switch but will leave users of "default no brainer container" happy as they likely wouldn't even notice. On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira wrote: > On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote: > > In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) > in > > QVector. > > That is not very difficult once we move the begin pointer out of the d > pointer > and into the main QVector class. We need to add an interface to QArrayData > to > shrink and expand the buffer without relocating it. With that, we > practically > hide the allocated capacity information from QVector too. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed May 24 15:12:00 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 24 May 2017 16:12:00 +0300 Subject: [Development] QList In-Reply-To: References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> Message-ID: <3798391495631520@web25o.yandex.ru> 24.05.2017, 15:49, "NIkolai Marchenko" : > A semi-sane idea that I think no one has suggested yet: > > What if, starting from Qt6, QList becomes a wrapper for QArrayList with a contructor from this type? > After all making existing code slightly _slower_ because of the wrapping overhead is way less problematic than breaking it outright. > It will nudge the users of QLists that need to be fast to switch but will leave users of "default no brainer container" happy as they likely wouldn't even notice. If existing Qt APIs switch from QList to QVector in Qt 6, such change will make it hard to support both Qt 5 and Qt 6 in the same code base. > > On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira wrote: >> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote: >>> In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) in >>> QVector. >> >> That is not very difficult once we move the begin pointer out of the d pointer >> and into the main QVector class. We need to add an interface to QArrayData to >> shrink and expand the buffer without relocating it. With that, we practically >> hide the allocated capacity information from QVector too. >> >> -- >> 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 --  Regards, Konstantin From enmarantispam at gmail.com Wed May 24 15:18:52 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 24 May 2017 16:18:52 +0300 Subject: [Development] QList In-Reply-To: <3798391495631520@web25o.yandex.ru> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> Message-ID: I was talking about the solution that assumes making a QArrayList type and deprecating QList entirely, not the one that aliases QList to QVector which I, personally, don't like, since it will produce a lot of the code perception problems and incorrect perfomance assumptions. Not to mention people will still widely use QList as it's "easier to type "(don't laugh) and "looks like a default container by simplicity of its name" (again, don't laugh, I am just outlining potential problems with new users) On Wed, May 24, 2017 at 4:12 PM, Konstantin Tokarev wrote: > > > 24.05.2017, 15:49, "NIkolai Marchenko" : > > A semi-sane idea that I think no one has suggested yet: > > > > What if, starting from Qt6, QList becomes a wrapper for QArrayList with > a contructor from this type? > > After all making existing code slightly _slower_ because of the wrapping > overhead is way less problematic than breaking it outright. > > It will nudge the users of QLists that need to be fast to switch but > will leave users of "default no brainer container" happy as they likely > wouldn't even notice. > > If existing Qt APIs switch from QList to QVector in Qt 6, such change will > make it hard to support both Qt 5 and Qt 6 in the same code base. > > > > > On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira < > thiago.macieira at intel.com> wrote: > >> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote: > >>> In my opinion for Qt6, we should make prepend, takeFirst amortized > O(1) in > >>> QVector. > >> > >> That is not very difficult once we move the begin pointer out of the d > pointer > >> and into the main QVector class. We need to add an interface to > QArrayData to > >> shrink and expand the buffer without relocating it. With that, we > practically > >> hide the allocated capacity information from QVector too. > >> > >> -- > >> 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 > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed May 24 15:24:48 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 24 May 2017 16:24:48 +0300 Subject: [Development] QList In-Reply-To: References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> Message-ID: <3867481495632288@web25o.yandex.ru> 24.05.2017, 16:19, "NIkolai Marchenko" : > I was talking about the solution that assumes making a QArrayList type and deprecating QList entirely, > not the one that aliases QList to QVector which I, personally, don't like, since it will produce a lot of the code perception problems and incorrect perfomance assumptions. So, do you propose to replace QList with QArrayList in existing APIs? That would be a serious pessimization for small types. > Not to mention people will still widely use QList as it's "easier to type "(don't laugh) and "looks like a default container by simplicity of its name" > (again, don't laugh, I am just outlining potential problems with new users) > > On Wed, May 24, 2017 at 4:12 PM, Konstantin Tokarev wrote: > >> 24.05.2017, 15:49, "NIkolai Marchenko" : >>> A semi-sane idea that I think no one has suggested yet: >>> >>> What if, starting from Qt6, QList becomes a wrapper for QArrayList with a contructor from this type? >>> After all making existing code slightly _slower_ because of the wrapping overhead is way less problematic than breaking it outright. >>> It will nudge the users of QLists that need to be fast to switch but will leave users of "default no brainer container" happy as they likely wouldn't even notice. >> >> If existing Qt APIs switch from QList to QVector in Qt 6, such change will make it hard to support both Qt 5 and Qt 6 in the same code base. >> >>> >>> On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira wrote: >>>> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote: >>>>> In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) in >>>>> QVector. >>>> >>>> That is not very difficult once we move the begin pointer out of the d pointer >>>> and into the main QVector class. We need to add an interface to QArrayData to >>>> shrink and expand the buffer without relocating it. With that, we practically >>>> hide the allocated capacity information from QVector too. >>>> >>>> -- >>>> 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 >> >> -- >> Regards, >> Konstantin --  Regards, Konstantin From enmarantispam at gmail.com Wed May 24 15:36:51 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 24 May 2017 16:36:51 +0300 Subject: [Development] QList In-Reply-To: <3867481495632288@web25o.yandex.ru> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> <3867481495632288@web25o.yandex.ru> Message-ID: Not necessarily. It really depends on which type Qt decides to use in place of what is now returned as a QList. As far as wrapper is concerned, it doesn't even need to be a singlular type if the interface matches since it will be a template anyway. P.S. I am not really involved with Qt development so I am obviously missing a lot of context. I just saw that this wasn't even mentioned throughout this thread or the previous one and finally decided to comment. I just, personally, see the problems I already mentioned above about incorrect code perception significant enough that QVector solution feels wrong. Users will see, for example, codebases with "QList.something.prepend" and assume things. Completely incorrect things. And debugging older codebases is already hard as it is, even when things actually mean what you assume they do. The current solution that seems to be heading to Qt6 (qvector alias) will, imho, in the long run, produce a lot of confusion. Not when switching from 5 to 6, but when trying to debug/finetune the code. On Wed, May 24, 2017 at 4:24 PM, Konstantin Tokarev wrote: > > > 24.05.2017, 16:19, "NIkolai Marchenko" : > > I was talking about the solution that assumes making a QArrayList type > and deprecating QList entirely, > > not the one that aliases QList to QVector which I, personally, don't > like, since it will produce a lot of the code perception problems and > incorrect perfomance assumptions. > > So, do you propose to replace QList with QArrayList in existing APIs? That > would be a serious pessimization for small types. > > > Not to mention people will still widely use QList as it's "easier to > type "(don't laugh) and "looks like a default container by simplicity of > its name" > > (again, don't laugh, I am just outlining potential problems with new > users) > > > > On Wed, May 24, 2017 at 4:12 PM, Konstantin Tokarev > wrote: > > > >> 24.05.2017, 15:49, "NIkolai Marchenko" : > >>> A semi-sane idea that I think no one has suggested yet: > >>> > >>> What if, starting from Qt6, QList becomes a wrapper for QArrayList > with a contructor from this type? > >>> After all making existing code slightly _slower_ because of the > wrapping overhead is way less problematic than breaking it outright. > >>> It will nudge the users of QLists that need to be fast to switch but > will leave users of "default no brainer container" happy as they likely > wouldn't even notice. > >> > >> If existing Qt APIs switch from QList to QVector in Qt 6, such change > will make it hard to support both Qt 5 and Qt 6 in the same code base. > >> > >>> > >>> On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira < > thiago.macieira at intel.com> wrote: > >>>> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote: > >>>>> In my opinion for Qt6, we should make prepend, takeFirst amortized > O(1) in > >>>>> QVector. > >>>> > >>>> That is not very difficult once we move the begin pointer out of the > d pointer > >>>> and into the main QVector class. We need to add an interface to > QArrayData to > >>>> shrink and expand the buffer without relocating it. With that, we > practically > >>>> hide the allocated capacity information from QVector too. > >>>> > >>>> -- > >>>> 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 > >> > >> -- > >> Regards, > >> Konstantin > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Thu May 18 08:39:24 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 18 May 2017 06:39:24 +0000 Subject: [Development] CI is down again Message-ID: We seem to have hardware issues which are under investigation. We'll be back online as soon as possible. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed May 24 18:39:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 May 2017 09:39:16 -0700 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: References: <201705221204.10619.marc.mutz@kdab.com> <2875487.pWGtXr2rgi@tjmaciei-mobl1> Message-ID: <36532765.XhcXLxH236@tjmaciei-mobl1> On Tuesday, 23 May 2017 15:35:50 PDT Giuseppe D'Angelo wrote: > On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira > > wrote: > > We are arguing whether the change makes the code uglier and is worth that > > ugliness. I'm not sold on that. Leave those const behind until Qt 6, > > unless > > you can show that engaging the move constructor is important. > > What about defining a (private) macro centrally and using it in those > places, as it has been proposed? Still ugly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed May 24 18:40:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 May 2017 09:40:44 -0700 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <4436B1A2-CFB9-4972-B427-73447A7A0D73@qt.io> References: <201705221204.10619.marc.mutz@kdab.com> <4436B1A2-CFB9-4972-B427-73447A7A0D73@qt.io> Message-ID: <6472718.3nKgE6I39F@tjmaciei-mobl1> On Wednesday, 24 May 2017 02:04:36 PDT Lars Knoll wrote: > > On 24 May 2017, at 00:35, Giuseppe D'Angelo wrote: > > > > On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira > > > > wrote: > >> We are arguing whether the change makes the code uglier and is worth that > >> ugliness. I'm not sold on that. Leave those const behind until Qt 6, > >> unless > >> you can show that engaging the move constructor is important. > > > > What about defining a (private) macro centrally and using it in those > > places, as it has been proposed? > > +1 on that. It avoids the uglyness of having a complicated #ifdef that we'd > probably have in multiple places. It'll also ensure we can do the changes > now and the we won't forget to fix it when we move over to Qt 6. "We won't forget when we move to Qt 6" is not an argument. Just add the necessary ### Qt6 macro and we won't forget. The ### Qt5 that remained in Qt5 weren't because we forgot. It's because they were too difficult to apply or broke too much when applied. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed May 24 21:09:41 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 24 May 2017 21:09:41 +0200 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <6472718.3nKgE6I39F@tjmaciei-mobl1> References: <201705221204.10619.marc.mutz@kdab.com> <4436B1A2-CFB9-4972-B427-73447A7A0D73@qt.io> <6472718.3nKgE6I39F@tjmaciei-mobl1> Message-ID: <337797dc05576c82ab91ac6c5664e9c3@kdab.com> On 2017-05-24 18:40, Thiago Macieira wrote: > On Wednesday, 24 May 2017 02:04:36 PDT Lars Knoll wrote: >> > On 24 May 2017, at 00:35, Giuseppe D'Angelo wrote: >> > >> > On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira >> > >> > wrote: >> >> We are arguing whether the change makes the code uglier and is worth that >> >> ugliness. I'm not sold on that. Leave those const behind until Qt 6, >> >> unless >> >> you can show that engaging the move constructor is important. >> > >> > What about defining a (private) macro centrally and using it in those >> > places, as it has been proposed? >> >> +1 on that. It avoids the uglyness of having a complicated #ifdef that >> we'd >> probably have in multiple places. It'll also ensure we can do the >> changes >> now and the we won't forget to fix it when we move over to Qt 6. > > "We won't forget when we move to Qt 6" is not an argument. Just add the > necessary ### Qt6 macro and we won't forget. > > The ### Qt5 that remained in Qt5 weren't because we forgot. It's > because they > were too difficult to apply or broke too much when applied. I maintain that they were forgotten. Well, or ignored. From a quick grep in QtBase, two that caught my eye: - qvector.h: The solution is obvious, straight-forward, and BiC: unexport QPolygon(F). Wasn't done. Wouldn't've broken anything. - qregexp.cpp: They're also about removing const: from member functions, this time. Code breaks, but is trivial to fix. If we don't even remember to do _that_ kind of trivial change, how can we, with a straight face, claim that we will handle all the ### Qt 6 ones? There are already 236 "### Qt 6" instances today, in QtBase alone. They all need to be looked at, understood, maybe re-evaluated, and implemented. The ones protected with QT_VERSION checks, otoh, will become active the day Ossi flips the switch and calls dev 6.0.0. Thanks, Marc From marc.mutz at kdab.com Wed May 24 21:25:43 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 24 May 2017 21:25:43 +0200 Subject: [Development] QList In-Reply-To: <3798391495631520@web25o.yandex.ru> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> Message-ID: On 2017-05-24 15:12, Konstantin Tokarev wrote: > 24.05.2017, 15:49, "NIkolai Marchenko" : >> A semi-sane idea that I think no one has suggested yet: >> >> What if, starting from Qt6, QList becomes a wrapper for QArrayList >> with a contructor from this type? >> After all making existing code slightly _slower_ because of the >> wrapping overhead is way less problematic than breaking it outright. >> It will nudge the users of QLists that need to be fast to switch but >> will leave users of "default no brainer container" happy as they >> likely wouldn't even notice. > > If existing Qt APIs switch from QList to QVector in Qt 6, such change > will make it hard to support both Qt 5 and Qt 6 in the same code base. Which is why I suggested to make QList a type alias for QVector or QArrayList, depending on some yet-to-be-determined criteria. Obvious candidates algorithms are: 1. the one that QList currently uses. This means that no QList user will see his own code break (except when he depends on the padding present in today's QList when T is smaller than void*), but will either need to port when interfacing with Qt API that moved to QVector or incur the deep copy when QVector and QList are implicitly converted to each other (an operation that should be added and immediately deprecated). 2. historic QList use. When a type T was customarily held in QList in Qt 5, QList maps to the container that is now used in Qt 6, regardless of what (1) would have yielded. If T was not customarily held in QVector, which includes the case that T is not a Qt library type, it uses the algorithm from (1) to minimize breakages. Under (1) QList would map to QArrayList, because Q5List uses indirect memory layout (QVariant is too large), while Qt 6 APIs will almost certainly use QVector for holding QVariants. Under (2) we'd therefore map QList to QVector, because that's what allows clients to continue to use QList for the same API in both Qt 5 and 6. I'm tending towards (2) these days. Thanks, Marc From thiago.macieira at intel.com Wed May 24 23:49:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 May 2017 14:49:06 -0700 Subject: [Development] QUIP 6: removing top-level const from return types In-Reply-To: <337797dc05576c82ab91ac6c5664e9c3@kdab.com> References: <201705221204.10619.marc.mutz@kdab.com> <6472718.3nKgE6I39F@tjmaciei-mobl1> <337797dc05576c82ab91ac6c5664e9c3@kdab.com> Message-ID: <5512267.WIFir0Rdhn@tjmaciei-mobl1> On Wednesday, 24 May 2017 12:09:41 PDT Marc Mutz wrote: > I maintain that they were forgotten. Well, or ignored. > > From a quick grep in QtBase, two that caught my eye: > > - qvector.h: The solution is obvious, straight-forward, and BiC: > unexport QPolygon(F). Wasn't done. Wouldn't've broken anything. That would imply exporting each of the out-of-line functions. That idea never occurred to us back then (and I still dislike because it uglifies the headers, but it's a reasonable solution for QPolygon(F)). Without this possibility in our pockets, the solution was incredibly hard and therefore matches my criteria. > - qregexp.cpp: They're also about removing const: from member > functions, this time. Code breaks, but is trivial to fix. We were expecting to remove the entirety of QRegExp, so no one bothered because it would have been a wasted effort. Also, they WERE removed. And then brought back in a git revert. See babd3e252b87a3b9c91cd44189d4fcb5cd8ab270. So this again qualifies as "not easy". > If we don't even remember to do _that_ kind of trivial change, how can > we, with a straight face, claim that we will handle all the ### Qt 6 > ones? Let's try again. Find me trivial ### Qt5 that we left over. > There are already 236 "### Qt 6" instances today, in QtBase alone. > They all need to be looked at, understood, maybe re-evaluated, and > implemented. The ones protected with QT_VERSION checks, otoh, will > become active the day Ossi flips the switch and calls dev 6.0.0. And we'll find issues like the qregexp one that don't work or break too much because no one tested them, but unlike a steady change where we can detect what change caused the breakage, we'll get them all at once and we'll have to spend time investigating. I'm not saying we shouldn't use the QT_VERSION_CHECK trick, but we should use it judiciously. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Thu May 25 01:19:38 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 25 May 2017 02:19:38 +0300 Subject: [Development] QList In-Reply-To: References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> Message-ID: On 24 May 2017 at 22:25, Marc Mutz wrote: > On 2017-05-24 15:12, Konstantin Tokarev wrote: >> >> 24.05.2017, 15:49, "NIkolai Marchenko" : >>> >>> A semi-sane idea that I think no one has suggested yet: >>> >>> What if, starting from Qt6, QList becomes a wrapper for QArrayList with a >>> contructor from this type? >>> After all making existing code slightly _slower_ because of the wrapping >>> overhead is way less problematic than breaking it outright. >>> It will nudge the users of QLists that need to be fast to switch but will >>> leave users of "default no brainer container" happy as they likely wouldn't >>> even notice. >> >> >> If existing Qt APIs switch from QList to QVector in Qt 6, such change >> will make it hard to support both Qt 5 and Qt 6 in the same code base. > > > Which is why I suggested to make QList a type alias for QVector or > QArrayList, depending on some yet-to-be-determined criteria. Obvious > candidates algorithms are: I think we need to take a serious step backwards here. I, for various reasons, got the impression that a major problem at hand is that when a user (NOT in any template code, necessarily) uses QList, that user doesn't know the consequences. Mostly because depending on the characteristics of Foo, the user doesn't know what the performance characteristics and semantics of QList are, because QList might or might not use (in)direct storage. Perhaps I completely fail to understand the problem space. I (think I) have read Marc's writings on the subject matter, but chances are that the crux of the matter is still escaping me. How does it help anyone to create a new alias that still results in a concrete type the semantics of which still depend on the element type? From marc.mutz at kdab.com Thu May 25 06:38:32 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 25 May 2017 06:38:32 +0200 Subject: [Development] QList In-Reply-To: References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> Message-ID: On 2017-05-25 01:19, Ville Voutilainen wrote: [...] > How does it help anyone to create a new alias that still results in a > concrete type > the semantics of which still depend on the element type? The QList type alias in Qt 6 would be deprecated from the get-go. As would be the QArrayList/QVector implicit conversions. They're purely vehicles to keep old source working. Thanks, Marc From annulen at yandex.ru Thu May 25 12:38:37 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 25 May 2017 13:38:37 +0300 Subject: [Development] QList In-Reply-To: References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> Message-ID: <813191495708717@web19j.yandex.ru> 25.05.2017, 02:19, "Ville Voutilainen" : > On 24 May 2017 at 22:25, Marc Mutz wrote: >>  On 2017-05-24 15:12, Konstantin Tokarev wrote: >>>  24.05.2017, 15:49, "NIkolai Marchenko" : >>>>  A semi-sane idea that I think no one has suggested yet: >>>> >>>>  What if, starting from Qt6, QList becomes a wrapper for QArrayList with a >>>>  contructor from this type? >>>>  After all making existing code slightly _slower_ because of the wrapping >>>>  overhead is way less problematic than breaking it outright. >>>>  It will nudge the users of QLists that need to be fast to switch but will >>>>  leave users of "default no brainer container" happy as they likely wouldn't >>>>  even notice. >>> >>>  If existing Qt APIs switch from QList to QVector in Qt 6, such change >>>  will make it hard to support both Qt 5 and Qt 6 in the same code base. >> >>  Which is why I suggested to make QList a type alias for QVector or >>  QArrayList, depending on some yet-to-be-determined criteria. Obvious >>  candidates algorithms are: > > I think we need to take a serious step backwards here. I, for various reasons, > got the impression that a major problem at hand is that when a user (NOT in any > template code, necessarily) uses QList, that user doesn't know the > consequences. Other problem, that IMO is more serious, is that Qt *requires* user to use QList, by returning or taking it as and argument in various places. That's almost only reason why I use QList in my code[*]. If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with this APIs will break, unless QList will become an alias of QVector. [*] And, fwiw, almost only reason I use QString, but that's off-topic here > Mostly because depending on the characteristics of Foo, > the user doesn't know what the performance characteristics and semantics > of QList are, because QList might or might not use (in)direct storage. > > Perhaps I completely fail to understand the problem space. I (think I) > have read Marc's writings > on the subject matter, but chances are that the crux of the matter is > still escaping me. > How does it help anyone to create a new alias that still results in a > concrete type > the semantics of which still depend on the element type? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From andre at familiesomers.nl Thu May 25 13:53:43 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 25 May 2017 13:53:43 +0200 Subject: [Development] QList In-Reply-To: <813191495708717@web19j.yandex.ru> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> <813191495708717@web19j.yandex.ru> Message-ID: <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: > > 25.05.2017, 02:19, "Ville Voutilainen" : >> On 24 May 2017 at 22:25, Marc Mutz wrote: >>> On 2017-05-24 15:12, Konstantin Tokarev wrote: >>>> 24.05.2017, 15:49, "NIkolai Marchenko" : >>>>> A semi-sane idea that I think no one has suggested yet: >>>>> >>>>> What if, starting from Qt6, QList becomes a wrapper for QArrayList with a >>>>> contructor from this type? >>>>> After all making existing code slightly _slower_ because of the wrapping >>>>> overhead is way less problematic than breaking it outright. >>>>> It will nudge the users of QLists that need to be fast to switch but will >>>>> leave users of "default no brainer container" happy as they likely wouldn't >>>>> even notice. >>>> If existing Qt APIs switch from QList to QVector in Qt 6, such change >>>> will make it hard to support both Qt 5 and Qt 6 in the same code base. >>> Which is why I suggested to make QList a type alias for QVector or >>> QArrayList, depending on some yet-to-be-determined criteria. Obvious >>> candidates algorithms are: >> I think we need to take a serious step backwards here. I, for various reasons, >> got the impression that a major problem at hand is that when a user (NOT in any >> template code, necessarily) uses QList, that user doesn't know the >> consequences. > Other problem, that IMO is more serious, is that Qt *requires* user to use QList, > by returning or taking it as and argument in various places. That's almost only > reason why I use QList in my code[*]. > > If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with > this APIs will break, unless QList will become an alias of QVector. > > [*] And, fwiw, almost only reason I use QString, but that's off-topic here > I think you bring up a good point there. Would not the best way out be to fix exactly this problem? If these functions would not return a container, but some type of view into such a container, that would leave users free to choose the type of container they need for their job instead of being forced into the direction Qt choose for its API. A view might take the form of a pair of iterators, a range, or perhaps even some specialized class that basicaly wraps a pair or iterators and that provides convenience functions to/from the Qt containers. André From rjvbertin at gmail.com Thu May 25 14:34:59 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 25 May 2017 14:34:59 +0200 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS Message-ID: <1675663.E0tiC2nB9q@patux.local> Hello, Qglobal.h sets QT_NO_EXCEPTIONS automatically when building with -fno- exceptions, but only when a GNU compiler is used, not when using clang. Is that an oversight or rather because it's impossible with clang? Curiously this doesn't always lead to errors in template classes that use QT_TRY, QT_THROW etc. in code built with -fno-exceptions, I wonder how that can be explained. Thanks, René From rjvbertin at gmail.com Thu May 25 15:19:56 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 25 May 2017 15:19:56 +0200 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS References: <1675663.E0tiC2nB9q@patux.local> Message-ID: <2084725.YIYAFKSKK4@portia.local> René J. V. Bertin wrote: > Hello, > > Qglobal.h sets QT_NO_EXCEPTIONS automatically when building with -fno- > exceptions, but only when a GNU compiler is used, not when using clang. Is > that an oversight or rather because it's impossible with clang? The answer is clearly not that it's impossible with clang. Not as straightforward, -fno-exceptions can be detected with defined(Q_CC_CLANG) && !(defined(__EXCEPTIONS) && __has_feature(cxx_exceptions))) (found here: http://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html#the-exceptions-macro) I've filed a bug: https://bugreports.qt.io/browse/QTBUG-61034 R. From cfeck at kde.org Thu May 25 18:40:46 2017 From: cfeck at kde.org (Christoph Feck) Date: Thu, 25 May 2017 18:40:46 +0200 Subject: [Development] QList In-Reply-To: <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> <813191495708717@web19j.yandex.ru> <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> Message-ID: On 25.05.2017 13:53, André Somers wrote: > Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: >> Other problem, that IMO is more serious, is that Qt *requires* user to use QList, >> by returning or taking it as and argument in various places. That's almost only >> reason why I use QList in my code[*]. >> >> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with >> this APIs will break, unless QList will become an alias of QVector. >> >> [*] And, fwiw, almost only reason I use QString, but that's off-topic here >> > I think you bring up a good point there. Would not the best way out be > to fix exactly this problem? If these functions would not return a > container, but some type of view into such a container, that would leave > users free to choose the type of container they need for their job > instead of being forced into the direction Qt choose for its API. A view > might take the form of a pair of iterators, a range, or perhaps even > some specialized class that basicaly wraps a pair or iterators and that > provides convenience functions to/from the Qt containers. If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem. From thiago.macieira at intel.com Thu May 25 17:22:51 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 May 2017 08:22:51 -0700 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS In-Reply-To: <1675663.E0tiC2nB9q@patux.local> References: <1675663.E0tiC2nB9q@patux.local> Message-ID: <1770896.OzsQ8rL2LK@tjmaciei-mobl1> On Thursday, 25 May 2017 05:34:59 PDT René J. V. Bertin wrote: > Hello, > > Qglobal.h sets QT_NO_EXCEPTIONS automatically when building with -fno- > exceptions, but only when a GNU compiler is used, not when using clang. Is > that an oversight or rather because it's impossible with clang? It's a bug in your testing, because it sets QT_NO_EXCEPTIONS here with Clang. $ clang -std=c++14 -fno-exceptions -I. -include QtCore/qglobal.h -fPIC -xc++ - c -o /dev/null - <<<' #ifndef QT_NO_EXCEPTIONS # error Was not defined #endif' [nothing] > Curiously this doesn't always lead to errors in template classes that use > QT_TRY, QT_THROW etc. in code built with -fno-exceptions, I wonder how that > can be explained. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Thu May 25 19:03:58 2017 From: andre at familiesomers.nl (=?utf-8?Q?Andr=C3=A9_Somers?=) Date: Thu, 25 May 2017 19:03:58 +0200 Subject: [Development] QList In-Reply-To: References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> <813191495708717@web19j.yandex.ru> <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> Message-ID: <6266596B-5B29-4675-9B6F-FD6519FAC386@familiesomers.nl> Hi, Sent from my phone, please excuse my brevity > On 25 May 2017, at 18:40, Christoph Feck wrote: > >> On 25.05.2017 13:53, André Somers wrote: >> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: >>> Other problem, that IMO is more serious, is that Qt *requires* user to use QList, >>> by returning or taking it as and argument in various places. That's almost only >>> reason why I use QList in my code[*]. >>> >>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with >>> this APIs will break, unless QList will become an alias of QVector. >>> >>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here >>> >> I think you bring up a good point there. Would not the best way out be >> to fix exactly this problem? If these functions would not return a >> container, but some type of view into such a container, that would leave >> users free to choose the type of container they need for their job >> instead of being forced into the direction Qt choose for its API. A view >> might take the form of a pair of iterators, a range, or perhaps even >> some specialized class that basicaly wraps a pair or iterators and that >> provides convenience functions to/from the Qt containers. > > If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem. Sure, but do you always or even most of the time need that feature? If not, why always pay for it? And it would be easy to turn it into a container when needed, but then you can choose the most appropriate for your task instead of always getting a QList (now) or a QVector (Qt6?) André > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From cfeck at kde.org Thu May 25 19:21:59 2017 From: cfeck at kde.org (Christoph Feck) Date: Thu, 25 May 2017 19:21:59 +0200 Subject: [Development] QList In-Reply-To: <6266596B-5B29-4675-9B6F-FD6519FAC386@familiesomers.nl> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> <813191495708717@web19j.yandex.ru> <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> <6266596B-5B29-4675-9B6F-FD6519FAC386@familiesomers.nl> Message-ID: <8ef9cec4-0f76-b8e5-5277-930b1d42ae73@kde.org> On 25.05.2017 19:03, André Somers wrote: >> On 25 May 2017, at 18:40, Christoph Feck wrote: >> >>> On 25.05.2017 13:53, André Somers wrote: >>> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: >>>> Other problem, that IMO is more serious, is that Qt *requires* user to use QList, >>>> by returning or taking it as and argument in various places. That's almost only >>>> reason why I use QList in my code[*]. >>>> >>>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with >>>> this APIs will break, unless QList will become an alias of QVector. >>>> >>>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here >>>> >>> I think you bring up a good point there. Would not the best way out be >>> to fix exactly this problem? If these functions would not return a >>> container, but some type of view into such a container, that would leave >>> users free to choose the type of container they need for their job >>> instead of being forced into the direction Qt choose for its API. A view >>> might take the form of a pair of iterators, a range, or perhaps even >>> some specialized class that basicaly wraps a pair or iterators and that >>> provides convenience functions to/from the Qt containers. >> >> If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem. > > Sure, but do you always or even most of the time need that feature? If not, why always pay for it? And it would be easy to turn it into a container when needed, but then you can choose the most appropriate for your task instead of always getting a QList (now) or a QVector (Qt6?) Indeed in most cases you really do not need this feature, but unless there will be a compile-time error, we will see subtle bugs/crashes introduced where that feature was relied upon. I have seen many crashes in the big KDE code base from Qt3->Qt4 porting just because the code compiled fine (e.g. after mass-renaming class or method names), but semantics changed in subtle or unexpected ways. From rjvbertin at gmail.com Thu May 25 21:14:09 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 25 May 2017 21:14:09 +0200 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS References: <1675663.E0tiC2nB9q@patux.local> <1770896.OzsQ8rL2LK@tjmaciei-mobl1> Message-ID: <3668163.jan5kASjdX@portia.local> Thiago Macieira wrote: > It's a bug in your testing, because it sets QT_NO_EXCEPTIONS here with Clang. No it's not, ditto for testing by others. In fact, your test is wrong because it misses a detail: this concerns ObjC++. See http://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html#the-exceptions-macro : It explains rather unambiguously that clang 3.6 and later set _EXCEPTIONS `if C++ or ObjC exceptions are enabled` and that `To reliably test if C++ exceptions are enabled, use _EXCEPTIONS && __has_feature(cxx_exceptions), else things won’t work in all versions of Clang in Objective-C++ files.` R From thiago.macieira at intel.com Thu May 25 22:32:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 May 2017 13:32:54 -0700 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS In-Reply-To: <3668163.jan5kASjdX@portia.local> References: <1675663.E0tiC2nB9q@patux.local> <1770896.OzsQ8rL2LK@tjmaciei-mobl1> <3668163.jan5kASjdX@portia.local> Message-ID: <1610090.UGFXXGLIbn@tjmaciei-mobl1> On Thursday, 25 May 2017 12:14:09 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > It's a bug in your testing, because it sets QT_NO_EXCEPTIONS here with > > Clang. > No it's not, ditto for testing by others. In fact, your test is wrong > because it misses a detail: this concerns ObjC++. You never mentioned ObjC++. However: $ clang -std=c++14 -fno-exceptions -I. -include QtCore/qglobal.h -fPIC -xobjective-c++ -c -o /dev/null - <<<' #ifndef QT_NO_EXCEPTIONS # error Was not defined #endif' [nothing] So it still works. I also tested four different Clang versions: 3.8, 3.9, 4.0 and trunk (5.0). What's more, this used to work when Clang 3.6 was current. It even used to work when 2.8 was current, because this has never needed updates. > See > http://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html#the-excep > tions-macro : > > It explains rather unambiguously that clang 3.6 and later set _EXCEPTIONS > `if C++ or ObjC exceptions are enabled` and that `To reliably test if C++ > exceptions are enabled, use _EXCEPTIONS && __has_feature(cxx_exceptions), > else things won’t work in all versions of Clang in Objective-C++ files.` We're testing __EXCEPTIONS, like we should. Please describe the environment in which: a) -fno-exceptions is active b) __EXCEPTIONS is defined Provide the full command-line and the compiler version. I still advise you to look into what's wrong with your testing, because I can't reproduce it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 25 22:38:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 May 2017 13:38:47 -0700 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS In-Reply-To: <1610090.UGFXXGLIbn@tjmaciei-mobl1> References: <1675663.E0tiC2nB9q@patux.local> <3668163.jan5kASjdX@portia.local> <1610090.UGFXXGLIbn@tjmaciei-mobl1> Message-ID: <14717808.xE6gF3AZ1u@tjmaciei-mobl1> On Thursday, 25 May 2017 13:32:54 PDT Thiago Macieira wrote: > We're testing __EXCEPTIONS, like we should. > > Please describe the environment in which: > a) -fno-exceptions is active > b) __EXCEPTIONS is defined > > Provide the full command-line and the compiler version. > > I still advise you to look into what's wrong with your testing, because I > can't reproduce it. Ok, I could reproduce this. It's Apple's bug and regression. $ /Applications/Xcode.app/Contents/Developer/Toolchains/ XcodeDefault.xctoolchain/usr/bin/clang++ -fno-exceptions -std=c++11 -dM -E - xobjective-c++ /dev/null | grep __EXCEPTIONS #define __EXCEPTIONS 1 $ /Applications/Xcode6.4.app/Contents/Developer/Toolchains/ XcodeDefault.xctoolchain/usr/bin/clang++ -fno-exceptions -std=c++11 -dM -E - xobjective-c++ /dev/null | grep __EXCEPTIONS [nothing] Please report to Apple. This problem does not exist upstream and did not exist in previous releases of their Clang. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu May 25 23:51:05 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 25 May 2017 23:51:05 +0200 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS References: <1675663.E0tiC2nB9q@patux.local> <1770896.OzsQ8rL2LK@tjmaciei-mobl1> <3668163.jan5kASjdX@portia.local> <1610090.UGFXXGLIbn@tjmaciei-mobl1> Message-ID: <4576665.qRkxVBsQTy@portia.local> Thiago Macieira wrote: >> It explains rather unambiguously that clang 3.6 and later set _EXCEPTIONS >> `if C++ or ObjC exceptions are enabled` and that `To reliably test if C++ >> exceptions are enabled, use _EXCEPTIONS && __has_feature(cxx_exceptions), >> else things won’t work in all versions of Clang in Objective-C++ files.` > > We're testing __EXCEPTIONS, like we should. I know English isn't my first native tongue, but I read the quote above as "if you want to be certain whether C++ exceptions are enabled, regardless of what clang version is being used and regardless of whether you're compiling C++ or ObjC++, then you should test __EXCEPTIONS in combination with __has_feature(cxx_exceptions)". > Please describe the environment in which: > a) -fno-exceptions is active > b) __EXCEPTIONS is defined > > Provide the full command-line and the compiler version. On OS X 10.9.5 with Qt 5.8.0 and *stock* clang 4.0 (clang version 4.0.0 (tags/RELEASE_400/final)), building KF5 Kinit 5.32.0 with the following probe: #ifdef __EXCEPTIONS #if __EXCEPTIONS #warning "__EXCEPTIONS is defined and true" #else #warning "__EXCEPTIONS is defined but false" #endif #else #warning "__EXCEPTIONS is NOT defined" #endif #ifdef QT_NO_EXCEPTIONS #warning "QT_NO_EXCEPTIONS is defined" #else #warning "QT_NO_EXCEPTIONS is NOT defined" #endif /opt/local/bin/clang++-mp-4.0 -DCMAKE_INSTALL_PREFIX=\"/opt/local\" - DKF5_LIBEXEC_INSTALL_DIR=\"/opt/local/libexec/kde5/kf5\" - DLIB_INSTALL_DIR=\"lib\" -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB - DQT_MAC_USE_COCOA -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_FROM_BYTEARRAY - DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS - DQT_NO_URL_CAST_FROM_STRING -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DTRANSLATION_DOMAIN=\"kinit5\" -D_DARWIN_C_SOURCE - D_LARGEFILE64_SOURCE -I/path/towork/build/src/kdeinit - I/path/to/work/kinit-5.32.0/src/kdeinit - I/path/to/work/build/src/kdeinit/kdeinit5_autogen/include - I/path/to/work/build/src -I/path/to/work/kinit-5.32.0/src -I/path/to/work/build -iframework /opt/local/libexec/qt5/Library/Frameworks -isystem /opt/local/libexec/qt5/Library/Frameworks/QtGui.framework/Headers -isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers -isystem /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Headers - isystem /opt/local/share/qt5/mkspecs/macx-clang -isystem /opt/local/include/KF5/KWindowSystem -isystem /opt/local/include/KF5 -isystem /opt/local/libexec/qt5/Library/Frameworks/QtWidgets.framework/Headers -isystem /opt/local/include/KF5/KCrash -isystem /opt/local/include/KF5/KI18n -isystem /opt/local/include/KF5/KConfigCore -isystem /opt/local/libexec/qt5/Library/Frameworks/QtDBus.framework/Headers -O3 - march=native -g -DNDEBUG -stdlib=libc++ -std=c++0x -fno-operator-names -fno- exceptions -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align - Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon- virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time - pedantic -arch x86_64 -mmacosx-version-min=10.9 -fvisibility=hidden - fvisibility-inlines-hidden -fPIC -std=gnu++11 -o CMakeFiles/kdeinit5.dir/kinit_mac.mm.o -c /path/to/work/kinit-5.32.0/src/kdeinit/kinit_mac.mm kinit_mac.mm:81:2: warning: #warning is a language extension [-Wpedantic] #warning "__EXCEPTIONS is defined and true" kinit_mac.mm:91:2: warning: #warning is a language extension [-Wpedantic] #warning "QT_NO_EXCEPTIONS is NOT defined" When I add -fno-objc-exceptions __EXCEPTIONS is no longer defined and QT_NO_EXCEPTIONS is. This is exactly as described in the linked document from llvm.org . Also exactly as described: when I use the exact same commandline with /usr/bin/clang++ (Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)), the probe prints kinit_mac.mm:86:2: warning: #warning is a language extension [-Wpedantic] #warning "__EXCEPTIONS is NOT defined" kinit_mac.mm:89:2: warning: #warning is a language extension [-Wpedantic] #warning "QT_NO_EXCEPTIONS is defined" QT_NO_EXCEPTIONS is indeed defined with both compilers when compiling regular C++ files. Did you do all your testing on Mac? > Ok, I could reproduce this. It's Apple's bug and regression. > > $ /Applications/Xcode.app/Contents/Developer/Toolchains/ > XcodeDefault.xctoolchain/usr/bin/clang++ -fno-exceptions -std=c++11 -dM -E - > xobjective-c++ /dev/null | grep __EXCEPTIONS > #define __EXCEPTIONS 1 What Xcode version is this? Clang 3.6 was introduced with Xcode 6.3 . If your Xcode.app is older than that you're not seeing a regression introduced by Apple but a feature introduced upstream. (Admittedly it could be both, given Apple's role in LLVM & clang ^^) > > $ /Applications/Xcode6.4.app/Contents/Developer/Toolchains/ > XcodeDefault.xctoolchain/usr/bin/clang++ -fno-exceptions -std=c++11 -dM -E - > xobjective-c++ /dev/null | grep __EXCEPTIONS > [nothing] From thiago.macieira at intel.com Fri May 26 08:45:28 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 May 2017 23:45:28 -0700 Subject: [Development] Blacklisting: CI vs non-CI Message-ID: <2588867.aP3dJy60Ez@tjmaciei-mobl1> I've seen some blacklists, in the past, that were real flaky tests: things that would be unstable on any machine, given the proper conditions. But most of the recent blacklists, and certainly all the BPASS I see when I run tests, are due to the tests being run in an environment that runs 300x slower than normal. Can we invent a blacklist that only applies to slow machines? I don't need to see those BPASS on 100% of the time that the test is run on my machine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From swarit.wipra at gmail.com Fri May 26 10:12:03 2017 From: swarit.wipra at gmail.com (swarit wipra) Date: Fri, 26 May 2017 13:42:03 +0530 Subject: [Development] Regarding build/Link error while building my Qt Project Code in the Microsoft Visual Studio 2015 ( OS : Windows 10 ) Message-ID: Hi Folks, Good Day !! I am trying to build my Qt source code in the Microsoft Visual Studio 2015. It fails with the following Link error: Severity Code Description Project File Line Suppression State *Error LNK1104 cannot open file 'Qt5Declaratived.lib'* Please help me in fixing this. Thanks in advance. Best Regards Swarit -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Fri May 26 12:08:55 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 26 May 2017 12:08:55 +0200 Subject: [Development] Blacklisting: CI vs non-CI In-Reply-To: <2588867.aP3dJy60Ez@tjmaciei-mobl1> References: <2588867.aP3dJy60Ez@tjmaciei-mobl1> Message-ID: <201705261208.55753.kde@carewolf.com> On Friday 26 May 2017, Thiago Macieira wrote: > I've seen some blacklists, in the past, that were real flaky tests: things > that would be unstable on any machine, given the proper conditions. > > But most of the recent blacklists, and certainly all the BPASS I see when I > run tests, are due to the tests being run in an environment that runs 300x > slower than normal. Can we invent a blacklist that only applies to slow > machines? > > I don't need to see those BPASS on 100% of the time that the test is run on > my machine. What about a flaky list for tests that are allowed to be run multiple times until they pass more than 50% of the time? I think we already have something like that for integration, but it could be narrowed to specific tests and then allowed even more runs and be used outside of integration. Best regards `Allan From annulen at yandex.ru Fri May 26 12:12:30 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 26 May 2017 13:12:30 +0300 Subject: [Development] Blacklisting: CI vs non-CI In-Reply-To: <2588867.aP3dJy60Ez@tjmaciei-mobl1> References: <2588867.aP3dJy60Ez@tjmaciei-mobl1> Message-ID: <2304071495793550@web29g.yandex.ru> 26.05.2017, 09:45, "Thiago Macieira" : > I've seen some blacklists, in the past, that were real flaky tests: things that > would be unstable on any machine, given the proper conditions. > > But most of the recent blacklists, and certainly all the BPASS I see when I > run tests, are due to the tests being run in an environment that runs 300x > slower than normal. Can we invent a blacklist that only applies to slow > machines? > > I don't need to see those BPASS on 100% of the time that the test is run on my > machine. If problem is that tests just don't have enough time to complete in CI environment, it would be a good idea to mark such tests as "slow" so they get higher timeout settings. > > -- > 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 kde at carewolf.com Fri May 26 12:31:35 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 26 May 2017 12:31:35 +0200 Subject: [Development] Blacklisting: CI vs non-CI In-Reply-To: <2304071495793550@web29g.yandex.ru> References: <2588867.aP3dJy60Ez@tjmaciei-mobl1> <2304071495793550@web29g.yandex.ru> Message-ID: <201705261231.35850.kde@carewolf.com> On Friday 26 May 2017, Konstantin Tokarev wrote: > 26.05.2017, 09:45, "Thiago Macieira" : > > I've seen some blacklists, in the past, that were real flaky tests: > > things that would be unstable on any machine, given the proper > > conditions. > > > > But most of the recent blacklists, and certainly all the BPASS I see when > > I run tests, are due to the tests being run in an environment that runs > > 300x slower than normal. Can we invent a blacklist that only applies to > > slow machines? > > > > I don't need to see those BPASS on 100% of the time that the test is run > > on my machine. > > If problem is that tests just don't have enough time to complete in CI > environment, it would be a good idea to mark such tests as "slow" so they > get higher timeout settings. > That is not always the issue. Sometimes timings are just so far off the tests no longer work. Be it due to the test testing timing specifically or because it is doing simulated input. There are almost as many reason for the flakiness as there are flaky tests. Best regards `Allan From marc.mutz at kdab.com Fri May 26 13:31:49 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 26 May 2017 13:31:49 +0200 Subject: [Development] QList In-Reply-To: References: <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> Message-ID: <201705261331.50108.marc.mutz@kdab.com> On Thursday 25 May 2017 18:40:46 Christoph Feck wrote: > If you only return a view to the container, then if the container is > modified, the return value is no longer valid. Returning a full > container (referenced, with copy-on-write semantics) will not have this > problem. If you return a vector of QRects from QRegion, then modify the QRegion, the rectangles you have a no longer valid, either. Yes, the program will not crash, nor will Valgrind complain. But it will use outdated information. If you use the QRegion::begin/end(), and you do the same mistake, you get a crash or valgrind complains. So what you said is that you'd rather have the API hide your mistakes from you than to point them out to you. Interesting approach. I wish you luck persuing it. Thanks, Marc (seriously considering installing Gnome now) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Fri May 26 13:46:48 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 26 May 2017 13:46:48 +0200 Subject: [Development] Qt 5.9.0 RC released In-Reply-To: References: Message-ID: <201705261346.48825.marc.mutz@kdab.com> On Wednesday 24 May 2017 12:48:15 Jani Heikkinen wrote: > Hi all, > > Qt 5.9.0 RC is now available. Diff to beta4 can be found as an attachment. > > You can update RC at the top of existing online installation by using > maintenance tool or do clean installation. Instructions how to get the > release via online installer are here: > https://wiki.qt.io/How_to_get_snapshot_via_online_installer. At this time > there is also offline installers available, see > http://download.qt.io/development_releases/qt/5.9/5.9.0-rc/ > > Please test the release as soon as possible and report your effort via > https://wiki.qt.io/Qt59_release_testing. We are planning to release Qt > 5.9.0 final Wed 31.5.2017. https://bugreports.qt.io/browse/QTBUG-60837 should be fixed for 5.9.0. The fix is up on Gerrit the whole week already, but the release team is refusing to merge it and make an RC2. If such issues are not cause for a RC2, then why do we bother with betas and RCs at all? Just branch off of dev, call it 5.9.0 and follow up a few weeks later with 5.9.1. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From jani.heikkinen at qt.io Fri May 26 15:18:01 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 26 May 2017 13:18:01 +0000 Subject: [Development] Qt 5.9.0 RC released In-Reply-To: <201705261346.48825.marc.mutz@kdab.com> References: <201705261346.48825.marc.mutz@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Marc Mutz > Sent: perjantai 26. toukokuuta 2017 14.47 > To: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Qt 5.9.0 RC released > > On Wednesday 24 May 2017 12:48:15 Jani Heikkinen wrote: > > Hi all, > > > > Qt 5.9.0 RC is now available. Diff to beta4 can be found as an attachment. > > > > You can update RC at the top of existing online installation by using b> > maintenance tool or do clean installation. Instructions how to get the > > release via online installer are here: > > https://wiki.qt.io/How_to_get_snapshot_via_online_installer. At this > > time there is also offline installers available, see > > http://download.qt.io/development_releases/qt/5.9/5.9.0-rc/ > > > > Please test the release as soon as possible and report your effort via > > https://wiki.qt.io/Qt59_release_testing. We are planning to release Qt > > 5.9.0 final Wed 31.5.2017. > > https://bugreports.qt.io/browse/QTBUG-60837 should be fixed for 5.9.0. > The fix is up on Gerrit the whole week already, but the release team is > refusing to merge it and make an RC2. > > If such issues are not cause for a RC2, then why do we bother with betas and > RCs at all? Just branch off of dev, call it 5.9.0 and follow up a few weeks later > with 5.9.1. > To be honest this comment feels a bit unfair: Original error report was P2 and quite many important information were missing. And that's why this wasn't seen as a blocker for the release or critical enough for 'rc2'. We have re-evaluated the decision based on new information got today & we agree we should fix this before release. That's why we have already staged the fix in. Hoping all will proceed OK and we can release rc2 (= RC + just a fix for QTBUG-60837, nothing else) on Monday and keep the original schedule for the final. br, Jani From thiago.macieira at intel.com Fri May 26 05:40:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 May 2017 20:40:43 -0700 Subject: [Development] clang and auto-setting of QT_NO_EXCEPTIONS In-Reply-To: <4576665.qRkxVBsQTy@portia.local> References: <1675663.E0tiC2nB9q@patux.local> <1610090.UGFXXGLIbn@tjmaciei-mobl1> <4576665.qRkxVBsQTy@portia.local> Message-ID: <1886696.nCAl18oS9U@tjmaciei-mobl1> On Thursday, 25 May 2017 14:51:05 PDT René J. V. Bertin wrote: > > Ok, I could reproduce this. It's Apple's bug and regression. > > > > $ /Applications/Xcode.app/Contents/Developer/Toolchains/ > > XcodeDefault.xctoolchain/usr/bin/clang++ -fno-exceptions -std=c++11 -dM -E > > - xobjective-c++ /dev/null | grep __EXCEPTIONS > > #define __EXCEPTIONS 1 > > What Xcode version is this? Clang 3.6 was introduced with Xcode 6.3 . If > your Xcode.app is older than that you're not seeing a regression introduced > by Apple but a feature introduced upstream. (Admittedly it could be both, > given Apple's role in LLVM & clang ^^) The only Clang that matters on a Mac (the one that came with the latest XCode). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri May 26 17:31:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 May 2017 08:31:39 -0700 Subject: [Development] Blacklisting: CI vs non-CI In-Reply-To: <2304071495793550@web29g.yandex.ru> References: <2588867.aP3dJy60Ez@tjmaciei-mobl1> <2304071495793550@web29g.yandex.ru> Message-ID: <2116834.xgDbcX4DyS@tjmaciei-mobl1> On Friday, 26 May 2017 03:12:30 PDT Konstantin Tokarev wrote: > If problem is that tests just don't have enough time to complete in CI > environment, it would be a good idea to mark such tests as "slow" so they > get higher timeout settings. The problem is not the full test timeout. It's intermediate timeouts: every time you use QTRY_VERIFY, QTRY_COMPARE, QElapsedTimer, QDeadlineTimer, QTestEventLoop::timeout, etc., your test is now "flaky" because what you measured to take a few microseconds can now take up to a second to run. I've already decided I won't fix such issues. The CI needs to be brought up to normal performance instead. That means we need to blacklist those tests for a while. I'm simply asking how to hide those BPASS. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Fri May 26 17:48:59 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 26 May 2017 15:48:59 +0000 Subject: [Development] Blacklisting: CI vs non-CI In-Reply-To: <2588867.aP3dJy60Ez@tjmaciei-mobl1> References: <2588867.aP3dJy60Ez@tjmaciei-mobl1> Message-ID: Hi, Is it possible that you're looking for the "ci" keyword in the exclusion files? Tor Arne implemented it for https://bugreports.qt.io/browse/QTBUG-59564 Simon ________________________________ From: Development on behalf of Thiago Macieira Sent: Friday, May 26, 2017 8:45:28 AM To: development at qt-project.org Subject: [Development] Blacklisting: CI vs non-CI I've seen some blacklists, in the past, that were real flaky tests: things that would be unstable on any machine, given the proper conditions. But most of the recent blacklists, and certainly all the BPASS I see when I run tests, are due to the tests being run in an environment that runs 300x slower than normal. Can we invent a blacklist that only applies to slow machines? I don't need to see those BPASS on 100% of the time that the test is run on my machine. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri May 26 18:07:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 May 2017 09:07:21 -0700 Subject: [Development] Blacklisting: CI vs non-CI In-Reply-To: References: <2588867.aP3dJy60Ez@tjmaciei-mobl1> Message-ID: <21121459.6ymBdhQYVS@tjmaciei-mobl1> On Friday, 26 May 2017 08:48:59 PDT Simon Hausmann wrote: > Hi, > > > Is it possible that you're looking for the "ci" keyword in the exclusion > files? > > > Tor Arne implemented it for https://bugreports.qt.io/browse/QTBUG-59564 That's exactly what I wanted. But it looks like I'm not the only one who didn't know, because I'm seeing new blacklists come in for clearly CI-specific issues that don't use the "ci" keyword. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ewleaver at comcast.net Fri May 26 23:41:45 2017 From: ewleaver at comcast.net (Ed Leaver) Date: Fri, 26 May 2017 17:41:45 -0400 Subject: [Development] Qt 5.9.0 RC released In-Reply-To: References: <201705261346.48825.marc.mutz@kdab.com> Message-ID: <0f430316-1337-7ee1-4435-2aafca7fa30d@comcast.net> Thanks, Jani :-) On 05/26/2017 09:18 AM, Jani Heikkinen wrote: >> -----Original Message----- >> From: Development [mailto:development- >> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Marc Mutz >> Sent: perjantai 26. toukokuuta 2017 14.47 >> To: development at qt-project.org; releasing at qt-project.org >> Subject: Re: [Development] Qt 5.9.0 RC released >> >> On Wednesday 24 May 2017 12:48:15 Jani Heikkinen wrote: >>> Hi all, >>> >>> Qt 5.9.0 RC is now available. Diff to beta4 can be found as an attachment. >>> >>> You can update RC at the top of existing online installation by using > b> > maintenance tool or do clean installation. Instructions how to get the >>> release via online installer are here: >>> https://wiki.qt.io/How_to_get_snapshot_via_online_installer. At this >>> time there is also offline installers available, see >>> http://download.qt.io/development_releases/qt/5.9/5.9.0-rc/ >>> >>> Please test the release as soon as possible and report your effort via >>> https://wiki.qt.io/Qt59_release_testing. We are planning to release Qt >>> 5.9.0 final Wed 31.5.2017. >> https://bugreports.qt.io/browse/QTBUG-60837 should be fixed for 5.9.0. >> The fix is up on Gerrit the whole week already, but the release team is >> refusing to merge it and make an RC2. >> >> If such issues are not cause for a RC2, then why do we bother with betas and >> RCs at all? Just branch off of dev, call it 5.9.0 and follow up a few weeks later >> with 5.9.1. >> > To be honest this comment feels a bit unfair: Original error report was P2 and quite many important information were missing. And that's why this wasn't seen as a blocker for the release or critical enough for 'rc2'. > > We have re-evaluated the decision based on new information got today & we agree we should fix this before release. That's why we have already staged the fix in. Hoping all will proceed OK and we can release rc2 (= RC + just a fix for QTBUG-60837, nothing else) on Monday and keep the original schedule for the final. > > br, > Jani > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From nabbz0rz at gmail.com Sun May 28 05:00:53 2017 From: nabbz0rz at gmail.com (Casey Sanchez) Date: Sat, 27 May 2017 23:00:53 -0400 Subject: [Development] [Qt-Quick] GridStar layout for QML Message-ID: I've created a grid layout that I find to be more functional than the default that is provided. For full documentation please see: https://forum.qt.io/topic/64699/gridstar-layout The Git Repo can be found here: https://github.com/Tannz0rz/GridStarLayout/tree/master/Quick Any suggestions are appreciated. Thank you for your consideration. -------------- next part -------------- An HTML attachment was scrubbed... URL: From c64zottel at gmail.com Sun May 28 08:41:33 2017 From: c64zottel at gmail.com (c64zottel .) Date: Sun, 28 May 2017 08:41:33 +0200 Subject: [Development] How to deal with C++ Interfaces in Qml? Message-ID: Hello, I am trying to figure out how to pass objects derived from a pure virtual class and encountered several issues (I guess): There are 2 classes derived from InputDeviceConfiguratorGate: JoystickDeviceConfigurator and KeyboardDeviceConfigurator. If I try to register them like: qmlRegisterUncreatableType( "JoystickDeviceConfigurator", 1, 0, "JoystickDeviceConfigurator", "Not creatable in Qml." ); qmlRegisterUncreatableType( "KeyboardDeviceConfigurator", 1, 0, "KeyboardDeviceConfigurator", "Not creatable in Qml." ); Then Qml throws: QMetaType::registerTypedef: -- Type name 'InputDeviceConfiguratorGate*' previously registered as typedef of 'JoystickDeviceConfigurator*' [1049], now registering as typedef of 'KeyboardDeviceConfigurator*' [1052]. If I to use qmlRegisterInterface( "InputDeviceConfiguratorGate" ); Then I can't use the actual interface in Qml. (I can? How?) I already asked on the qt forum: https://forum.qt.io/topic/79589/how-to-use-a-virtual-interface-in-qml-with-qmlregisterinterface https://forum.qt.io/topic/79691/how-to-use-a-specialization-of-an-c-interface to find out someone else opened the topic 2 years ago: https://forum.qt.io/topic/54387/how-do-you-use-c-interfaces-pure-virtual-class-in-qml Thanks for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oktal3700 at gmail.com Sun May 28 13:17:31 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Sun, 28 May 2017 12:17:31 +0100 Subject: [Development] [Qt-Quick] GridStar layout for QML In-Reply-To: References: Message-ID: I don't see a copyright license. On 28 May 2017 at 04:00, Casey Sanchez wrote: > I've created a grid layout that I find to be more functional than the > default that is provided. > > For full documentation please see: > https://forum.qt.io/topic/64699/gridstar-layout > > The Git Repo can be found here: > https://github.com/Tannz0rz/GridStarLayout/tree/master/Quick > > > Any suggestions are appreciated. Thank you for your consideration. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nabbz0rz at gmail.com Sun May 28 14:25:02 2017 From: nabbz0rz at gmail.com (Casey Sanchez) Date: Sun, 28 May 2017 08:25:02 -0400 Subject: [Development] [Qt-Quick] GridStar layout for QML Message-ID: Pardon me, if you couldn't tell I am new at this; LGPLv2.1 added accordingly. Thank you for the warning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markg85 at gmail.com Sun May 28 15:57:20 2017 From: markg85 at gmail.com (Mark Gaiser) Date: Sun, 28 May 2017 15:57:20 +0200 Subject: [Development] [Qt-Quick] GridStar layout for QML In-Reply-To: References: Message-ID: On Sun, May 28, 2017 at 5:00 AM, Casey Sanchez wrote: > I've created a grid layout that I find to be more functional than the > default that is provided. > > For full documentation please see: > https://forum.qt.io/topic/64699/gridstar-layout > > The Git Repo can be found here: > https://github.com/Tannz0rz/GridStarLayout/tree/master/Quick > > > Any suggestions are appreciated. Thank you for your consideration. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > Hi, That looks neat! Just a couple of questions (without reading the code or playing with it) 1. Does it allow dynamic row/comumn add/removal? A usecase for that would be a column based file browser where opening a folder would create a new column. 2. Are states and transitions supported? So when a cell changes in size, can that change be animated (obviously provided the transition effect is defined in qml, it isn't be default)? 3. "GridStar.rowSpan: 0 // Span remaining rows" doesn't look intuitive to me. Something like "auto" or "fill" would perhaps be more fitting? I've been playing with an improved Grid concept as well. In my case it is inspired by the CSS Grid Layout [1]. I would define the layout in ASCII. A simple example would be something like this: ApplicationWindow { width: 800 height: 600 GridLayout { anchors.fill: parent layout: [ "header", "col content", "footer" ] Rectangle { id: header height: 100 } Rectangle { id: col width: 50 } Rectangle { id: content } Rectangle { id: footer height: 25 } } } Not defining sizes (width/height) would distribute all available space evenly. The "content" element in this example therefore has no width/height. It simply takes all remaining space. This concept worked quite well and i had some working code (the example above actually worked!). It quickly became rather complicated when cell spacing would be included, animations and dynamic additions/removal of cells and layout re-calculations. That's where i left it i think. [1] https://www.w3.org/TR/css-grid-1/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nabbz0rz at gmail.com Sun May 28 17:22:42 2017 From: nabbz0rz at gmail.com (Casey Sanchez) Date: Sun, 28 May 2017 11:22:42 -0400 Subject: [Development] [Qt-Quick] GridStar layout for QML Message-ID: 1. At this point, no it does not. That feature can be easily added. 2. Again, no. I'm certain it wouldn't be that difficult of an implementation however. 3. Not necessarily, any span value less than or equal to 0 spans the remaining rows, plus that value. So 0 spans the remaining rows, -1 spans the remaining rows minus 1, -2 spans the remaining rows minus 2, and so on. 4. So long as the row/column definitions have equal weights they will all occupy the same amount of space; weights all have a default value of 1, so you could do say: ColumnDefinition { } ColumnDefinition { } ColumnDefinition { } But again, so long as the weights are equal the result is the same. -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Mon May 29 11:35:00 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Mon, 29 May 2017 09:35:00 +0000 Subject: [Development] [Announce] Qt 5.9 RC2 released Message-ID: Hi all, Qt 5.9 RC2 is available. It is Qt 5.9 RC + https://codereview.qt-project.org/#/c/195341/ At this time RC2 is available via online installers only, instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. And because there is only one change after official RC we should be able to release final Qt 5.9.0 this Wed (31.5.2017) as planned. br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jani.heikkinen at qt.io Mon May 29 11:35:45 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 29 May 2017 09:35:45 +0000 Subject: [Development] Qt 5.9 RC2 released Message-ID: Hi all, Qt 5.9 RC2 is available. It is Qt 5.9 RC + https://codereview.qt-project.org/#/c/195341/ At this time RC2 is available via online installers only, instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. And because there is only one change after official RC we should be able to release final Qt 5.9.0 this Wed (31.5.2017) as planned. br, Jani Heikkinen Release Manager From Kai.Koehne at qt.io Mon May 29 12:43:23 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Mon, 29 May 2017 10:43:23 +0000 Subject: [Development] Please add [ChangeLog] entries to your commits! Message-ID: Hi, I just noticed that, out of the 61 commits in qtbase/5.9 that are not part of 5.9.0, only one has a [ChangeLog] entry. Some of the commits are either changes to doc, or autotests, but for the rest: If it is not important enough to be mentioned to the user, why is the change in 5.9? Please be reminded that all changes that might be of interest to the end user should be part of the ChangeLog. So please, whenever reviewing a change, please check whether a [ChangeLog] entry is in order. Thanks Kai -- Kai Köhne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com From announce at qt-project.org Mon May 29 13:19:08 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Mon, 29 May 2017 13:19:08 +0200 Subject: [Development] [Announce] Qbs 1.8.0 released Message-ID: Hi, we are happy to announce the release of qbs 1.8.0. You can find all the relevant information here: https://blog.qt.io/blog/2017/05/29/qbs-1-8-released _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jhihn at gmx.com Mon May 29 14:53:24 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 29 May 2017 14:53:24 +0200 Subject: [Development] QList In-Reply-To: <6266596B-5B29-4675-9B6F-FD6519FAC386@familiesomers.nl> References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> <813191495708717@web19j.yandex.ru> <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> <6266596B-5B29-4675-9B6F-FD6519FAC386@familiesomers.nl> Message-ID: > Sent: Thursday, May 25, 2017 at 7:03 PM > From: "André Somers" > To: "Christoph Feck" > Cc: development at qt-project.org > Subject: Re: [Development] QList > > Hi, > > Sent from my phone, please excuse my brevity > > > On 25 May 2017, at 18:40, Christoph Feck wrote: > > > >> On 25.05.2017 13:53, André Somers wrote: > >> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: > >>> Other problem, that IMO is more serious, is that Qt *requires* user to use QList, > >>> by returning or taking it as and argument in various places. That's almost only > >>> reason why I use QList in my code[*]. > >>> > >>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with > >>> this APIs will break, unless QList will become an alias of QVector. > >>> > >>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here > >>> > >> I think you bring up a good point there. Would not the best way out be > >> to fix exactly this problem? If these functions would not return a > >> container, but some type of view into such a container, that would leave > >> users free to choose the type of container they need for their job > >> instead of being forced into the direction Qt choose for its API. A view > >> might take the form of a pair of iterators, a range, or perhaps even > >> some specialized class that basicaly wraps a pair or iterators and that > >> provides convenience functions to/from the Qt containers. > > > > If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem. > > Sure, but do you always or even most of the time need that feature? If not, why always pay for it? And it would be easy to turn it into a container when needed, but then you can choose the most appropriate for your task instead of always getting a QList (now) or a QVector (Qt6?) I wonder how gsl::span plays into this. I just learned about span, quick seems to be wet we need here? > André > > > _______________________________________________ > > 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 29 15:27:10 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 29 May 2017 13:27:10 +0000 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Kai Koehne > Sent: Monday, 29 May 2017 12:43 PM > To: development at qt-project.org > Subject: [Development] Please add [ChangeLog] entries to your commits! > > Hi, > > I just noticed that, out of the 61 commits in qtbase/5.9 that are not part of > 5.9.0, only one has a [ChangeLog] entry. > > Some of the commits are either changes to doc, or autotests, but for the > rest: If it is not important enough to be mentioned to the user, why is the > change in 5.9? > > Please be reminded that all changes that might be of interest to the end user > should be part of the ChangeLog. So please, whenever reviewing a change, > please check whether a [ChangeLog] entry is in order. Do we have a set of guidelines for what is considered interesting? > Thanks > > Kai > > -- > Kai Köhne, Senior Manager R&D | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 > B > > The Future is Written with Qt > www.qtworldsummit.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Mon May 29 16:15:38 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 29 May 2017 16:15:38 +0200 Subject: [Development] QList In-Reply-To: References: <2113093.zhT74SXtvi@maurice> <1706186.7l5m6VU2rZ@tjmaciei-mobl1> <3798391495631520@web25o.yandex.ru> <813191495708717@web19j.yandex.ru> <0b7455f7-3f09-d81a-f398-c44cf85d7652@familiesomers.nl> <6266596B-5B29-4675-9B6F-FD6519FAC386@familiesomers.nl> Message-ID: <59473ed3-6e6a-4b72-8f4b-91dade8d2059@familiesomers.nl> Hi, Op 29/05/2017 om 14:53 schreef Jason H: >> Sent: Thursday, May 25, 2017 at 7:03 PM >> From: "André Somers" >> To: "Christoph Feck" >> Cc: development at qt-project.org >> Subject: Re: [Development] QList >> >> Hi, >> >> On 25 May 2017, at 18:40, Christoph Feck wrote: >> >>>> On 25.05.2017 13:53, André Somers wrote: >>>> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: >>>>> Other problem, that IMO is more serious, is that Qt *requires* user to use QList, >>>>> by returning or taking it as and argument in various places. That's almost only >>>>> reason why I use QList in my code[*]. >>>>> >>>>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with >>>>> this APIs will break, unless QList will become an alias of QVector. >>>>> >>>>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here >>>>> >>>> I think you bring up a good point there. Would not the best way out be >>>> to fix exactly this problem? If these functions would not return a >>>> container, but some type of view into such a container, that would leave >>>> users free to choose the type of container they need for their job >>>> instead of being forced into the direction Qt choose for its API. A view >>>> might take the form of a pair of iterators, a range, or perhaps even >>>> some specialized class that basicaly wraps a pair or iterators and that >>>> provides convenience functions to/from the Qt containers. >>> If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem. >> Sure, but do you always or even most of the time need that feature? If not, why always pay for it? And it would be easy to turn it into a container when needed, but then you can choose the most appropriate for your task instead of always getting a QList (now) or a QVector (Qt6?) > > > > I wonder how gsl::span plays into this. I just learned about span, quick seems to be wet we need here? > Not at all, I think. gsl::span is "a non-owning range of contiguous memory" according to https://www.quora.com/What-is-the-span-T-in-the-CppCoreGuidelines. As QList does not obey that definition, it would rule out being a view into QList (or its successor with the same semantics) already. André From wim.delvaux at adaptiveplanet.com Tue May 30 00:22:15 2017 From: wim.delvaux at adaptiveplanet.com (wim delvaux) Date: Tue, 30 May 2017 00:22:15 +0200 Subject: [Development] Question on using multiple multicast receives on same channel in one program Message-ID: Hi all, I was wondering if it possible to open multiple QUdpSockets on the same multicast address/port pair. I need to write a little mockup application that consists of serveral 'threads' which normally run in difference processes. I want this mockup to be as close to the target solution as possible. Therefore I tried to open multiple connections to that multicast address/port but to no avail. Other solutions ? Anyone ? W -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue May 30 00:33:18 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 May 2017 15:33:18 -0700 Subject: [Development] Question on using multiple multicast receives on same channel in one program In-Reply-To: References: Message-ID: <1571519.cSGe9avGnr@tjmaciei-mobl1> On segunda-feira, 29 de maio de 2017 15:22:15 PDT wim delvaux wrote: > Hi all, > > I was wondering if it possible to open multiple QUdpSockets on the same > multicast address/port pair. Sure! > I need to write a little mockup application that consists of serveral > 'threads' which normally run > in difference processes. I want this mockup to be as close to the target > solution as possible. > > Therefore I tried to open multiple connections to that multicast > address/port but to no avail. > > Other solutions ? Anyone ? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From vivek at alokin.in Tue May 30 06:50:06 2017 From: vivek at alokin.in (Vivek P) Date: Tue, 30 May 2017 10:20:06 +0530 Subject: [Development] (no subject) Message-ID: http://lists.qt-project.org/pipermail/interest/2015-April/016264.html. I got the same error while starting wayland client with wayland-brcm platform plugin on raspberry pi . Can anyone help me to fix this error -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Tue May 30 09:15:15 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Tue, 30 May 2017 07:15:15 +0000 Subject: [Development] Periodical digest from the CI (2017/05) - CI Performance, HW and SW changes Message-ID: Hi all! I was due to write you something about the CI. This time I’ll cover the topics performance as well as upcoming hardware and software changes. Performance: You have all noticed that the CI system is behaving poorly to what comes to the performance. Sometimes autotests take over 30 times longer to run compared to a normal situation. Now why is that? We actually have different kinds of bottlenecks. One is the bandwidth with which the virtual machines (VMs) store local data to their virtual hard drives. The servers on which our virtual machines run have no local hard drives. They instead store all their data on a centralized storage called the Compellent (https://en.wikipedia.org/wiki/Dell_Compellent). So when a VM wants to store data on its virtual hard drive, the host it runs on actually stores the data on the centralized storage. We have several generations of hardware installed, and they have different speeds on their SAN interface with which they are connected to the Compellent. As your build picks up a server, it can be a new rack server, or it can be an older generation Blade (https://en.wikipedia.org/wiki/Blade_server). Also, all the other VMs on these servers share the same bandwidth, so depending on what the other builds do, your SAN connection can be affected. Sadly, our test of prioritization these VMs, didn’t produce expected results and really didn’t much at all. These generations of hardware and type of hardware also affect the amount of other VMs the hardware can run simultaneously. We have Mac mini’s running our macOS builds. Those generally run 1 VM per physical Mac mini. Then we have old Blades that run around 4 VMs per Blade. The latest additions to our hardware pool are dual socket 20 core CPU server racks. Those run up to 26 VMs simultaneously. Running more on the same hardware reduces costs for us, but also increases the odds of one build affecting the next. Another bottleneck is the Compellent itself. The storage system has 120 + 10 spare hard drives spinning at 15K RPM. However great the IOPS performance is in that system, when we decide to start 200+ VMs in the CI, it goes down to its knees. And when it does that, all builds and autotest run are affected. You could think of this as you having 2 computers at home sharing the same spinning disk. Now that all is grim and morbid, let’s continue with the good news. Upcoming hardware changes: We’re replacing the current hardware stack with a completely new one. The parts have arrived and are being installed as I type right now. Not only did we acquire new hardware that is faster, but we also redesigned the building concepts so that they utilize the hardware differently. The new hardware can be easily expanded and we designed the system so, that we don’t produce bottlenecks even when expanding it. Before I go in to details, I need to explain a bit how the CI systems generally works. So heading off on a tangent here! When developer stages a commit in Gerrit (codereview.qt-project.org), the CI picks it (or multiple commits) up. The CI or Coin as the piece of software is figuratively called, generates work items based on the data received. If let’s say the commits was for QtDeclarative, Coin now produces work items for itself to handle that QtDeclarative build on top of circa 30 different target platforms. Each of these work items depend on QtBase to be built. So now Coin also creates these circa 30 work items for QtBase. As QtDeclarative is built on top of the current qt5.git’s QtBase, it means in normal situations that QtBase has already been built previously. These artifacts have been stored by Coin and can now be reused. So instead of rebuilding QtBase for QtDeclarative, Coin simply checks its storage and links the previous builds to the current one and promptly continues with building QtDeclarative. This is the major change in how we build Qt nowadays compared to old days with Jenkins where every build always rebuilt the entire stack up to its point. Continuing into more details. Whenever Coin starts to build something, it needs a VM for the task. We have “templates” in vSphere that represent different operating systems. They are virtual machines that have operating systems installed in them along with some basic things set up like user accounts and SSHD etc. Then they have been shut down ready to be used. Now when a build needs a VM, it clones a template VM and launches the clone. The clone is actually only a linked clone. This means that we don’t really clone anything, but only create a new virtual machine that links or points to the original one. Now, when the new clone is powered on, it _reads_ from the original template, but all changes are _written_ to its own file called the ‘delta image’. This way a new virtual machine only takes up space that’s equal to the amount of data it has written. Going back to the template again. I said that it only contained basic things like user accounts and SSHD. A build surely needs more than that. We need Visual Studios, MINGW, CMake, OpenSSH, XCodes, MySQL etc installed as well. Those things are ‘provisioned’. In qt5.git we have a folder structure under /coin/provisioning that contains scripts that install these things. As there is no point in running them every time for every VM, we create yet another set of templates that contain these pre-installed. We call these TIER2 images (or templates) vs TIER1 images being the vanilla distros containing only the basic things enabling us to even use them. TIER2 images work pretty much the same way as QtBase was a dependency for QtDeclarative. Each build we trigger checks the current configurations scripts from qt5.git and makes a SHA from the folder structure. This SHA is used in naming the TIER2 image. If the content we want to install has changed, we have to regenerate a new TIER2 image. This is called the provisioning and it’s triggered automatically if the requested TIER2 image doesn’t exist. Now, let’s go back on track and talk about the hardware changes. The new servers have local SSD drives that work as the storage for the VMs instead of a centralized storage. This removes the bottleneck of a SAN network and reduces latencies while at it. And while being SSD drives, they are faster by design to what the Compellent used to be with its rotating discs. We still have a Compellent, but this time it’s filled with SSD drives. While the VMs use local SSD drives on the hosts themselves to store data, reading is a more complicated thing. The TIER1 and TIER2 images described earlier are still stored centralized on the Compellent. This saves us the transferring of the images to each server serving as the host for the VMs. These TIER2 images are cloned as normal, and then the read operations point to the source. This would cause the same situation as with the old system where everything is read from the Compellent, but we are relying on caches to work in our favor here. The TIER2 images are shared via NFS, and the host OS on the server is equipped with a 500 GB NFS cache. So whenever something is read from the TIER2, it is in fact now read from the NFS cache that’s local. All this is obviously assuming that the data has been read once previously. In practice, if a TIER2 image gets updated, the data has to be read from the centralized storage once, and then it’s in cache for the rest of the builds. We also have to remember that not the entire TIER2 image is read whenever data is read. If a build requests openssh.so, only those blocks containing the file are read. We also need the Compellent to provide us with redundancy for critical systems and a huge data storage for data that can’t be stored distributed. Critical systems include our own infrastructure and the storage is needed for all kinds of data including our release packages, install packages, distro ISO images etc. So even if we had a good mechanism to distribute the entire TIER1 and TIER2 load to the servers themselves, currently there is no need for it and the Compellent serves this need more than well right now. The new hardware infrastructure will include new switches and firewalls as well. And all these are being set up in new premises, so everything is new. With this we will expect a few maintenance breaks during the upcoming months where services are being handed over from one site to the other. The down times should be relatively low, since all data is being transferred beforehand and not during the down times. Software changes: Currently Coin is using VMware’s vSphere technology to create and run VMs. That’s about to change. Our new spinal cord will be based on OpenNebula (https://opennebula.org/). The swap to this new technology will come at the same time we switch to the new facility with the new hardware. We’ve been working hard to get the robustness and reliability up, matching or even exceeding the one provided by VMware’s products. With open source non-proprietary code we can go deep into the root causes of problems and fix drivers if that’s needed to make our VMs run smoothly without hick-ups. With OpenNebula being KVM based, we can expect new distro support to be available sooner as well. No longer do we need to fall back to saying a new macOS can’t be installed because VMware doesn’t support it. Let’s hope I can hold up to this promise or claim 😉 Performance wise the comparison between VMware and OpenNebula is a bit unfair since they use different underlying hardware, but we can say that builds aren’t going to get any slower by the looks of it. We’re also working on getting all of our distros more provision scripted. This will make it a lot easier for anyone ( yes, this includes you ) to upgrade the software that’s being run on the VMs. Anyone can access qt5.git/coin/provisioning and modify / add scripts there. Normal code review procedures apply and TIER2 images get updated. Internally we’ve had 3 different Jenkins instances in the past. We had one for CI that got replaced by Coin a year ago. The remaining two were for release package creation, Creator builds and few others, and the second one was for RTA standing for Release Test Automation where we verified the packages to really install something and examples working etc. Those two Jenkins instances are planned to be merged with Coin at some point in time, but for the time being they are going to stay there for a while. However, we’re improving the backend of how they receive their VMs. They currently compete with Coin in getting hardware resources. In the next weeks this is going to be changed so that Coin creates these VMs. This takes away the race conditions between two back ends, but also gives our Jenkins instances “support” for OpenNebula VMs. Even if this does not show up directly to you as CI users, it should show up with slightly more reliable VM dedication, more effective cleanup of VMs, and at least from the technical perspective we should be more capable of producing packages faster. I hope you found this interesting. If you have any questions feel free to ask in public or in private. I’ll be happy to answer if I can 😊 Have a great summer! -Tony Tony Sarajärvi CI Tech Lead -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Tue May 30 09:31:05 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 30 May 2017 07:31:05 +0000 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: References: Message-ID: > -----Original Message----- > From: Mitch Curtis > Sent: Monday, May 29, 2017 3:27 PM > To: Kai Koehne ; development at qt-project.org > Subject: RE: Please add [ChangeLog] entries to your commits! > > > [...] > > Please be reminded that all changes that might be of interest to the > > end user should be part of the ChangeLog. So please, whenever > > reviewing a change, please check whether a [ChangeLog] entry is in order. > > Do we have a set of guidelines for what is considered interesting? I'd say anything that changes observable behavior of existing features, or new features. Should get a [ChangeLog] - new features - fixes for bugs in released versions of Qt Can be ignored: - fixes in tests - doc fixes - pure code cleanup - fixes for regressions introduced in not-yet-released commits Regards Kai (who considers starting a QUIP about this ...) From edward.welbourne at qt.io Tue May 30 10:48:02 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 30 May 2017 08:48:02 +0000 Subject: [Development] Question on using multiple multicast receives on same channel in one program In-Reply-To: <1571519.cSGe9avGnr@tjmaciei-mobl1> References: , <1571519.cSGe9avGnr@tjmaciei-mobl1> Message-ID: On segunda-feira, 29 de maio de 2017 15:22:15 PDT wim delvaux wrote: > Therefore I tried to open multiple connections to that multicast > address/port but to no avail. What exactly did you try and in what sense did it fail ? Eddy. From wim.delvaux at adaptiveplanet.com Tue May 30 12:59:46 2017 From: wim.delvaux at adaptiveplanet.com (wim delvaux) Date: Tue, 30 May 2017 12:59:46 +0200 Subject: [Development] Question on using multiple multicast receives on same channel in one program In-Reply-To: References: <1571519.cSGe9avGnr@tjmaciei-mobl1> Message-ID: Well I created multiple QObjects, in each created a QUdpSocket and connected it to the same adress/port. I was hoping that all of the connected objects would receive all incoming data (multicast copies I thought) but it seems only one object gets the data. I was hoping to avoid creating my own dispatcher object layered between all of the QObjects and the multicast channel W On Tue, May 30, 2017 at 10:48 AM, Edward Welbourne wrote: > On segunda-feira, 29 de maio de 2017 15:22:15 PDT wim delvaux wrote: > > Therefore I tried to open multiple connections to that multicast > > address/port but to no avail. > > What exactly did you try and in what sense did it fail ? > > Eddy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue May 30 19:00:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 May 2017 10:00:00 -0700 Subject: [Development] Question on using multiple multicast receives on same channel in one program In-Reply-To: References: Message-ID: <1649468.UfrreGorst@tjmaciei-mobl1> On Tuesday, 30 May 2017 03:59:46 PDT wim delvaux wrote: > Well I created multiple QObjects, in each created a QUdpSocket and > connected it to the same adress/port. > > I was hoping that all of the connected objects would receive all incoming > data (multicast copies I thought) but it seems only one object gets the > data. When you called bind(), did all of them return true? Did you remember to allow reusing the port number? Pass the QUdpSocket::ShareAddress flag to bind(). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue May 30 19:25:31 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 May 2017 10:25:31 -0700 Subject: [Development] Periodical digest from the CI (2017/05) - CI Performance, HW and SW changes In-Reply-To: References: Message-ID: <7447131.tZ04N2LHWG@tjmaciei-mobl1> On Tuesday, 30 May 2017 00:15:15 PDT Tony Sarajärvi wrote: > I hope you found this interesting. Yes, a lot! Thanks for the write-up, Tony. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed May 31 12:11:26 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 31 May 2017 10:11:26 +0000 Subject: [Development] Qt 5.9.0 released Message-ID: Hi all, I am happy to announce Qt 5.9.0 is released today, see http://blog.qt.io/blog/2017/05/31/qt-5-9-released/ Big thanks everyone involved! Br, Jani Heikkinen Release Manager From mitch.curtis at qt.io Wed May 31 14:30:41 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 31 May 2017 12:30:41 +0000 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: References: Message-ID: > -----Original Message----- > From: Kai Koehne > Sent: Tuesday, 30 May 2017 9:31 AM > To: Mitch Curtis ; development at qt-project.org > Subject: RE: Please add [ChangeLog] entries to your commits! > > > > > -----Original Message----- > > From: Mitch Curtis > > Sent: Monday, May 29, 2017 3:27 PM > > To: Kai Koehne ; development at qt-project.org > > Subject: RE: Please add [ChangeLog] entries to your commits! > > > > > [...] > > > Please be reminded that all changes that might be of interest to the > > > end user should be part of the ChangeLog. So please, whenever > > > reviewing a change, please check whether a [ChangeLog] entry is in > order. > > > > Do we have a set of guidelines for what is considered interesting? > > I'd say anything that changes observable behavior of existing features, or > new features. > > Should get a [ChangeLog] > - new features > - fixes for bugs in released versions of Qt > > Can be ignored: > - fixes in tests > - doc fixes > - pure code cleanup > - fixes for regressions introduced in not-yet-released commits > > Regards > > Kai > > (who considers starting a QUIP about this ...) There's also this one: https://wiki.qt.io/Commit_Policy That doesn't mention anything about change log entries for non-critical bug fixes. From robin.burchell at crimson.no Wed May 31 14:38:53 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Wed, 31 May 2017 14:38:53 +0200 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: References: Message-ID: <1496234333.415121.994072744.318A2C16@webmail.messagingengine.com> My rule of thumb (when editing qtdeclarative's, for the last releases) has been to include things depending on the "size" of the release. Small (patch level) release? Include more bugs. Large (.0) release? Less focus on bugs, more focus on architectural changes, feature additions, etc. Any behavioral changes are always something that should be mentioned, of course. To me, it's implicit that each release will ideally have improvements in terms of stability, so I think that there's less point in focusing on them, unless they are a major newsworthy item: something like "sorry we released 1.0.0 yesterday, but it turns out that feature foo was totally broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed a crash that has existed for the past 3 years" - less so, but that's my own personal view. -- Robin Burchell robin at crimson.no On Wed, May 31, 2017, at 02:30 PM, Mitch Curtis wrote: > > -----Original Message----- > > From: Kai Koehne > > Sent: Tuesday, 30 May 2017 9:31 AM > > To: Mitch Curtis ; development at qt-project.org > > Subject: RE: Please add [ChangeLog] entries to your commits! > > > > > > > > > -----Original Message----- > > > From: Mitch Curtis > > > Sent: Monday, May 29, 2017 3:27 PM > > > To: Kai Koehne ; development at qt-project.org > > > Subject: RE: Please add [ChangeLog] entries to your commits! > > > > > > > [...] > > > > Please be reminded that all changes that might be of interest to the > > > > end user should be part of the ChangeLog. So please, whenever > > > > reviewing a change, please check whether a [ChangeLog] entry is in > > order. > > > > > > Do we have a set of guidelines for what is considered interesting? > > > > I'd say anything that changes observable behavior of existing features, or > > new features. > > > > Should get a [ChangeLog] > > - new features > > - fixes for bugs in released versions of Qt > > > > Can be ignored: > > - fixes in tests > > - doc fixes > > - pure code cleanup > > - fixes for regressions introduced in not-yet-released commits > > > > Regards > > > > Kai > > > > (who considers starting a QUIP about this ...) > > There's also this one: > > https://wiki.qt.io/Commit_Policy > > That doesn't mention anything about change log entries for non-critical > bug fixes. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Wed May 31 14:50:35 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 31 May 2017 14:50:35 +0200 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: <1496234333.415121.994072744.318A2C16@webmail.messagingengine.com> References: <1496234333.415121.994072744.318A2C16@webmail.messagingengine.com> Message-ID: <20170531125035.GM30138@troll08> On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote: > To me, it's implicit that each release will ideally have improvements in > terms of stability, so I think that there's less point in focusing on > them, unless they are a major newsworthy item: something like "sorry we > released 1.0.0 yesterday, but it turns out that feature foo was totally > broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed > a crash that has existed for the past 3 years" - less so, but that's my > own personal view. > the trolltech policy was to always add a changelog entry when there was a proper bug report. that seems reasonable, because there is (or at least was) somebody waiting for that fix. From robin.burchell at crimson.no Wed May 31 15:02:03 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Wed, 31 May 2017 15:02:03 +0200 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: <20170531125035.GM30138@troll08> References: <1496234333.415121.994072744.318A2C16@webmail.messagingengine.com> <20170531125035.GM30138@troll08> Message-ID: <1496235723.421252.994099496.6A8E3B71@webmail.messagingengine.com> On Wed, May 31, 2017, at 02:50 PM, Oswald Buddenhagen wrote: > On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote: > > To me, it's implicit that each release will ideally have improvements in > > terms of stability, so I think that there's less point in focusing on > > them, unless they are a major newsworthy item: something like "sorry we > > released 1.0.0 yesterday, but it turns out that feature foo was totally > > broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed > > a crash that has existed for the past 3 years" - less so, but that's my > > own personal view. > > > the trolltech policy was to always add a changelog entry when there was a > proper bug report. that seems reasonable, because there is (or at least > was) somebody waiting for that fix. Yes, however, if they are waiting for the fix, one would assume they are also subscribed to the bug tracker, and presumably watching the bug. They'll get a notification when the bug state changes (and a fix version is added). I should note that I'm not opposed to mentioning more stuff, I was just talking about my own editorial process when digging around after stuff missing changelog entries. -- Robin Burchell robin at crimson.no From mitch.curtis at qt.io Wed May 31 16:48:45 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 31 May 2017 14:48:45 +0000 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: <1496235723.421252.994099496.6A8E3B71@webmail.messagingengine.com> References: <1496234333.415121.994072744.318A2C16@webmail.messagingengine.com> <20170531125035.GM30138@troll08> <1496235723.421252.994099496.6A8E3B71@webmail.messagingengine.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Robin Burchell > Sent: Wednesday, 31 May 2017 3:02 PM > To: development at qt-project.org > Subject: Re: [Development] Please add [ChangeLog] entries to your commits! > > On Wed, May 31, 2017, at 02:50 PM, Oswald Buddenhagen wrote: > > On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote: > > > To me, it's implicit that each release will ideally have > > > improvements in terms of stability, so I think that there's less > > > point in focusing on them, unless they are a major newsworthy item: > > > something like "sorry we released 1.0.0 yesterday, but it turns out > > > that feature foo was totally broken, have 1.0.1 today to fix that" > > > would be newsworthy, but "we fixed a crash that has existed for the > > > past 3 years" - less so, but that's my own personal view. > > > > > the trolltech policy was to always add a changelog entry when there > > was a proper bug report. that seems reasonable, because there is (or > > at least > > was) somebody waiting for that fix. > > Yes, however, if they are waiting for the fix, one would assume they are > also subscribed to the bug tracker, and presumably watching the bug. > They'll get a notification when the bug state changes (and a fix version > is added). I should note that I'm not opposed to mentioning more stuff, I > was just talking about my own editorial process when digging around after > stuff missing changelog entries. It's hard to beat the automatic notifications that Jira has. Anyone who has a business interest in a bug should be watching it in Jira. I don't remember seeing ChangeLog entries for fixes for non-critical bugs, and I imagine it would be really hard to get people to do this, which is why I was suggesting (on #qt-labs, and I'm probably not the first) that it would be good to have a way to automatically add one based on the task number and the title of the bug report (either as a post commit hook or maybe some script that the changelog script calls to fetch the info from git log). For example, for https://bugreports.qt.io/browse/QTBUG-1000, it could be something like: [ChangeLog][QTBUG-1000] Fixed "QTableWidget Row Remove/Insert bug" The titles could of course be edited by the maintainer (either after the changelog has been generated, or they could be more conscientious about editing bad bug report titles), but for the most part the titles are fairly sane and wouldn't need changing. > -- > Robin Burchell > robin at crimson.no > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed May 31 18:04:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 May 2017 09:04:58 -0700 Subject: [Development] Please add [ChangeLog] entries to your commits! In-Reply-To: <20170531125035.GM30138@troll08> References: <1496234333.415121.994072744.318A2C16@webmail.messagingengine.com> <20170531125035.GM30138@troll08> Message-ID: <1821563.JWvIB7bDVP@tjmaciei-mobl1> On Wednesday, 31 May 2017 05:50:35 PDT Oswald Buddenhagen wrote: > On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote: > > To me, it's implicit that each release will ideally have improvements in > > terms of stability, so I think that there's less point in focusing on > > them, unless they are a major newsworthy item: something like "sorry we > > released 1.0.0 yesterday, but it turns out that feature foo was totally > > broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed > > a crash that has existed for the past 3 years" - less so, but that's my > > own personal view. > > the trolltech policy was to always add a changelog entry when there was a > proper bug report. that seems reasonable, because there is (or at least > was) somebody waiting for that fix. Which is why, as a maintainer, I did a quick git log --grep=Task-number and checked which bug fixes did not have a changelog entry but should have had (not all needed it). (I think there's a way to make git do the skipping, but I'd have to look at the manual) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuel.gaist at edeltech.ch Wed May 31 22:39:25 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Wed, 31 May 2017 22:39:25 +0200 Subject: [Development] Periodical digest from the CI (2017/05) - CI Performance, HW and SW changes In-Reply-To: References: Message-ID: <3F77663F-AD28-4FF8-8580-5B5FDAF2F9C7@edeltech.ch> > On 30 May 2017, at 09:15, Tony Sarajärvi wrote: > > Hi all! > > I was due to write you something about the CI. This time I’ll cover the topics performance as well as upcoming hardware and software changes. > > Performance: > > You have all noticed that the CI system is behaving poorly to what comes to the performance. Sometimes autotests take over 30 times longer to run compared to a normal situation. Now why is that? > > We actually have different kinds of bottlenecks. One is the bandwidth with which the virtual machines (VMs) store local data to their virtual hard drives. The servers on which our virtual machines run have no local hard drives. They instead store all their data on a centralized storage called the Compellent (https://en.wikipedia.org/wiki/Dell_Compellent). So when a VM wants to store data on its virtual hard drive, the host it runs on actually stores the data on the centralized storage. > > We have several generations of hardware installed, and they have different speeds on their SAN interface with which they are connected to the Compellent. As your build picks up a server, it can be a new rack server, or it can be an older generation Blade (https://en.wikipedia.org/wiki/Blade_server). Also, all the other VMs on these servers share the same bandwidth, so depending on what the other builds do, your SAN connection can be affected. Sadly, our test of prioritization these VMs, didn’t produce expected results and really didn’t much at all. > > These generations of hardware and type of hardware also affect the amount of other VMs the hardware can run simultaneously. We have Mac mini’s running our macOS builds. Those generally run 1 VM per physical Mac mini. Then we have old Blades that run around 4 VMs per Blade. The latest additions to our hardware pool are dual socket 20 core CPU server racks. Those run up to 26 VMs simultaneously. Running more on the same hardware reduces costs for us, but also increases the odds of one build affecting the next. > > Another bottleneck is the Compellent itself. The storage system has 120 + 10 spare hard drives spinning at 15K RPM. However great the IOPS performance is in that system, when we decide to start 200+ VMs in the CI, it goes down to its knees. And when it does that, all builds and autotest run are affected. You could think of this as you having 2 computers at home sharing the same spinning disk. > > Now that all is grim and morbid, let’s continue with the good news. > > Upcoming hardware changes: > > We’re replacing the current hardware stack with a completely new one. The parts have arrived and are being installed as I type right now. Not only did we acquire new hardware that is faster, but we also redesigned the building concepts so that they utilize the hardware differently. The new hardware can be easily expanded and we designed the system so, that we don’t produce bottlenecks even when expanding it. > > Before I go in to details, I need to explain a bit how the CI systems generally works. So heading off on a tangent here! When developer stages a commit in Gerrit (codereview.qt-project.org), the CI picks it (or multiple commits) up. The CI or Coin as the piece of software is figuratively called, generates work items based on the data received. If let’s say the commits was for QtDeclarative, Coin now produces work items for itself to handle that QtDeclarative build on top of circa 30 different target platforms. Each of these work items depend on QtBase to be built. So now Coin also creates these circa 30 work items for QtBase. As QtDeclarative is built on top of the current qt5.git’s QtBase, it means in normal situations that QtBase has already been built previously. These artifacts have been stored by Coin and can now be reused. So instead of rebuilding QtBase for QtDeclarative, Coin simply checks its storage and links the previous builds to the current one and promptly continues with building QtDeclarative. This is the major change in how we build Qt nowadays compared to old days with Jenkins where every build always rebuilt the entire stack up to its point. > > Continuing into more details. Whenever Coin starts to build something, it needs a VM for the task. We have “templates” in vSphere that represent different operating systems. They are virtual machines that have operating systems installed in them along with some basic things set up like user accounts and SSHD etc. Then they have been shut down ready to be used. Now when a build needs a VM, it clones a template VM and launches the clone. The clone is actually only a linked clone. This means that we don’t really clone anything, but only create a new virtual machine that links or points to the original one. Now, when the new clone is powered on, it _reads_ from the original template, but all changes are _written_ to its own file called the ‘delta image’. This way a new virtual machine only takes up space that’s equal to the amount of data it has written. > > Going back to the template again. I said that it only contained basic things like user accounts and SSHD. A build surely needs more than that. We need Visual Studios, MINGW, CMake, OpenSSH, XCodes, MySQL etc installed as well. Those things are ‘provisioned’. In qt5.git we have a folder structure under /coin/provisioning that contains scripts that install these things. As there is no point in running them every time for every VM, we create yet another set of templates that contain these pre-installed. We call these TIER2 images (or templates) vs TIER1 images being the vanilla distros containing only the basic things enabling us to even use them. > > TIER2 images work pretty much the same way as QtBase was a dependency for QtDeclarative. Each build we trigger checks the current configurations scripts from qt5.git and makes a SHA from the folder structure. This SHA is used in naming the TIER2 image. If the content we want to install has changed, we have to regenerate a new TIER2 image. This is called the provisioning and it’s triggered automatically if the requested TIER2 image doesn’t exist. > > Now, let’s go back on track and talk about the hardware changes. > > The new servers have local SSD drives that work as the storage for the VMs instead of a centralized storage. This removes the bottleneck of a SAN network and reduces latencies while at it. And while being SSD drives, they are faster by design to what the Compellent used to be with its rotating discs. We still have a Compellent, but this time it’s filled with SSD drives. While the VMs use local SSD drives on the hosts themselves to store data, reading is a more complicated thing. The TIER1 and TIER2 images described earlier are still stored centralized on the Compellent. This saves us the transferring of the images to each server serving as the host for the VMs. These TIER2 images are cloned as normal, and then the read operations point to the source. This would cause the same situation as with the old system where everything is read from the Compellent, but we are relying on caches to work in our favor here. The TIER2 images are shared via NFS, and the host OS on the server is equipped with a 500 GB NFS cache. So whenever something is read from the TIER2, it is in fact now read from the NFS cache that’s local. All this is obviously assuming that the data has been read once previously. In practice, if a TIER2 image gets updated, the data has to be read from the centralized storage once, and then it’s in cache for the rest of the builds. We also have to remember that not the entire TIER2 image is read whenever data is read. If a build requests openssh.so, only those blocks containing the file are read. > > We also need the Compellent to provide us with redundancy for critical systems and a huge data storage for data that can’t be stored distributed. Critical systems include our own infrastructure and the storage is needed for all kinds of data including our release packages, install packages, distro ISO images etc. So even if we had a good mechanism to distribute the entire TIER1 and TIER2 load to the servers themselves, currently there is no need for it and the Compellent serves this need more than well right now. > > The new hardware infrastructure will include new switches and firewalls as well. And all these are being set up in new premises, so everything is new. With this we will expect a few maintenance breaks during the upcoming months where services are being handed over from one site to the other. The down times should be relatively low, since all data is being transferred beforehand and not during the down times. > > Software changes: > > Currently Coin is using VMware’s vSphere technology to create and run VMs. That’s about to change. Our new spinal cord will be based on OpenNebula (https://opennebula.org/). The swap to this new technology will come at the same time we switch to the new facility with the new hardware. We’ve been working hard to get the robustness and reliability up, matching or even exceeding the one provided by VMware’s products. With open source non-proprietary code we can go deep into the root causes of problems and fix drivers if that’s needed to make our VMs run smoothly without hick-ups. With OpenNebula being KVM based, we can expect new distro support to be available sooner as well. No longer do we need to fall back to saying a new macOS can’t be installed because VMware doesn’t support it. Let’s hope I can hold up to this promise or claim 😉 > > Performance wise the comparison between VMware and OpenNebula is a bit unfair since they use different underlying hardware, but we can say that builds aren’t going to get any slower by the looks of it. > > We’re also working on getting all of our distros more provision scripted. This will make it a lot easier for anyone ( yes, this includes you ) to upgrade the software that’s being run on the VMs. Anyone can access qt5.git/coin/provisioning and modify / add scripts there. Normal code review procedures apply and TIER2 images get updated. > > Internally we’ve had 3 different Jenkins instances in the past. We had one for CI that got replaced by Coin a year ago. The remaining two were for release package creation, Creator builds and few others, and the second one was for RTA standing for Release Test Automation where we verified the packages to really install something and examples working etc. Those two Jenkins instances are planned to be merged with Coin at some point in time, but for the time being they are going to stay there for a while. However, we’re improving the backend of how they receive their VMs. They currently compete with Coin in getting hardware resources. In the next weeks this is going to be changed so that Coin creates these VMs. This takes away the race conditions between two back ends, but also gives our Jenkins instances “support” for OpenNebula VMs. Even if this does not show up directly to you as CI users, it should show up with slightly more reliable VM dedication, more effective cleanup of VMs, and at least from the technical perspective we should be more capable of producing packages faster. > > > I hope you found this interesting. If you have any questions feel free to ask in public or in private. I’ll be happy to answer if I can 😊 > > Have a great summer! > -Tony > > Tony Sarajärvi > CI Tech Lead > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, Thank you very much for the detailed post ! It’s pretty great to be able to understand what’s going on behind the "Merge Patch Set To Staging" button. Cheers Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: