From sh at theharmers.co.uk Thu Mar 1 10:11:15 2018 From: sh at theharmers.co.uk (Sean Harmer) Date: Thu, 1 Mar 2018 09:11:15 +0000 Subject: [Development] API breackage in Qt3D In-Reply-To: References: Message-ID: Animation and Extras are tech preview. The rest are stable. Cheers, Sean On 28/02/2018 16:40, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! today I was packaging Qt3D (meaning the the submodule) for Debian > and noticed that some symbols where missing. We understood that Qt3D > (the submodule) was API/ABI stable, but Konstantin Tokarev pointed > out: > > https://abi-laboratory.pro/tracker/timeline/qt/ "NOTE: The libQt53D* > objects are introduced in the library > since 5.5.0 but with no stable ABI guarantee, so analysis of these > objects was not performed." > > But then Thiago pointed out: > > well, we need to start having it stable > it's no longer in experimental state > $ git config -f .gitmodules --get submodule.qt3d.status > addon > qt3d left preview status in 5.7 > if there are libs inside that aren't stable ABI, they should > be moved to a separate module > > So bringing up the issue here. > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From jani.heikkinen at qt.io Thu Mar 1 12:10:01 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 1 Mar 2018 11:10:01 +0000 Subject: [Development] Qt 5.11 beta1 released In-Reply-To: References: Message-ID: Hi! We have released Qt 5.11 beta1 today, see http://blog.qt.io/blog/2018/03/01/qt-5-11-beta-released/ You can find Qt 5.11 beta1 under 'Preview' node from Online installer. Please take a tour & start testing Qt 5.11 now. As earlier we will release new beta releases regularly until we are ready for final Qt 5.11 release. It is really important to recognize all blockers for the final release as soon as possible so please make sure all release blockers can be found from RC blocker list (https://bugreports.qt.io/issues/?filter=19209). br Jani From perezmeyer at gmail.com Thu Mar 1 13:51:49 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Thu, 1 Mar 2018 09:51:49 -0300 Subject: [Development] API breackage in Qt3D In-Reply-To: References: Message-ID: El 1 mar. 2018 6:11 a.m., "Sean Harmer" escribió: Animation and Extras are tech preview. The rest are stable. Ok, so we have probably misunderstood that part. Just as an idea, would it be possible to tag tech preview symbols as we do for private ones? On one hand it would make their detection easier, on the other it might help as an incentive to not make them stable API... -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Thu Mar 1 13:56:19 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 1 Mar 2018 12:56:19 +0000 Subject: [Development] API breackage in Qt3D In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > Subject: Re: [Development] API breackage in Qt3D > > El 1 mar. 2018 6:11 a.m., "Sean Harmer" > escribió: > > > Animation and Extras are tech preview. The rest are stable. > > > Ok, so we have probably misunderstood that part. I also think this should be documented more explicitly: https://codereview.qt-project.org/#/c/216892/ Reviews are welcome 😊 Kai From jani.heikkinen at qt.io Thu Mar 1 14:07:12 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 1 Mar 2018 13:07:12 +0000 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' started Message-ID: Hi! We have soft branched '5.9.5' from '5.9'. Final downmerge from '5.9' to '5.9.5' will happen at the beginning of week 11 (most probably Monday 12.3.2018). Please start using '5.9.5' for new changes (cherry-picks from 5.11) targeted to Qt 5.9.5 release. And once again: No any 'nice to haves' in '5.9.5' anymore! We are targeting to release Qt 5.9.5 during March. br, Jani From thiago.macieira at intel.com Thu Mar 1 17:22:45 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 1 Mar 2018 08:22:45 -0800 Subject: [Development] API breackage in Qt3D In-Reply-To: References: Message-ID: <4635690.e52pPWTgiT@tjmaciei-mobl1> On Thursday, 1 March 2018 04:56:19 PST Kai Koehne wrote: > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > Subject: Re: [Development] API breackage in Qt3D > > > > El 1 mar. 2018 6:11 a.m., "Sean Harmer" > > escribió: > > > > > > > > Animation and Extras are tech preview. The rest are stable. > > > > > > > > Ok, so we have probably misunderstood that part. > > > I also think this should be documented more explicitly: > > https://codereview.qt-project.org/#/c/216892/ > > Reviews are welcome 😊 Please move them to another module until they're ready, or at least disable the building unless explicitly enabled. Debian wasn't the only one that packaged those libs and has symbol control enabled. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Corey.Pendleton at garmin.com Fri Mar 2 01:02:10 2018 From: Corey.Pendleton at garmin.com (Pendleton, Corey) Date: Fri, 2 Mar 2018 00:02:10 +0000 Subject: [Development] Unable to Push Message-ID: <5FFC5568D17E72418D3447AA09F49E690167F2BF31@olawpa-exmb01.ad.garmin.com> My apologies for the mass mail. I am attempting my first contribution. After following all the steps to set up Gerrit integration using https (for firewall) when I enter my credentials I get: $ git push gerrit-qt HEAD:refs/for/dev fatal: Authentication failed for 'https://CPendleton at codereview.qt-project.org/qt/qtbase.git/' Is there anyone who can help me get this configured properly? Thanks! Corey Pendleton Senior Software Engineer - Automotive OEM [auto-oem-signature] ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 8667 bytes Desc: image003.png URL: From thiago.macieira at intel.com Fri Mar 2 02:21:04 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 1 Mar 2018 17:21:04 -0800 Subject: [Development] Unable to Push In-Reply-To: <5FFC5568D17E72418D3447AA09F49E690167F2BF31@olawpa-exmb01.ad.garmin.com> References: <5FFC5568D17E72418D3447AA09F49E690167F2BF31@olawpa-exmb01.ad.garmin.com> Message-ID: <3902523.uEcBt0l3JN@tjmaciei-mobl1> On Thursday, 1 March 2018 16:02:10 PST Pendleton, Corey wrote: > My apologies for the mass mail. I am attempting my first contribution. > After following all the steps to set up Gerrit integration using https (for > firewall) when I enter my credentials I get: $ git push gerrit-qt > HEAD:refs/for/dev > fatal: Authentication failed for > 'https://CPendleton at codereview.qt-project.org/qt/qtbase.git/' > > Is there anyone who can help me get this configured properly? Please use SSH. You need to upload your SSH key to Gerrit (click Settings on the right). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aapo.keskimolo at qt.io Fri Mar 2 09:10:21 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Fri, 2 Mar 2018 08:10:21 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin will be restarted today to test two patches in production. Use http to download artifacts, source archives and provisioning scripts https://codereview.qt-project.org/#/c/205560/ Ystävällisin terveisin / Kind regards, Aapo Keskimölö | Software Engineer aapo.keskimolo at qt.io | +358 44 559 2378 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gauravjumrani123 at gmail.com Fri Mar 2 11:08:17 2018 From: gauravjumrani123 at gmail.com (gaurav jumrani) Date: Fri, 2 Mar 2018 15:38:17 +0530 Subject: [Development] introduction Message-ID: Hi developers, my name is gaurav jumrani. I am B.tech student from Rajasthan Technical university, kota(raj.).I know c++ and qt very well and want to contribute in bazel support task pls guide me how can i start and want to be a part of gsoc2018 as a student from your organization pls guide me ??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Mar 2 11:47:47 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 2 Mar 2018 10:47:47 +0000 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: <2098989.MG7ht681lK@tjmaciei-mobl1> References: , <2098989.MG7ht681lK@tjmaciei-mobl1> Message-ID: Thiago Macieira (27 February 2018 16:12) > Originally qrandom.cpp used getrandom(), which is in sys/random.h. Apparently > I forgot to remove the dependency when I switched to getentropy(). Alexei: please give https://codereview.qt-project.org/221913 a try, let me know if that (in place of the previous fix) works for you. Eddy. From edward.welbourne at qt.io Fri Mar 2 12:07:35 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 2 Mar 2018 11:07:35 +0000 Subject: [Development] introduction In-Reply-To: References: Message-ID: gaurav jumrani (2 March 2018 11:08) > my name is gaurav jumrani. I am B.tech student from Rajasthan > Technical university, kota(raj.).I know c++ and qt very well and want > to contribute in bazel support task pls guide me how can i start and > want to be a part of gsoc2018 as a student from your organization pls > guide me ??????????? Hi guarav. You'll get a fuller answer on IRC, the #qt-gsoc channel on the freenode server. See https://wiki.qt.io/Google_Summer_of_Code/2018 for an introduction and follow links from it for more details, including about IRC, Eddy. From perezmeyer at gmail.com Fri Mar 2 13:59:39 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Fri, 2 Mar 2018 09:59:39 -0300 Subject: [Development] API breackage in Qt3D In-Reply-To: <4635690.e52pPWTgiT@tjmaciei-mobl1> References: <4635690.e52pPWTgiT@tjmaciei-mobl1> Message-ID: On 1 March 2018 at 13:22, Thiago Macieira wrote: [snip] >> > Animation and Extras are tech preview. The rest are stable. [snip] > Please move them to another module until they're ready, or at least disable > the building unless explicitly enabled. > > Debian wasn't the only one that packaged those libs and has symbol control > enabled. Should I file a bug about this? -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ From Simon.Hausmann at qt.io Fri Mar 2 14:58:24 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 2 Mar 2018 13:58:24 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: , Message-ID: Hi, One more restart was needed, unfortunately. Simon ________________________________ From: Development on behalf of Aapo Keskimölö Sent: Friday, March 2, 2018 9:10:21 AM To: development at qt-project.org Subject: [Development] Coin maintenance notification Coin will be restarted today to test two patches in production. Use http to download artifacts, source archives and provisioning scripts https://codereview.qt-project.org/#/c/205560/ Ystävällisin terveisin / Kind regards, Aapo Keskimölö | Software Engineer aapo.keskimolo at qt.io | +358 44 559 2378 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ch.Ehrlicher at gmx.de Sat Mar 3 20:46:30 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sat, 3 Mar 2018 20:46:30 +0100 Subject: [Development] QVector rvalue overloads for convenience functions? Message-ID: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> Hi, recently rvalue overloads for QVector::append(T), push_back(T) and others were added to QVector. But not for the convenience functions like operator<<(T) or operator +=(T). Is this an oversight or by intention? Thx, Christian From mandeepsandhu.chd at gmail.com Sat Mar 3 21:11:18 2018 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Sat, 3 Mar 2018 12:11:18 -0800 Subject: [Development] QVector rvalue overloads for convenience functions? In-Reply-To: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> Message-ID: On Sat, Mar 3, 2018 at 11:46 AM, Christian Ehrlicher wrote: > Hi, > > recently rvalue overloads for QVector::append(T), push_back(T) and others > were added to QVector. But not for the convenience functions like > operator<<(T) or operator +=(T). Is this an oversight Why would an rvalue overload (by that I assume you mean move semantics) apply to the += operator? You're not discarding the existing object, just adding values from whats pointed to by the other reference. As for the << operator, it _might_ be an oversight, I'm not sure. Someone else can chime in. CMIIW. -mandeep > or by intention? > > > Thx, > Christian > _______________________________________________ > 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 Sat Mar 3 21:25:46 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 03 Mar 2018 21:25:46 +0100 Subject: [Development] QVector rvalue overloads for convenience functions? In-Reply-To: References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> Message-ID: <2306583.nmk4l4DFCy@twilight> On Samstag, 3. März 2018 21:11:18 CET Mandeep Sandhu wrote: > On Sat, Mar 3, 2018 at 11:46 AM, Christian Ehrlicher > > wrote: > > Hi, > > > > recently rvalue overloads for QVector::append(T), push_back(T) and others > > were added to QVector. But not for the convenience functions like > > operator<<(T) or operator +=(T). Is this an oversight > > Why would an rvalue overload (by that I assume you mean move semantics) > apply to the += operator? You're not discarding the existing object, just > adding values from whats pointed to by the other reference. > > As for the << operator, it _might_ be an oversight, I'm not sure. Someone > else can chime in. > Both of them could make sense assuming we are talking about the single value variants. I guess it is an oversight, feel free to add them. inline QVector &operator+=(T &&t) { append(std::move(t)); return *this; } inline QVector &operator<< (T &&t) { append(std::move(t)); return *this; } Note they might be missing from qvarlengtharray too. 'Allan From mandeepsandhu.chd at gmail.com Sat Mar 3 21:32:12 2018 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Sat, 3 Mar 2018 12:32:12 -0800 Subject: [Development] QVector rvalue overloads for convenience functions? In-Reply-To: <2306583.nmk4l4DFCy@twilight> References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> <2306583.nmk4l4DFCy@twilight> Message-ID: > > > inline QVector &operator+=(T &&t) > { append(std::move(t)); return *this; } > Ah, yes! This makes sense. inline QVector &operator<< (T &&t) > { append(std::move(t)); return *this; } > > Note they might be missing from qvarlengtharray too. > Thanks for the clarification. -mandeep > > 'Allan > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ch.Ehrlicher at gmx.de Sat Mar 3 21:38:12 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sat, 3 Mar 2018 21:38:12 +0100 Subject: [Development] QVector reserve counterproductive? Message-ID: <4b9e2af7-42fb-6a05-c7ca-5a3174efdcfd@gmx.de> Hi, while digging through the bugreports I found https://bugreports.qt.io/browse/QTBUG-66677 which seems to show a downside of QVector::reserve(). QPainterPath::addPolygon() is calling reserve() to make sure to have enough space for the new positions. This is exactly what I would have done and what e.g. CLazy suggests. But it looks like reserve() allocates *exactly* the amount of elements given. Therefore calling addPolygon() a second time will do a new reallocation and so on. The documentation for reserve() only states that memory for 'at least size elements' is allocated so my naive assumption would be that calling reserve a second time with a slightly bigger value than before does nothing. But this doesn't seem to be the case here. For the bug: removing the reserve() inside addPolygon() fixes the speed issues mentioned in the bug report. Don't know if the bug report is a valid use case though. Thx, Christian From Ch.Ehrlicher at gmx.de Sat Mar 3 21:47:36 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sat, 3 Mar 2018 21:47:36 +0100 Subject: [Development] QVector rvalue overloads for convenience functions? In-Reply-To: <2306583.nmk4l4DFCy@twilight> References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> <2306583.nmk4l4DFCy@twilight> Message-ID: <668e6596-4955-b911-e9e4-c1df06b0bb06@gmx.de> Am 03.03.2018 um 21:25 schrieb Allan Sandfeld Jensen: > On Samstag, 3. März 2018 21:11:18 CET Mandeep Sandhu wrote: >> On Sat, Mar 3, 2018 at 11:46 AM, Christian Ehrlicher >> >> wrote: >>> Hi, >>> >>> recently rvalue overloads for QVector::append(T), push_back(T) and others >>> were added to QVector. But not for the convenience functions like >>> operator<<(T) or operator +=(T). Is this an oversight >> Why would an rvalue overload (by that I assume you mean move semantics) >> apply to the += operator? You're not discarding the existing object, just >> adding values from whats pointed to by the other reference. >> >> As for the << operator, it _might_ be an oversight, I'm not sure. Someone >> else can chime in. >> > Both of them could make sense assuming we are talking about the single value > variants. I guess it is an oversight, feel free to add them. > > inline QVector &operator+=(T &&t) > { append(std::move(t)); return *this; } > inline QVector &operator<< (T &&t) > { append(std::move(t)); return *this; } > > Note they might be missing from qvarlengtharray too. QVarLengthArray does not have those convenience functions but it provides 'void append(T &&t) ' unconditionally in 5.11 ... Christian From sergio.martins at kdab.com Sat Mar 3 23:22:09 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?Martins=2C_S=C3=A9rgio?=) Date: Sat, 03 Mar 2018 22:22:09 +0000 Subject: [Development] QVector reserve counterproductive? In-Reply-To: <4b9e2af7-42fb-6a05-c7ca-5a3174efdcfd@gmx.de> References: <4b9e2af7-42fb-6a05-c7ca-5a3174efdcfd@gmx.de> Message-ID: <502c8728a4ecd291bb604fe17d302c7b@kdab.com> On 2018-03-03 20:38, Christian Ehrlicher wrote: > Hi, > > while digging through the bugreports I found > https://bugreports.qt.io/browse/QTBUG-66677 which seems to show a > downside of QVector::reserve(). Yes, reserve() shouldn't be called repeatedly inside loops. Instead use it only once, outside your outermost loop. > QPainterPath::addPolygon() is calling reserve() to make sure to have > enough space for the new positions. This is exactly what I would have > done and what e.g. CLazy suggests. Not really, see "Example where reserve shouldn't be used" in https://github.com/KDE/clazy/blob/master/src/checks/level2/README-reserve-candidates.md and also the pitfalls section where it talkes about using the growth strategy instead > But it looks like reserve() > allocates *exactly* the amount of elements given. Actually that qpainterpath code is off-by-one, it should be: d_func()->elements.reserve(d_func()->elements.size() + polygon.size() - 1); which also fixes the performance problem (by luck, in that specific benchmark). Please test. Ideas welcome on how we can catch more of these cases... 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 Ch.Ehrlicher at gmx.de Sun Mar 4 10:03:40 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sun, 4 Mar 2018 10:03:40 +0100 Subject: [Development] QVector reserve counterproductive? In-Reply-To: <502c8728a4ecd291bb604fe17d302c7b@kdab.com> References: <4b9e2af7-42fb-6a05-c7ca-5a3174efdcfd@gmx.de> <502c8728a4ecd291bb604fe17d302c7b@kdab.com> Message-ID: <10f8f724-6d52-8ad2-b03b-e94685f8d983@gmx.de> Am 03.03.2018 um 23:22 schrieb Martins, Sérgio: > On 2018-03-03 20:38, Christian Ehrlicher wrote: > >> But it looks like reserve() >> allocates *exactly* the amount of elements given. > > Actually that qpainterpath code is off-by-one, it should be: > d_func()->elements.reserve(d_func()->elements.size() + polygon.size() > - 1); > > which also fixes the performance problem (by luck, in that specific > benchmark). Please test. You're correct - this fixes the problem. Looks like the growth strategy is only applied when the current capacity == current size and not when the current capacity is slightly higher... good to know (and should maybe be documented?) Will create a patch for qpainterpath soon. Thx, Christian From Ch.Ehrlicher at gmx.de Sun Mar 4 14:20:21 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sun, 4 Mar 2018 14:20:21 +0100 Subject: [Development] QVector reserve counterproductive? In-Reply-To: <10f8f724-6d52-8ad2-b03b-e94685f8d983@gmx.de> References: <4b9e2af7-42fb-6a05-c7ca-5a3174efdcfd@gmx.de> <502c8728a4ecd291bb604fe17d302c7b@kdab.com> <10f8f724-6d52-8ad2-b03b-e94685f8d983@gmx.de> Message-ID: <605e5dde-422d-f0f3-6960-16d53441e187@gmx.de> Am 04.03.2018 um 10:03 schrieb Christian Ehrlicher: > Am 03.03.2018 um 23:22 schrieb Martins, Sérgio: >> On 2018-03-03 20:38, Christian Ehrlicher wrote: >> >>> But it looks like reserve() >>> allocates *exactly* the amount of elements given. >> >> Actually that qpainterpath code is off-by-one, it should be: >> d_func()->elements.reserve(d_func()->elements.size() + polygon.size() >> - 1); >> >> which also fixes the performance problem (by luck, in that specific >> benchmark). Please test. > You're correct - this fixes the problem. Looks like the growth > strategy is only applied when the current capacity == current size and > not when the current capacity is slightly higher... good to know (and > should maybe be documented?) The off-by-one idea was wrong. moveTo() will add another point to elements - therefore reserve(d_func()->elements.size() + polygon.size()) is correct. Maybe the best idea here would be to simply remove the reserve() calls and let QVector do what it is made for... :) Christian From sergio.martins at kdab.com Sun Mar 4 16:01:01 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?Martins=2C_S=C3=A9rgio?=) Date: Sun, 04 Mar 2018 15:01:01 +0000 Subject: [Development] QVector reserve counterproductive? In-Reply-To: <605e5dde-422d-f0f3-6960-16d53441e187@gmx.de> References: <4b9e2af7-42fb-6a05-c7ca-5a3174efdcfd@gmx.de> <502c8728a4ecd291bb604fe17d302c7b@kdab.com> <10f8f724-6d52-8ad2-b03b-e94685f8d983@gmx.de> <605e5dde-422d-f0f3-6960-16d53441e187@gmx.de> Message-ID: On 2018-03-04 13:20, Christian Ehrlicher wrote: > Am 04.03.2018 um 10:03 schrieb Christian Ehrlicher: >> Am 03.03.2018 um 23:22 schrieb Martins, Sérgio: >>> On 2018-03-03 20:38, Christian Ehrlicher wrote: >>> >>>> But it looks like reserve() >>>> allocates *exactly* the amount of elements given. >>> >>> Actually that qpainterpath code is off-by-one, it should be: >>> d_func()->elements.reserve(d_func()->elements.size() + polygon.size() >>> - 1); >>> >>> which also fixes the performance problem (by luck, in that specific >>> benchmark). Please test. >> You're correct - this fixes the problem. Looks like the growth >> strategy is only applied when the current capacity == current size and >> not when the current capacity is slightly higher... good to know (and >> should maybe be documented?) > The off-by-one idea was wrong. moveTo() will add another point to > elements - therefore reserve(d_func()->elements.size() + > polygon.size()) is correct. > Maybe the best idea here would be to simply remove the reserve() calls > and let QVector do what it is made for... :) If you're sure you're not pessimizing any other case, then removing reserve() is fine. But maybe there's a third option: vec.reserve(qMax(needed, what_the_capacity_would_have_been_without_reserve)) this way it's good for short containers, as growth is bootstrapped and also good for big containers as reserving becomes a no-op, as there's already capacity. 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 alexander.blasche at qt.io Mon Mar 5 08:07:15 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 5 Mar 2018 07:07:15 +0000 Subject: [Development] Nominating Kari Oikarinen for Approver Status In-Reply-To: References: Message-ID: Congratulations to Kari, All rights have been set. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Rainer Keller > Sent: Friday, 9 February 2018 14:19 > To: development at qt-project.org > Subject: [Development] Nominating Kari Oikarinen for Approver Status > > Hello everybody, > > I'd like to nominate Kari Oikarinen for approver status in the Qt Project. > > Kari has been contributing to Qt for Device Creation, COIN and several other > parts of the Qt project. He also is the maintainer of the Qt Debug Bridge. His > track record can be found under: > > https://codereview.qt-project.org/#q,owner:kari.oikarinen,n,z > https://codereview.qt-project.org/#q,reviewer:kari.oikarinen,n,z > > With regards, > Rainer > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Mon Mar 5 10:00:35 2018 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 5 Mar 2018 10:00:35 +0100 Subject: [Development] QVector rvalue overloads for convenience functions? In-Reply-To: <2306583.nmk4l4DFCy@twilight> References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> <2306583.nmk4l4DFCy@twilight> Message-ID: <294a36ab-e621-bc1a-c404-4516e408227a@familiesomers.nl> On 03/03/2018 21:25, Allan Sandfeld Jensen wrote: > On Samstag, 3. März 2018 21:11:18 CET Mandeep Sandhu wrote: >> On Sat, Mar 3, 2018 at 11:46 AM, Christian Ehrlicher >> >> wrote: >>> Hi, >>> >>> recently rvalue overloads for QVector::append(T), push_back(T) and others >>> were added to QVector. But not for the convenience functions like >>> operator<<(T) or operator +=(T). Is this an oversight >> Why would an rvalue overload (by that I assume you mean move semantics) >> apply to the += operator? You're not discarding the existing object, just >> adding values from whats pointed to by the other reference. >> >> As for the << operator, it _might_ be an oversight, I'm not sure. Someone >> else can chime in. >> > Both of them could make sense assuming we are talking about the single value > variants. Just wondering: why limit this to single value variants? I'd think that it would be equally useful for the variants taking a container? André From kde at carewolf.com Mon Mar 5 18:59:50 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 05 Mar 2018 18:59:50 +0100 Subject: [Development] QVector rvalue overloads for convenience functions? In-Reply-To: <294a36ab-e621-bc1a-c404-4516e408227a@familiesomers.nl> References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> <2306583.nmk4l4DFCy@twilight> <294a36ab-e621-bc1a-c404-4516e408227a@familiesomers.nl> Message-ID: <2197467.ScODbl2zfM@twilight> On Montag, 5. März 2018 10:00:35 CET André Somers wrote: > On 03/03/2018 21:25, Allan Sandfeld Jensen wrote: > > On Samstag, 3. März 2018 21:11:18 CET Mandeep Sandhu wrote: > >> On Sat, Mar 3, 2018 at 11:46 AM, Christian Ehrlicher > >> > >> > >> wrote: > >>> Hi, > >>> > >>> recently rvalue overloads for QVector::append(T), push_back(T) and > >>> others > >>> were added to QVector. But not for the convenience functions like > >>> operator<<(T) or operator +=(T). Is this an oversight > >> > >> Why would an rvalue overload (by that I assume you mean move semantics) > >> apply to the += operator? You're not discarding the existing object, just > >> adding values from whats pointed to by the other reference. > >> > >> As for the << operator, it _might_ be an oversight, I'm not sure. Someone > >> else can chime in. > > > > Both of them could make sense assuming we are talking about the single > > value variants. > > Just wondering: why limit this to single value variants? I'd think that > it would be equally useful for the variants taking a container? > While it is possible for it to be usefull, you first need to write the rvalue- append for that, and due to how the Qt containers are designed they may be implicitly shared in which case it rvalue append won't be able to avoid copying instead of moving. The same design also kind of encourages using Qt containers in ways where the ref-count will be higher than 1 and thus moving is not possible/meaningful. ' Allan From kevin.kofler at chello.at Tue Mar 6 01:42:39 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Mar 2018 01:42:39 +0100 Subject: [Development] QVector rvalue overloads for convenience functions? References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> <2306583.nmk4l4DFCy@twilight> <294a36ab-e621-bc1a-c404-4516e408227a@familiesomers.nl> <2197467.ScODbl2zfM@twilight> Message-ID: Allan Sandfeld Jensen wrote: > While it is possible for it to be usefull, you first need to write the > rvalue- append for that, and due to how the Qt containers are designed > they may be implicitly shared in which case it rvalue append won't be able > to avoid copying instead of moving. The same design also kind of > encourages using Qt containers in ways where the ref-count will be higher > than 1 and thus moving is not possible/meaningful. I would also like to point out that the actual gain of having an append(QVector &&) over the current append(const QVector &) would be very limited. At best you would save a pair of atomic integer operations. All this complexity of rvalue references and std::move in C++11 and newer is only necessary because the STL containers are not implicitly shared. Kevin Kofler From aapo.keskimolo at qt.io Tue Mar 6 09:15:16 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Tue, 6 Mar 2018 08:15:16 +0000 Subject: [Development] Coin maintenance notification Message-ID: <8141354D-AAC1-42A5-9673-0A6353AD66C3@qt.io> Coin will be taken down to fix storage where some binary artifacts are missing. We will also update production at the same time with new baseline. The expected downtime should be less than an hour. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From giuseppe.dangelo at kdab.com Tue Mar 6 10:05:39 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 6 Mar 2018 10:05:39 +0100 Subject: [Development] QVector rvalue overloads for convenience functions? In-Reply-To: References: <374a5af5-37e1-c075-64b3-06e1f53113de@gmx.de> <2306583.nmk4l4DFCy@twilight> <294a36ab-e621-bc1a-c404-4516e408227a@familiesomers.nl> <2197467.ScODbl2zfM@twilight> Message-ID: Il 06/03/2018 01:42, Kevin Kofler ha scritto: > I would also like to point out that the actual gain of having an > append(QVector &&) over the current append(const QVector &) would be > very limited. At best you would save a pair of atomic integer operations. No, because the former would move all elements. template void QVector::append(const QVector &v) { reserve(size() + v.size()); std::copy(v.begin(), v.end(), std::back_inserter(this)); } template void QVector::append(QVector &&v) { reserve(size() + v.size()); std::move(v.begin(), v.end(), std::back_inserter(this)); } > All this complexity of rvalue references and std::move in C++11 and newer is > only necessary because the STL containers are not implicitly shared. Not at all, you may want to exactly the same for std::vector. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The 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 aapo.keskimolo at qt.io Tue Mar 6 10:58:51 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Tue, 6 Mar 2018 09:58:51 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: <8141354D-AAC1-42A5-9673-0A6353AD66C3@qt.io> References: <8141354D-AAC1-42A5-9673-0A6353AD66C3@qt.io> Message-ID: Coin update has finished and the service is back up. Kind regards/Ystävällisin terveisin, Aapo Keskimölö > On 6 Mar 2018, at 10.15, Aapo Keskimölö wrote: > > Coin will be taken down to fix storage where some binary artifacts are missing. > > We will also update production at the same time with new baseline. > > The expected downtime should be less than an hour. > > > Kind regards/Ystävällisin terveisin, > Aapo Keskimölö From mitch.curtis at qt.io Tue Mar 6 11:04:33 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 6 Mar 2018 10:04:33 +0000 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable Message-ID: https://codereview.qt-project.org/#/c/221758/ makes QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that they can be used from QML. I think that this could be useful to debug issues, but being such a widely used and important class, I'm a bit unsure about whether it's worth the extra overhead. Here's what Olivier has to say about the overhead (taken from the review comments): "The overhead here is that QObject, which is the base class of all objects, gets two more methods. (out of the 4 it has currently.) This means that QMetaObject::invoke might be slightly slower if it does not find the method. (But since it is currently not really optimized right now, i don't think we should care about this.) I don't know what that means for QML lookups, but probably does not matter." So, I'm wondering what others think. Would you use these from QML? Would these be better off as a helper function in the Qt singleton? E.g. Qt.dumpObjectTree(object) and Qt.dumpObjectInfo(object). From andre at familiesomers.nl Tue Mar 6 11:12:24 2018 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Tue, 6 Mar 2018 11:12:24 +0100 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable In-Reply-To: References: Message-ID: <86494243-261d-6e80-9861-f7c4bf58c226@familiesomers.nl> On 06/03/2018 11:04, Mitch Curtis wrote: > https://codereview.qt-project.org/#/c/221758/ makes QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that they can be used from QML. I think that this could be useful to debug issues, but being such a widely used and important class, I'm a bit unsure about whether it's worth the extra overhead. Here's what Olivier has to say about the overhead (taken from the review comments): > > "The overhead here is that QObject, which is the base class of all objects, gets two more methods. (out of the 4 it has currently.) This means that QMetaObject::invoke might be slightly slower if it does not find the method. (But since it is currently not really optimized right now, i don't think we should care about this.) I don't know what that means for QML lookups, but probably does not matter." > > So, I'm wondering what others think. > > Would you use these from QML? > > Would these be better off as a helper function in the Qt singleton? E.g. Qt.dumpObjectTree(object) and Qt.dumpObjectInfo(object). > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development To be honest: no, I would probably never use them from QML. Nor do I use often from C++ either. I usually resort to external tooling such as GammaRay that give me all these methods can give me and much, much more. André From py.siret at gmail.com Tue Mar 6 11:29:17 2018 From: py.siret at gmail.com (Pierre-Yves Siret) Date: Tue, 6 Mar 2018 11:29:17 +0100 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable In-Reply-To: <86494243-261d-6e80-9861-f7c4bf58c226@familiesomers.nl> References: <86494243-261d-6e80-9861-f7c4bf58c226@familiesomers.nl> Message-ID: 2018-03-06 11:12 GMT+01:00 André Somers : > > > On 06/03/2018 11:04, Mitch Curtis wrote: > >> https://codereview.qt-project.org/#/c/221758/ makes >> QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that >> they can be used from QML. I think that this could be useful to debug >> issues, but being such a widely used and important class, I'm a bit unsure >> about whether it's worth the extra overhead. Here's what Olivier has to say >> about the overhead (taken from the review comments): >> >> "The overhead here is that QObject, which is the base class of all >> objects, gets two more methods. (out of the 4 it has currently.) This means >> that QMetaObject::invoke might be slightly slower if it does not find the >> method. (But since it is currently not really optimized right now, i don't >> think we should care about this.) I don't know what that means for QML >> lookups, but probably does not matter." >> >> So, I'm wondering what others think. >> >> Would you use these from QML? >> >> Would these be better off as a helper function in the Qt singleton? E.g. >> Qt.dumpObjectTree(object) and Qt.dumpObjectInfo(object). >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > To be honest: no, I would probably never use them from QML. Nor do I use > often from C++ either. I usually resort to external tooling such as > GammaRay that give me all these methods can give me and much, much more. > > André > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > I won't either, I just tried it and it gave me too low-level information that I can't really exploit afterwards. I don't see a usecase where that'll help me, maybe you do? I prefer my low-tech solution of recursively iterating the children or resources lists from QML or like André said, external tooling like GammaRay. A helper function seems like a good compromise if it's needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Tue Mar 6 11:50:14 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 6 Mar 2018 10:50:14 +0000 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable In-Reply-To: References: <86494243-261d-6e80-9861-f7c4bf58c226@familiesomers.nl> Message-ID: From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Pierre-Yves Siret Sent: Tuesday, 6 March 2018 11:29 AM To: André Somers Cc: Qt development mailing list Subject: Re: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable 2018-03-06 11:12 GMT+01:00 André Somers >: On 06/03/2018 11:04, Mitch Curtis wrote: https://codereview.qt-project.org/#/c/221758/ makes QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that they can be used from QML. I think that this could be useful to debug issues, but being such a widely used and important class, I'm a bit unsure about whether it's worth the extra overhead. Here's what Olivier has to say about the overhead (taken from the review comments): "The overhead here is that QObject, which is the base class of all objects, gets two more methods. (out of the 4 it has currently.) This means that QMetaObject::invoke might be slightly slower if it does not find the method. (But since it is currently not really optimized right now, i don't think we should care about this.) I don't know what that means for QML lookups, but probably does not matter." So, I'm wondering what others think. Would you use these from QML? Would these be better off as a helper function in the Qt singleton? E.g. Qt.dumpObjectTree(object) and Qt.dumpObjectInfo(object). _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development To be honest: no, I would probably never use them from QML. Nor do I use often from C++ either. I usually resort to external tooling such as GammaRay that give me all these methods can give me and much, much more. André _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development I won't either, I just tried it and it gave me too low-level information that I can't really exploit afterwards. I don't see a usecase where that'll help me, maybe you do? I prefer my low-tech solution of recursively iterating the children or resources lists from QML or like André said, external tooling like GammaRay. A helper function seems like a good compromise if it's needed. Thanks for the feedback guys. With regards to it giving too low-level information, I’m not sure what you mean. The idea is to be able to see the children of an object/item, so output matching that description would be on exactly the right level. :) It seems to give more information than recursively iterating the children from QML: import QtQuick 2.7 import QtQuick.Controls 2.3 ApplicationWindow { visible: true width: 640 height: 480 function printTree(item, indent) { if (indent === undefined) indent = 0 else ++indent if (indent === 0) print(item) for (var childIndex = 0; childIndex < item.children.length; ++childIndex) { var pad = "" for (var i = 0; i < indent; ++i) pad += " " print(pad, item.children[childIndex]) printTree(item.children[childIndex], indent) } } StackView { id: stackView initialItem: Button { Image {} } Component.onCompleted: { stackView.dumpObjectTree() printTree(stackView) } } } Output from dumpObjectTree(): QQuickStackView:: QQuickTransition:: QQuickTransition:: QQuickTransition:: QQuickTransition:: QQuickTransition:: QQuickTransition:: QQuickButton:: QQuickImage:: QQuickRectangle:: QQmlComponentAttached:: Output from printTree(): qml: QQuickStackView(0x25e95f08020) qml: QQuickButton(0x25e95f09100) qml: QQuickImage(0x25e95f08890) qml: QQuickRectangle(0x25e95f091f0) The idea is not necessarily to print the QObjects, but since there was already a function that printed everything (dumpObjectInfo()), I figure it would be simple enough to expose it to QML. Shawn has a similar patch that is aimed at items: https://codereview.qt-project.org/#/c/193285/ The use case that led me to push the patch was a focus issue, if I remember correctly. An unnamed (no objectName) item had focus, and I couldn’t see where it came from. I’m starting to lean towards a singleton helper for this, if we went ahead with it at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From py.siret at gmail.com Tue Mar 6 12:00:31 2018 From: py.siret at gmail.com (Pierre-Yves Siret) Date: Tue, 6 Mar 2018 12:00:31 +0100 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable In-Reply-To: References: <86494243-261d-6e80-9861-f7c4bf58c226@familiesomers.nl> Message-ID: 2018-03-06 11:50 GMT+01:00 Mitch Curtis : > *From:* Development [mailto:development-bounces+mitch.curtis= > qt.io at qt-project.org] *On Behalf Of *Pierre-Yves Siret > *Sent:* Tuesday, 6 March 2018 11:29 AM > *To:* André Somers > *Cc:* Qt development mailing list > *Subject:* Re: [Development] Making QObject::dumpObjectTree() and > QObject::dumpObjectInfo() invokable > > > > > > > > 2018-03-06 11:12 GMT+01:00 André Somers : > > > > On 06/03/2018 11:04, Mitch Curtis wrote: > > https://codereview.qt-project.org/#/c/221758/ makes > QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that > they can be used from QML. I think that this could be useful to debug > issues, but being such a widely used and important class, I'm a bit unsure > about whether it's worth the extra overhead. Here's what Olivier has to say > about the overhead (taken from the review comments): > > "The overhead here is that QObject, which is the base class of all > objects, gets two more methods. (out of the 4 it has currently.) This means > that QMetaObject::invoke might be slightly slower if it does not find the > method. (But since it is currently not really optimized right now, i don't > think we should care about this.) I don't know what that means for QML > lookups, but probably does not matter." > > So, I'm wondering what others think. > > Would you use these from QML? > > Would these be better off as a helper function in the Qt singleton? E.g. > Qt.dumpObjectTree(object) and Qt.dumpObjectInfo(object). > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > To be honest: no, I would probably never use them from QML. Nor do I use > often from C++ either. I usually resort to external tooling such as > GammaRay that give me all these methods can give me and much, much more. > > André > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > I won't either, I just tried it and it gave me too low-level information > that I can't really exploit afterwards. I don't see a usecase where that'll > help me, maybe you do? > > > > I prefer my low-tech solution of recursively iterating the children or > resources lists from QML or like André said, external tooling like GammaRay. > > > > A helper function seems like a good compromise if it's needed. > > > > Thanks for the feedback guys. > > > > With regards to it giving too low-level information, I’m not sure what you > mean. The idea is to be able to see the children of an object/item, so > output matching that description would be on exactly the right level. :) > > > > It seems to give more information than recursively iterating the children > from QML: > > > That's what I meant, I generally don't want all the QObject tree, the Item tree is enough most of the time. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Tue Mar 6 15:06:25 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Mar 2018 15:06:25 +0100 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable References: Message-ID: Mitch Curtis wrote: > https://codereview.qt-project.org/#/c/221758/ makes > QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that > they can be used from QML. Would this have any security impact? I'm thinking of issues like ASLR bypass or other information leakage, if these end up being invokable from untrusted scripts. Or is all the information contained there already available to QML? Kevin Kofler From alexei.fedotov at gmail.com Tue Mar 6 16:04:52 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 6 Mar 2018 18:04:52 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: <2098989.MG7ht681lK@tjmaciei-mobl1> Message-ID: Hi Edward, After I learned that configure needs -recheck and cleaned the workspace, I cannot build Qt that far to check the fix. I get the problem with QAtomicOpsSupport with the last branch and some other problems with different branches "is not a class template template<> struct QAtomicOpsSupport<2> { enum { IsSupported = 1 }; };" Trying to figure out what to do. Any advice is appreciated. -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Fri, Mar 2, 2018 at 1:47 PM, Edward Welbourne wrote: > Thiago Macieira (27 February 2018 16:12) >> Originally qrandom.cpp used getrandom(), which is in sys/random.h. Apparently >> I forgot to remove the dependency when I switched to getentropy(). > > Alexei: please give > https://codereview.qt-project.org/221913 > a try, let me know if that (in place of the previous fix) works for you. > > Eddy. From thiago.macieira at intel.com Tue Mar 6 16:29:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Mar 2018 07:29:50 -0800 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: Message-ID: <4942212.GksEE0fiAM@tjmaciei-mobl1> On Tuesday, 6 March 2018 07:04:52 PST Alexei Fedotov wrote: > Hi Edward, > After I learned that configure needs -recheck and cleaned the > workspace, I cannot build Qt that > far to check the fix. I get the problem with QAtomicOpsSupport with > the last branch and some other problems with different branches > "is not a class template > template<> struct QAtomicOpsSupport<2> { enum { IsSupported = 1 }; };" > > Trying to figure out what to do. Any advice is appreciated. Start by pasting the exact error message. File name, line number and compiler command-line help too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexei.fedotov at gmail.com Tue Mar 6 16:42:59 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 6 Mar 2018 18:42:59 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: <4942212.GksEE0fiAM@tjmaciei-mobl1> References: <4942212.GksEE0fiAM@tjmaciei-mobl1> Message-ID: Thiago, here is a required info 1) the command line extracted from the log which reproduces the error, D:/compilers/gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -c -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mthumb -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mthumb -mfloat-abi=hard --sysroot=D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihf -g -Og -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -Wno-error=implicit-fallthrough -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DPCRE2_CODE_UNIT_WIDTH=16 -Wall -Wextra -Werror -Woverloaded-virtual -Wshadow -Wundef -Wfloat-equal -Wnon-virtual-dtor -Wpointer-arith -Wformat-security -Wno-long-long -Wno-variadic-macros -pedantic-errors -Wchar-subscripts -Wold-style-cast -Wdouble-promotion -Wfloat-conversion -Wzero-as-null-pointer-constant -I. -I../3rdparty/zlib/src -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty/double-conversion/include -I../3rdparty/double-conversion/include/double-conversion -I../3rdparty/forkfd -I../../include -I../../include/QtCore -I../../include/QtCore/5.10.1 -I../../include/QtCore/5.10.1/QtCore -I.moc -I../3rdparty/pcre2/src -I../../mkspecs/devices/linux-beagleboard-g++ -DQT_NO_CAST_TO_ASCII=1 -DQT_NO_CAST_FROM_ASCII=1 -UQT_RESTRICTED_CAST_FROM_ASCII -DQT_STRICT_ITERATORS -DQT_NO_URL_CAST_FROM_STRING=1 -DQT_NO_CAST_FROM_BYTEARRAY=1 -DQT_NO_KEYWORDS=1 -DQT_USE_QSTRINGBUILDER -DQT_USE_FAST_OPERATOR_PLUS -Dsignals=int -Dslots=int -Demit=public: -Dforeach=public: -Dforever=public: -xc++ arch/qatomic_bootstrap.h -o .obj/header_qatomic_bootstrap.obj In file included from ../../include/QtCore/qatomic_cxx11.h:1:0, from ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:53, from ../../include/QtCore/qbasicatomic.h:1, from ../../include/QtCore/../../src/corelib/thread/qatomic.h:46, from ../../include/QtCore/qatomic.h:1, from ../../include/QtCore/../../src/corelib/global/qglobal.h:1185, from ../../include/QtCore/qglobal.h:1, from ../../include/QtCore/../../src/corelib/thread/qgenericatomic.h:44, from ../../include/QtCore/qgenericatomic.h:1, from arch/qatomic_bootstrap.h:44: ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:19: error: 'QAtomicOpsSupport' is not a class template template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; ^~~~~~~~~~~~~~~~~ ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:40: error: explicit specialization of non-template 'QAtomicOpsSupport' template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; 2) here is the first error message (I get the same for other <2> later as well) In file included from ../../include/QtCore/qatomic_cxx11.h:1:0, from ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:53, from ../../include/QtCore/qbasicatomic.h:1, from ../../include/QtCore/../../src/corelib/thread/qatomic.h:46, from ../../include/QtCore/qatomic.h:1, from ../../include/QtCore/../../src/corelib/global/qglobal.h:1185, from ../../include/QtCore/qglobal.h:1, from ../../include/QtCore/../../src/corelib/thread/qgenericatomic.h:44, from ../../include/QtCore/qgenericatomic.h:1, from arch/qatomic_bootstrap.h:44: ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:19: error: 'QAtomicOpsSupport' is not a class template template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; ^~~~~~~~~~~~~~~~~ ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:40: error: explicit specialization of non-template 'QAtomicOpsSupport' template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; 3) here is the compiler version, D:/compilers/gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -v Using built-in specs. COLLECT_GCC=D:\compilers\gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf\bin\arm-linux-gnueabihf-g++.exe COLLECT_LTO_WRAPPER=d:/compilers/gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/7.1.1/lto-wrapper.exe Target: arm-linux-gnueabihf Configured with: '/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/snapshots/gcc.git~linaro-7.1-2017.08/configure' SHELL=/bin/bash --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared --without-included-gettext --enable-nls --disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id --disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu --enable-libstdcxx-debug --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no --disable-multilib --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb --with-tune=cortex-a9 --with-arch=armv7-a --enable-threads=posix --enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/sysroots/arm-linux-gnueabihf --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32/arm-linux-gnueabihf/libc --enable-checking=release --disable-bootstrap --enable-languages=c,c++,fortran,lto --with-libiconv-prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32/usr --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 --target=arm-linux-gnueabihf --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 Thread model: posix gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08) Thanks for your help! -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Tue, Mar 6, 2018 at 6:29 PM, Thiago Macieira wrote: > On Tuesday, 6 March 2018 07:04:52 PST Alexei Fedotov wrote: >> Hi Edward, >> After I learned that configure needs -recheck and cleaned the >> workspace, I cannot build Qt that >> far to check the fix. I get the problem with QAtomicOpsSupport with >> the last branch and some other problems with different branches >> "is not a class template >> template<> struct QAtomicOpsSupport<2> { enum { IsSupported = 1 }; };" >> >> Trying to figure out what to do. Any advice is appreciated. > > Start by pasting the exact error message. File name, line number and compiler > command-line help 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 From alexei.fedotov at gmail.com Tue Mar 6 16:45:11 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 6 Mar 2018 18:45:11 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: <4942212.GksEE0fiAM@tjmaciei-mobl1> Message-ID: (I posted the error message one extra time) -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Tue, Mar 6, 2018 at 6:42 PM, Alexei Fedotov wrote: > Thiago, here is a required info > > 1) the command line extracted from the log which reproduces the error, > > D:/compilers/gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ > -c -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mthumb -march=armv7-a > -mtune=cortex-a8 -mfpu=neon -mthumb -mfloat-abi=hard > --sysroot=D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihf > -g -Og -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden > -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond > -Wno-stringop-overflow -Werror -Wno-error=cpp > -Wno-error=deprecated-declarations -Wno-error=strict-overflow > -Wno-error=implicit-fallthrough -D_REENTRANT -fPIC > -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH > -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB > -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS > -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS > -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -D_LARGEFILE64_SOURCE > -D_LARGEFILE_SOURCE -DPCRE2_CODE_UNIT_WIDTH=16 -Wall -Wextra -Werror > -Woverloaded-virtual -Wshadow -Wundef -Wfloat-equal -Wnon-virtual-dtor > -Wpointer-arith -Wformat-security -Wno-long-long -Wno-variadic-macros > -pedantic-errors -Wchar-subscripts -Wold-style-cast -Wdouble-promotion > -Wfloat-conversion -Wzero-as-null-pointer-constant -I. > -I../3rdparty/zlib/src -Iglobal -I../3rdparty/harfbuzz/src > -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 > -I../3rdparty/double-conversion/include > -I../3rdparty/double-conversion/include/double-conversion > -I../3rdparty/forkfd -I../../include -I../../include/QtCore > -I../../include/QtCore/5.10.1 -I../../include/QtCore/5.10.1/QtCore > -I.moc -I../3rdparty/pcre2/src > -I../../mkspecs/devices/linux-beagleboard-g++ -DQT_NO_CAST_TO_ASCII=1 > -DQT_NO_CAST_FROM_ASCII=1 -UQT_RESTRICTED_CAST_FROM_ASCII > -DQT_STRICT_ITERATORS -DQT_NO_URL_CAST_FROM_STRING=1 > -DQT_NO_CAST_FROM_BYTEARRAY=1 -DQT_NO_KEYWORDS=1 > -DQT_USE_QSTRINGBUILDER -DQT_USE_FAST_OPERATOR_PLUS -Dsignals=int > -Dslots=int -Demit=public: -Dforeach=public: -Dforever=public: -xc++ > arch/qatomic_bootstrap.h -o .obj/header_qatomic_bootstrap.obj > > In file included from ../../include/QtCore/qatomic_cxx11.h:1:0, > from > ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:53, > from ../../include/QtCore/qbasicatomic.h:1, > from > ../../include/QtCore/../../src/corelib/thread/qatomic.h:46, > from ../../include/QtCore/qatomic.h:1, > from > ../../include/QtCore/../../src/corelib/global/qglobal.h:1185, > from ../../include/QtCore/qglobal.h:1, > from > ../../include/QtCore/../../src/corelib/thread/qgenericatomic.h:44, > from ../../include/QtCore/qgenericatomic.h:1, > from arch/qatomic_bootstrap.h:44: > ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:19: > error: 'QAtomicOpsSupport' is not a class template > template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; > ^~~~~~~~~~~~~~~~~ > ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:40: > error: explicit specialization of non-template 'QAtomicOpsSupport' > template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; > > 2) here is the first error message (I get the same for other <2> later as well) > > In file included from ../../include/QtCore/qatomic_cxx11.h:1:0, > from > ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:53, > from ../../include/QtCore/qbasicatomic.h:1, > from > ../../include/QtCore/../../src/corelib/thread/qatomic.h:46, > from ../../include/QtCore/qatomic.h:1, > from > ../../include/QtCore/../../src/corelib/global/qglobal.h:1185, > from ../../include/QtCore/qglobal.h:1, > from > ../../include/QtCore/../../src/corelib/thread/qgenericatomic.h:44, > from ../../include/QtCore/qgenericatomic.h:1, > from arch/qatomic_bootstrap.h:44: > ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:19: > error: 'QAtomicOpsSupport' is not a class template > template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; > ^~~~~~~~~~~~~~~~~ > ../../include/QtCore/../../src/corelib/arch/qatomic_cxx11.h:48:40: > error: explicit specialization of non-template 'QAtomicOpsSupport' > template<> struct QAtomicOpsSupport<1> { enum { IsSupported = 1 }; }; > > 3) here is the compiler version, > D:/compilers/gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ > -v > Using built-in specs. > COLLECT_GCC=D:\compilers\gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf\bin\arm-linux-gnueabihf-g++.exe > COLLECT_LTO_WRAPPER=d:/compilers/gcc-linaro-7.1.1-2017.08-i686-mingw32_arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/7.1.1/lto-wrapper.exe > Target: arm-linux-gnueabihf > Configured with: > '/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/snapshots/gcc.git~linaro-7.1-2017.08/configure' > SHELL=/bin/bash > --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 > --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 > --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 > --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto > --enable-shared --without-included-gettext --enable-nls > --disable-sjlj-exceptions --enable-gnu-unique-object > --enable-linker-build-id --disable-libstdcxx-pch --enable-c99 > --enable-clocale=gnu --enable-libstdcxx-debug --enable-long-long > --with-cloog=no --with-ppl=no --with-isl=no --disable-multilib > --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb > --with-tune=cortex-a9 --with-arch=armv7-a --enable-threads=posix > --enable-multiarch --enable-libstdcxx-time=yes > --enable-gnu-indirect-function > --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/sysroots/arm-linux-gnueabihf > --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32/arm-linux-gnueabihf/libc > --enable-checking=release --disable-bootstrap > --enable-languages=c,c++,fortran,lto > --with-libiconv-prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32/usr > --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 > --target=arm-linux-gnueabihf > --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32 > Thread model: posix > gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08) > > Thanks for your help! > -- > Carry a towel > http://dataved.ru/ > +7 916 562 8095 > > [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ > [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings > [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ > > > On Tue, Mar 6, 2018 at 6:29 PM, Thiago Macieira > wrote: >> On Tuesday, 6 March 2018 07:04:52 PST Alexei Fedotov wrote: >>> Hi Edward, >>> After I learned that configure needs -recheck and cleaned the >>> workspace, I cannot build Qt that >>> far to check the fix. I get the problem with QAtomicOpsSupport with >>> the last branch and some other problems with different branches >>> "is not a class template >>> template<> struct QAtomicOpsSupport<2> { enum { IsSupported = 1 }; };" >>> >>> Trying to figure out what to do. Any advice is appreciated. >> >> Start by pasting the exact error message. File name, line number and compiler >> command-line help 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 From thiago.macieira at intel.com Tue Mar 6 18:18:09 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 6 Mar 2018 09:18:09 -0800 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: <4942212.GksEE0fiAM@tjmaciei-mobl1> Message-ID: <190050597.bTpa5menfU@tjmaciei-mobl1> On Tuesday, 6 March 2018 07:42:59 PST Alexei Fedotov wrote: > -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB [cut] > arch/qatomic_bootstrap.h -o .obj/header_qatomic_bootstrap.obj This is a header check of a file that shouldn't be header-checked. The header in question (qatomic_bootstrap.h) has: #pragma qt_sync_skip_header_check So the problem is syncqt. Please delete your build, verify that Perl is properly installed in your environment (it cannot be MSYS's) and and that you don't have a stale syncqt somewhere. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mitch.curtis at qt.io Wed Mar 7 07:19:31 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 7 Mar 2018 06:19:31 +0000 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Kevin Kofler > Sent: Tuesday, 6 March 2018 3:06 PM > To: development at qt-project.org > Subject: Re: [Development] Making QObject::dumpObjectTree() and > QObject::dumpObjectInfo() invokable > > Mitch Curtis wrote: > > https://codereview.qt-project.org/#/c/221758/ makes > > QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so > > that they can be used from QML. > > Would this have any security impact? I'm thinking of issues like ASLR bypass > or other information leakage, if these end up being invokable from untrusted > scripts. Or is all the information contained there already available to QML? I was hoping someone else would answer this because I have no idea what ASLR bypass is, but I can say that the information is already available to QML, at the very least by exposing it from C++, if that's what you mean. > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olszak.tomasz at gmail.com Wed Mar 7 10:25:46 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 7 Mar 2018 10:25:46 +0100 Subject: [Development] Is Qt Quick Item properties order significant? Message-ID: Hello, I'm writing here because I don't know if it is a bug or intended behavior and I should look more carefully in docs (haven't found anything mentioning it yet). Please consider 2 examples (can be pasted anywhere - you will see logs from object initialization): Item { property int tmp0: getTmp0Value(tmp1) property int tmp1: getTmp1Value() function getTmp1Value() { console.log("getTmp1Value should be called only once and before getTmp0Value"); return 1; } function getTmp0Value(arg) { console.log("getTmp0Value should be called only once and aftere getTmp1Value"); return arg + 1; } } And with small modification (order of properties has changed): Item { property int tmp1: getTmp1Value() property int tmp0: getTmp0Value(tmp1) .... } First one calls getTmp1Value twice, second one - as expected only once. Seems like when tmp0 is initialized it does not initialize tmp1 first as dependency but takes expression binding from tmp1 executes it and assign result to tmp0, then executes the same expression for tmp1 to initialize it. Is it a bug or do I miss something? Tomek -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Wed Mar 7 11:57:24 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 07 Mar 2018 11:57:24 +0100 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable References: Message-ID: Mitch Curtis wrote: > I was hoping someone else would answer this because I have no idea what > ASLR bypass is ASLR bypass is when malicious code can find out addresses that it should not know due to address space layout randomization. Kevin Kofler From rich at kde.org Wed Mar 7 12:30:33 2018 From: rich at kde.org (Richard Moore) Date: Wed, 7 Mar 2018 11:30:33 +0000 Subject: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable In-Reply-To: References: Message-ID: On 6 March 2018 at 14:06, Kevin Kofler wrote: > Mitch Curtis wrote: > > https://codereview.qt-project.org/#/c/221758/ makes > > QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that > > they can be used from QML. > > Would this have any security impact? I'm thinking of issues like ASLR > bypass > or other information leakage, if these end up being invokable from > untrusted > scripts. Or is all the information contained there already available to > QML? > > ​QML is not safe to run untrusted scripts period. Rich. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Thu Mar 8 04:53:15 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 8 Mar 2018 04:53:15 +0100 Subject: [Development] Is Qt Quick Item properties order significant? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From olszak.tomasz at gmail.com Thu Mar 8 08:15:51 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Thu, 8 Mar 2018 08:15:51 +0100 Subject: [Development] Is Qt Quick Item properties order significant? In-Reply-To: References: Message-ID: Hi thanks for feedback, I agree that putting everything in Component.onCompleted would be worse workaround than changing order but more explicit. On the other hand it is a lot less declarative. In my application I build different kinds of settings using list of objects or strings. I encountered this issue while building list of Time Zones. The Item that contained this list was instantiated in more than a second. Then I realized that the function that creates and filters list is called twice. There are numerous places in my application that uses function to initialize object properties. Moreover if I change tmp0 to: "property int tmp0: tmp1 + 1" getTmp1Value is still called twice which seems like a bug. AFAIK Qt knows dependencies between bindings because it triggers reevaluation in dependent property has changed. Seems like this dependency is ignored during initialization phase. Depending on complexity and duration of execution of bindings expression instantiation of component can be almost twice longer without any explicit cause. Am I right or missing something? 2018-03-08 4:53 GMT+01:00 Jason H : > > I can see your point. But tmp1 is not changing during the first property init, so it won't be evaluated. The way to work around this order-specifc init is to do it explicitly in a Component.onCompleted > > Sent: Wednesday, March 07, 2018 at 4:25 AM > From: "Tomasz Olszak" > To: development at qt-project.org > Subject: [Development] Is Qt Quick Item properties order significant? > Hello, > > I'm writing here because I don't know if it is a bug or intended behavior and I should look more carefully in docs (haven't found anything mentioning it yet). > > Please consider 2 examples (can be pasted anywhere - you will see logs from object initialization): > Item { > property int tmp0: getTmp0Value(tmp1) > property int tmp1: getTmp1Value() > function getTmp1Value() { > console.log("getTmp1Value should be called only once and before getTmp0Value"); > return 1; > } > function getTmp0Value(arg) { > console.log("getTmp0Value should be called only once and aftere getTmp1Value"); > return arg + 1; > } > } > > And with small modification (order of properties has changed): > Item { > property int tmp1: getTmp1Value() > property int tmp0: getTmp0Value(tmp1) > .... > } > > > First one calls getTmp1Value twice, second one - as expected only once. Seems like when tmp0 is initialized it does not initialize tmp1 first as dependency but takes expression binding from tmp1 executes it and assign result to tmp0, then executes the same expression for tmp1 to initialize it. > > Is it a bug or do I miss something? > > Tomek > > > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From olszak.tomasz at gmail.com Thu Mar 8 08:25:32 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Thu, 8 Mar 2018 08:25:32 +0100 Subject: [Development] Is Qt Quick Item properties order significant? In-Reply-To: References: Message-ID: The same behavior is when tmp1 is initialized with C++ function. Function is called twice too. 2018-03-08 8:15 GMT+01:00 Tomasz Olszak : > Hi thanks for feedback, > > I agree that putting everything in Component.onCompleted would be > worse workaround > than changing order but more explicit. On the other hand it is a lot > less declarative. > > In my application I build different kinds of settings using list of objects or > strings. I encountered this issue while building list of Time Zones. The Item > that contained this list was instantiated in more than a second. Then I realized > that the function that creates and filters list is called twice. There are > numerous places in my application that uses function to initialize object > properties. > > Moreover if I change tmp0 to: "property int tmp0: tmp1 + 1" > getTmp1Value is still called twice which seems like a bug. > AFAIK Qt knows dependencies between bindings because it triggers reevaluation > in dependent property has changed. Seems like this dependency is ignored during > initialization phase. Depending on complexity and duration of execution of > bindings expression instantiation of component can be almost twice longer > without any explicit cause. > > Am I right or missing something? > > 2018-03-08 4:53 GMT+01:00 Jason H : >> >> I can see your point. But tmp1 is not changing during the first property init, so it won't be evaluated. The way to work around this order-specifc init is to do it explicitly in a Component.onCompleted >> >> Sent: Wednesday, March 07, 2018 at 4:25 AM >> From: "Tomasz Olszak" >> To: development at qt-project.org >> Subject: [Development] Is Qt Quick Item properties order significant? >> Hello, >> >> I'm writing here because I don't know if it is a bug or intended behavior and I should look more carefully in docs (haven't found anything mentioning it yet). >> >> Please consider 2 examples (can be pasted anywhere - you will see logs from object initialization): >> Item { >> property int tmp0: getTmp0Value(tmp1) >> property int tmp1: getTmp1Value() >> function getTmp1Value() { >> console.log("getTmp1Value should be called only once and before getTmp0Value"); >> return 1; >> } >> function getTmp0Value(arg) { >> console.log("getTmp0Value should be called only once and aftere getTmp1Value"); >> return arg + 1; >> } >> } >> >> And with small modification (order of properties has changed): >> Item { >> property int tmp1: getTmp1Value() >> property int tmp0: getTmp0Value(tmp1) >> .... >> } >> >> >> First one calls getTmp1Value twice, second one - as expected only once. Seems like when tmp0 is initialized it does not initialize tmp1 first as dependency but takes expression binding from tmp1 executes it and assign result to tmp0, then executes the same expression for tmp1 to initialize it. >> >> Is it a bug or do I miss something? >> >> Tomek >> >> >> _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From olszak.tomasz at gmail.com Thu Mar 8 13:11:11 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Thu, 8 Mar 2018 13:11:11 +0100 Subject: [Development] Is Qt Quick Item properties order significant? In-Reply-To: References: Message-ID: With help from IRC I submitted regression Bug: https://bugreports.qt.io/browse/QTBUG-66945 2018-03-08 8:25 GMT+01:00 Tomasz Olszak : > The same behavior is when tmp1 is initialized with C++ function. > Function is called twice too. > > 2018-03-08 8:15 GMT+01:00 Tomasz Olszak : >> Hi thanks for feedback, >> >> I agree that putting everything in Component.onCompleted would be >> worse workaround >> than changing order but more explicit. On the other hand it is a lot >> less declarative. >> >> In my application I build different kinds of settings using list of objects or >> strings. I encountered this issue while building list of Time Zones. The Item >> that contained this list was instantiated in more than a second. Then I realized >> that the function that creates and filters list is called twice. There are >> numerous places in my application that uses function to initialize object >> properties. >> >> Moreover if I change tmp0 to: "property int tmp0: tmp1 + 1" >> getTmp1Value is still called twice which seems like a bug. >> AFAIK Qt knows dependencies between bindings because it triggers reevaluation >> in dependent property has changed. Seems like this dependency is ignored during >> initialization phase. Depending on complexity and duration of execution of >> bindings expression instantiation of component can be almost twice longer >> without any explicit cause. >> >> Am I right or missing something? >> >> 2018-03-08 4:53 GMT+01:00 Jason H : >>> >>> I can see your point. But tmp1 is not changing during the first property init, so it won't be evaluated. The way to work around this order-specifc init is to do it explicitly in a Component.onCompleted >>> >>> Sent: Wednesday, March 07, 2018 at 4:25 AM >>> From: "Tomasz Olszak" >>> To: development at qt-project.org >>> Subject: [Development] Is Qt Quick Item properties order significant? >>> Hello, >>> >>> I'm writing here because I don't know if it is a bug or intended behavior and I should look more carefully in docs (haven't found anything mentioning it yet). >>> >>> Please consider 2 examples (can be pasted anywhere - you will see logs from object initialization): >>> Item { >>> property int tmp0: getTmp0Value(tmp1) >>> property int tmp1: getTmp1Value() >>> function getTmp1Value() { >>> console.log("getTmp1Value should be called only once and before getTmp0Value"); >>> return 1; >>> } >>> function getTmp0Value(arg) { >>> console.log("getTmp0Value should be called only once and aftere getTmp1Value"); >>> return arg + 1; >>> } >>> } >>> >>> And with small modification (order of properties has changed): >>> Item { >>> property int tmp1: getTmp1Value() >>> property int tmp0: getTmp0Value(tmp1) >>> .... >>> } >>> >>> >>> First one calls getTmp1Value twice, second one - as expected only once. Seems like when tmp0 is initialized it does not initialize tmp1 first as dependency but takes expression binding from tmp1 executes it and assign result to tmp0, then executes the same expression for tmp1 to initialize it. >>> >>> Is it a bug or do I miss something? >>> >>> Tomek >>> >>> >>> _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jhihn at gmx.com Fri Mar 9 01:44:50 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 9 Mar 2018 01:44:50 +0100 Subject: [Development] Is Qt Quick Item properties order significant? In-Reply-To: References: Message-ID: Neat! I've never seen a patch land that fast! I'm going to be happy with this one! > Sent: Thursday, March 08, 2018 at 7:11 AM > From: "Tomasz Olszak" > To: No recipient address > Cc: development at qt-project.org > Subject: Re: [Development] Is Qt Quick Item properties order significant? > > With help from IRC I submitted regression Bug: > https://bugreports.qt.io/browse/QTBUG-66945 > > > 2018-03-08 8:25 GMT+01:00 Tomasz Olszak : > > The same behavior is when tmp1 is initialized with C++ function. > > Function is called twice too. > > > > 2018-03-08 8:15 GMT+01:00 Tomasz Olszak : > >> Hi thanks for feedback, > >> > >> I agree that putting everything in Component.onCompleted would be > >> worse workaround > >> than changing order but more explicit. On the other hand it is a lot > >> less declarative. > >> > >> In my application I build different kinds of settings using list of objects or > >> strings. I encountered this issue while building list of Time Zones. The Item > >> that contained this list was instantiated in more than a second. Then I realized > >> that the function that creates and filters list is called twice. There are > >> numerous places in my application that uses function to initialize object > >> properties. > >> > >> Moreover if I change tmp0 to: "property int tmp0: tmp1 + 1" > >> getTmp1Value is still called twice which seems like a bug. > >> AFAIK Qt knows dependencies between bindings because it triggers reevaluation > >> in dependent property has changed. Seems like this dependency is ignored during > >> initialization phase. Depending on complexity and duration of execution of > >> bindings expression instantiation of component can be almost twice longer > >> without any explicit cause. > >> > >> Am I right or missing something? > >> > >> 2018-03-08 4:53 GMT+01:00 Jason H : > >>> > >>> I can see your point. But tmp1 is not changing during the first property init, so it won't be evaluated. The way to work around this order-specifc init is to do it explicitly in a Component.onCompleted > >>> > >>> Sent: Wednesday, March 07, 2018 at 4:25 AM > >>> From: "Tomasz Olszak" > >>> To: development at qt-project.org > >>> Subject: [Development] Is Qt Quick Item properties order significant? > >>> Hello, > >>> > >>> I'm writing here because I don't know if it is a bug or intended behavior and I should look more carefully in docs (haven't found anything mentioning it yet). > >>> > >>> Please consider 2 examples (can be pasted anywhere - you will see logs from object initialization): > >>> Item { > >>> property int tmp0: getTmp0Value(tmp1) > >>> property int tmp1: getTmp1Value() > >>> function getTmp1Value() { > >>> console.log("getTmp1Value should be called only once and before getTmp0Value"); > >>> return 1; > >>> } > >>> function getTmp0Value(arg) { > >>> console.log("getTmp0Value should be called only once and aftere getTmp1Value"); > >>> return arg + 1; > >>> } > >>> } > >>> > >>> And with small modification (order of properties has changed): > >>> Item { > >>> property int tmp1: getTmp1Value() > >>> property int tmp0: getTmp0Value(tmp1) > >>> .... > >>> } > >>> > >>> > >>> First one calls getTmp1Value twice, second one - as expected only once. Seems like when tmp0 is initialized it does not initialize tmp1 first as dependency but takes expression binding from tmp1 executes it and assign result to tmp0, then executes the same expression for tmp1 to initialize it. > >>> > >>> Is it a bug or do I miss something? > >>> > >>> Tomek > >>> > >>> > >>> _______________________________________________ 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 olszak.tomasz at gmail.com Fri Mar 9 10:13:09 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Fri, 9 Mar 2018 10:13:09 +0100 Subject: [Development] Is Qt Quick Item properties order significant? In-Reply-To: References: Message-ID: Yes, I would like to thank Simon and Mitch for taking care of this. The prospect of spending few days on reviewing code and rearranging properties was not making me happy :) 2018-03-09 1:44 GMT+01:00 Jason H : > Neat! I've never seen a patch land that fast! I'm going to be happy with this one! > > >> Sent: Thursday, March 08, 2018 at 7:11 AM >> From: "Tomasz Olszak" >> To: No recipient address >> Cc: development at qt-project.org >> Subject: Re: [Development] Is Qt Quick Item properties order significant? >> >> With help from IRC I submitted regression Bug: >> https://bugreports.qt.io/browse/QTBUG-66945 >> >> >> 2018-03-08 8:25 GMT+01:00 Tomasz Olszak : >> > The same behavior is when tmp1 is initialized with C++ function. >> > Function is called twice too. >> > >> > 2018-03-08 8:15 GMT+01:00 Tomasz Olszak : >> >> Hi thanks for feedback, >> >> >> >> I agree that putting everything in Component.onCompleted would be >> >> worse workaround >> >> than changing order but more explicit. On the other hand it is a lot >> >> less declarative. >> >> >> >> In my application I build different kinds of settings using list of objects or >> >> strings. I encountered this issue while building list of Time Zones. The Item >> >> that contained this list was instantiated in more than a second. Then I realized >> >> that the function that creates and filters list is called twice. There are >> >> numerous places in my application that uses function to initialize object >> >> properties. >> >> >> >> Moreover if I change tmp0 to: "property int tmp0: tmp1 + 1" >> >> getTmp1Value is still called twice which seems like a bug. >> >> AFAIK Qt knows dependencies between bindings because it triggers reevaluation >> >> in dependent property has changed. Seems like this dependency is ignored during >> >> initialization phase. Depending on complexity and duration of execution of >> >> bindings expression instantiation of component can be almost twice longer >> >> without any explicit cause. >> >> >> >> Am I right or missing something? >> >> >> >> 2018-03-08 4:53 GMT+01:00 Jason H : >> >>> >> >>> I can see your point. But tmp1 is not changing during the first property init, so it won't be evaluated. The way to work around this order-specifc init is to do it explicitly in a Component.onCompleted >> >>> >> >>> Sent: Wednesday, March 07, 2018 at 4:25 AM >> >>> From: "Tomasz Olszak" >> >>> To: development at qt-project.org >> >>> Subject: [Development] Is Qt Quick Item properties order significant? >> >>> Hello, >> >>> >> >>> I'm writing here because I don't know if it is a bug or intended behavior and I should look more carefully in docs (haven't found anything mentioning it yet). >> >>> >> >>> Please consider 2 examples (can be pasted anywhere - you will see logs from object initialization): >> >>> Item { >> >>> property int tmp0: getTmp0Value(tmp1) >> >>> property int tmp1: getTmp1Value() >> >>> function getTmp1Value() { >> >>> console.log("getTmp1Value should be called only once and before getTmp0Value"); >> >>> return 1; >> >>> } >> >>> function getTmp0Value(arg) { >> >>> console.log("getTmp0Value should be called only once and aftere getTmp1Value"); >> >>> return arg + 1; >> >>> } >> >>> } >> >>> >> >>> And with small modification (order of properties has changed): >> >>> Item { >> >>> property int tmp1: getTmp1Value() >> >>> property int tmp0: getTmp0Value(tmp1) >> >>> .... >> >>> } >> >>> >> >>> >> >>> First one calls getTmp1Value twice, second one - as expected only once. Seems like when tmp0 is initialized it does not initialize tmp1 first as dependency but takes expression binding from tmp1 executes it and assign result to tmp0, then executes the same expression for tmp1 to initialize it. >> >>> >> >>> Is it a bug or do I miss something? >> >>> >> >>> Tomek >> >>> >> >>> >> >>> _______________________________________________ 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 Fri Mar 9 10:17:31 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 9 Mar 2018 09:17:31 +0000 Subject: [Development] Is Qt Quick Item properties order significant? In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Tomasz Olszak > Sent: Friday, 9 March 2018 10:13 AM > Cc: development at qt-project.org > Subject: Re: [Development] Is Qt Quick Item properties order significant? > > Yes, I would like to thank Simon and Mitch for taking care of this. I did nothing, all props go to Simon. :) > The prospect of spending few days on reviewing code and rearranging > properties was not making me happy :) > > 2018-03-09 1:44 GMT+01:00 Jason H : > > Neat! I've never seen a patch land that fast! I'm going to be happy with this > one! > > > > > >> Sent: Thursday, March 08, 2018 at 7:11 AM > >> From: "Tomasz Olszak" > >> To: No recipient address > >> Cc: development at qt-project.org > >> Subject: Re: [Development] Is Qt Quick Item properties order significant? > >> > >> With help from IRC I submitted regression Bug: > >> https://bugreports.qt.io/browse/QTBUG-66945 > >> > >> > >> 2018-03-08 8:25 GMT+01:00 Tomasz Olszak : > >> > The same behavior is when tmp1 is initialized with C++ function. > >> > Function is called twice too. > >> > > >> > 2018-03-08 8:15 GMT+01:00 Tomasz Olszak > : > >> >> Hi thanks for feedback, > >> >> > >> >> I agree that putting everything in Component.onCompleted would be > >> >> worse workaround than changing order but more explicit. On the > >> >> other hand it is a lot less declarative. > >> >> > >> >> In my application I build different kinds of settings using list > >> >> of objects or strings. I encountered this issue while building > >> >> list of Time Zones. The Item that contained this list was > >> >> instantiated in more than a second. Then I realized that the > >> >> function that creates and filters list is called twice. There are > >> >> numerous places in my application that uses function to initialize object > properties. > >> >> > >> >> Moreover if I change tmp0 to: "property int tmp0: tmp1 + 1" > >> >> getTmp1Value is still called twice which seems like a bug. > >> >> AFAIK Qt knows dependencies between bindings because it triggers > >> >> reevaluation in dependent property has changed. Seems like this > >> >> dependency is ignored during initialization phase. Depending on > >> >> complexity and duration of execution of bindings expression > >> >> instantiation of component can be almost twice longer without any > explicit cause. > >> >> > >> >> Am I right or missing something? > >> >> > >> >> 2018-03-08 4:53 GMT+01:00 Jason H : > >> >>> > >> >>> I can see your point. But tmp1 is not changing during the first > >> >>> property init, so it won't be evaluated. The way to work around > >> >>> this order-specifc init is to do it explicitly in a > >> >>> Component.onCompleted > >> >>> > >> >>> Sent: Wednesday, March 07, 2018 at 4:25 AM > >> >>> From: "Tomasz Olszak" > >> >>> To: development at qt-project.org > >> >>> Subject: [Development] Is Qt Quick Item properties order significant? > >> >>> Hello, > >> >>> > >> >>> I'm writing here because I don't know if it is a bug or intended > behavior and I should look more carefully in docs (haven't found anything > mentioning it yet). > >> >>> > >> >>> Please consider 2 examples (can be pasted anywhere - you will see > logs from object initialization): > >> >>> Item { > >> >>> property int tmp0: getTmp0Value(tmp1) > >> >>> property int tmp1: getTmp1Value() > >> >>> function getTmp1Value() { > >> >>> console.log("getTmp1Value should be called only once and > before getTmp0Value"); > >> >>> return 1; > >> >>> } > >> >>> function getTmp0Value(arg) { > >> >>> console.log("getTmp0Value should be called only once and aftere > getTmp1Value"); > >> >>> return arg + 1; > >> >>> } > >> >>> } > >> >>> > >> >>> And with small modification (order of properties has changed): > >> >>> Item { > >> >>> property int tmp1: getTmp1Value() > >> >>> property int tmp0: getTmp0Value(tmp1) > >> >>> .... > >> >>> } > >> >>> > >> >>> > >> >>> First one calls getTmp1Value twice, second one - as expected only > once. Seems like when tmp0 is initialized it does not initialize tmp1 first as > dependency but takes expression binding from tmp1 executes it and assign > result to tmp0, then executes the same expression for tmp1 to initialize it. > >> >>> > >> >>> Is it a bug or do I miss something? > >> >>> > >> >>> Tomek > >> >>> > >> >>> > >> >>> _______________________________________________ > Development > >> >>> mailing list Development at qt-project.org > >> >>> http://lists.qt-project.org/mailman/listinfo/development > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tony.sarajarvi at qt.io Fri Mar 9 13:08:29 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 9 Mar 2018 12:08:29 +0000 Subject: [Development] CI maintenance break on March 21 @ 8:00 - 9:00 EET Message-ID: Hi We'd like to have a small maintenance break. If the suggested time doesn't fit you at all, please contact us and we'll reschedule. Purpose: We'd like to update the firmware on the hardware running Coin. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Fri Mar 9 13:57:49 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Fri, 9 Mar 2018 12:57:49 +0000 Subject: [Development] Qt for WebAssembly Message-ID: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> Hi all, As you may have noticed work on Qt for WebAssembly is underway. With the recent updates the wip/webassembly branches are now based on Qt 5.11, which they will continue to be while we work on bringing up Qt Quick. The tracking bug for the project is QTBUG-63917 (with subtasks). This is a continuation of the initial port at https://codereview.qt-project.org/#/c/178543/ I think this may be a good time to discuss how we want to support Qt for WebAssembly and what direction the project should take. I’ll start out by describing some recent developments: * We are targeting WebAssembly using Emscripten as the SDK. The platform plugin is implemented (mainly) using the html5.h API from emscripten. The platform define is Q_OS_HTML5. We have wip branches for qtbase and qtdeclarative. If (minor) adjustments are needed in other modules then those could be submitted to the 5.11 branch under the Q_OS_HTML5 define. * Binary sizes: We are using static builds. The minimal Qt demos (QtCore + QtGui) come out at 2.1M compressed. The SensorTag demo (QtCore + QtGui + QtWidgets + QtQuick + QtCharts) (as seen on Embedded World) is 6.3M. In the end it may be that application assets will contribute significantly to the overall application size. We can look into building an asset download pipeline using web service workers. * Load times: In addition to the network connection this depends on the browser wasm implementation, Firefox has recently gotten very fast and can download and instantiate the small Qt demos in a couple of seconds. * Qt Applications as web page components Qt for WebAssembly draws to a HTML element. The default Qt html template makes the canvas cover the entire browser viewport, but any layout is possible. The size and position of the canvas may very well be outside of the applications control. Multiple canvases per “process” is possible but not yet supported. On the Qt side each canvas corresponds to a QScreen. The application is responsible for positioning windows on the screen(s). Qt::WindowFullScreen windows fill the entire canvas area with application content, normal windows get window decorations. We provide a Javascript API (qtloader.js) for managing the application process. (Here we have the luxury of using modern JS features due to the natural selection of browsers that the wasm requirement provides.) * Fonts We don’t have access to system font files. This means fonts must me embedded in the application binary or downloaded on demand. Exact font style matches with “native” system fonts will probably remain out of scope, but should still be able to match the font size setting. Page zoom is handled via the high-dpi implementation. * (No) thread support Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer, which has been disabled in all major browser after recent security incidents. So we are looking to upstream a no-thread configure option, and modules that want to work on the web should support it. It’s still possible to develop with pthreads enabled by enabling SharedArrayBuffer for your browser. No-thread could be implemented either by removing QThread (and friends), or by making QThread::start() a no-op. * QML interpretation vs compilation We’re currently using the QML interpreter, which is working reasonably well for development purposes. The end state is to compile to wasm, ahead of time. There has been some discussion on whether compilation should be implemented before anything is merged to the main Qt branches, or be handled later on. * Networking We are looking there approaches: (not mutually exclusive) - A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch. This allows making HTTP REST requests back to the origin server, or to other servers by using CORS. - A QWebSocket (client) backend implemented using HTML5 WebSocket This would allow making websocket connections to any server. - Using the emscripten sockets implementation and websockify. This is a tunneling solution where the server runs e.g. websockify and will forward to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work is needed in Qt. * QtMultimedia Very open for contributions :) Further information including getting started instructions is available on QTBUG-63917, and also or on QTBUG-65198 (platform documentation). Thanks for reading! Morten From jhihn at gmx.com Fri Mar 9 15:53:54 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 9 Mar 2018 15:53:54 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> Message-ID: While I am excited about this, I still wonder that it's the right approach. By right, I mean scalable. After evaluating the WebGL platform (which I was excited about as well) had having extreme performance issues, I foresee that this will has performance issues as well, because of one defect: You're rendering to a canvas what the browser can draw natively. If people want to serve Qt apps to the web, then the best approach (IMHO) is to use a server to send a client which is defined in HTML5 (name clash with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a QPainter). This will leverage the browser in the best way possible, and let it handle the low-level drawing. To this end QMLWeb is an existing approach (https://github.com/qmlweb/qmlweb). While I wish you the best of luck, I don't think it's going to work out well. The other day I asked the question on the blog, "Why can't we divorce behavior from the the UI?" (conceptually speaking) I was asking it in the context of QtQuick/QWidgets consistency, but I'd like to extend that to HTML elements as well. You should be able to define the UI component and the behavior component of a GUI item seperately and just attach the same behaviors to he various UIs. The thing here is that the HTML version of it would already come with some behaviors supplied by the browser, and the UI component would similarly be rendered by the browser. I know this isn't do-able in 5, or maybe even 6, but it's where I think things are headed. For example, a simple .ui file translator that gives you a HTML5 app would be the start. If you don't think this is possible, you should check out Webtoolkit (https://www.webtoolkit.eu/wt) which is a copy of Qt for the web. It works. At one point I wrote a script t translate Designer's .ui files from the Q* to the W* versions and it worked, mostly. If Qt wants to target the web, properly then bringing in Wt would be the 'proper' (IMHO) approach. We've had efforts to cram Qt binaries into browsers for over 10 years now (ActiveQt). None of it has really succeeded. I speculate it's because the initial load time is a huge turn-off. You can't use Qt for regular web sites, soo the appeal is limited. The ideal approach is one where Qt is advanced as a preferred web development technology, as well as a native technology. Incidentally that also opens Qt up to the biggest possible licensing base. Qt can compete with (and IMHO is better than) React and Angular. But this smallest-effort-to-the-browser is fundamentally broken, and I think will only result in an "also-ran" situation. I don't want to steal your thunder, but what is fundamentally different about this approach this time? Why will the results be any different? > Sent: Friday, March 09, 2018 at 7:57 AM > From: "Morten Sørvig" > To: "Qt Project Development Mailing-List" > Subject: [Development] Qt for WebAssembly > > Hi all, > > As you may have noticed work on Qt for WebAssembly is underway. With the > recent updates the wip/webassembly branches are now based on Qt 5.11, which > they will continue to be while we work on bringing up Qt Quick. The tracking > bug for the project is QTBUG-63917 (with subtasks). This is a continuation of > the initial port at https://codereview.qt-project.org/#/c/178543/ > > I think this may be a good time to discuss how we want to support Qt for > WebAssembly and what direction the project should take. I’ll start out > by describing some recent developments: > > * We are targeting WebAssembly using Emscripten as the SDK. The platform plugin > is implemented (mainly) using the html5.h API from emscripten. > > The platform define is Q_OS_HTML5. We have wip branches for qtbase and > qtdeclarative. If (minor) adjustments are needed in other modules then > those could be submitted to the 5.11 branch under the Q_OS_HTML5 define. > > * Binary sizes: We are using static builds. The minimal Qt demos (QtCore + QtGui) come > out at 2.1M compressed. The SensorTag demo (QtCore + QtGui + QtWidgets + QtQuick + QtCharts) > (as seen on Embedded World) is 6.3M. > > In the end it may be that application assets will contribute significantly to > the overall application size. We can look into building an asset download > pipeline using web service workers. > > * Load times: In addition to the network connection this depends on the browser > wasm implementation, Firefox has recently gotten very fast and can download and > instantiate the small Qt demos in a couple of seconds. > > * Qt Applications as web page components > > Qt for WebAssembly draws to a HTML element. The default Qt html template > makes the canvas cover the entire browser viewport, but any layout is possible. > The size and position of the canvas may very well be outside of the applications > control. Multiple canvases per “process” is possible but not yet supported. > > On the Qt side each canvas corresponds to a QScreen. The application is responsible > for positioning windows on the screen(s). Qt::WindowFullScreen windows fill the entire > canvas area with application content, normal windows get window decorations. > > We provide a Javascript API (qtloader.js) for managing the application process. > (Here we have the luxury of using modern JS features due to the natural selection > of browsers that the wasm requirement provides.) > > * Fonts > > We don’t have access to system font files. This means fonts must me embedded in > the application binary or downloaded on demand. > > Exact font style matches with “native” system fonts will probably remain out of > scope, but should still be able to match the font size setting. Page zoom is > handled via the high-dpi implementation. > > * (No) thread support > > Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer, > which has been disabled in all major browser after recent security incidents. > > So we are looking to upstream a no-thread configure option, and modules that > want to work on the web should support it. It’s still possible to develop with > pthreads enabled by enabling SharedArrayBuffer for your browser. > > No-thread could be implemented either by removing QThread (and friends), or by > making QThread::start() a no-op. > > * QML interpretation vs compilation > > We’re currently using the QML interpreter, which is working reasonably well > for development purposes. The end state is to compile to wasm, ahead of time. > > There has been some discussion on whether compilation should be implemented > before anything is merged to the main Qt branches, or be handled later on. > > * Networking > > We are looking there approaches: (not mutually exclusive) > > - A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch. > > This allows making HTTP REST requests back to the origin server, or to other servers > by using CORS. > > - A QWebSocket (client) backend implemented using HTML5 WebSocket > > This would allow making websocket connections to any server. > > - Using the emscripten sockets implementation and websockify. > > This is a tunneling solution where the server runs e.g. websockify and will forward > to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work > is needed in Qt. > > * QtMultimedia > > Very open for contributions :) > > Further information including getting started instructions is available on QTBUG-63917, > and also or on QTBUG-65198 (platform documentation). > > Thanks for reading! > Morten > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From sreegowthamj at gmail.com Fri Mar 9 19:02:38 2018 From: sreegowthamj at gmail.com (Sree Gowtham Josyula) Date: Fri, 9 Mar 2018 11:02:38 -0700 Subject: [Development] GSoC 2018: Interested in working on Bazel plugin for Qt Creator Message-ID: Hello All, I am a Masters Student in Computer Engineering Program at Arizona State University. I am interested in participating in Google Summer of Code 2018 with Qt as my mentor organisation. I went through all the projects mentioned here - https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas and I am interested in working on the Bazel plugin for Qt Creator. In that regard, I went through the plugin architecture of Qt Creator and CMakeProjectManager plugin written for it. Based on what I have understood, I have split the main task of Bazel suport for Qt Creator into the following sub tasks - 1. Getting the information of the configured toolchains in qtkitinformation 2. Identifying the build directory for a toolchain and running Bazel in it for the given project 3. Parsing the bazel configuration output from build directory to identify targets, header paths and compiler flags 4. Passing header paths and compiler flags information to Clang backend for supporting clang functionality like goto definition, auto-complete 5. Bazel BUILD & WORKSPACE file editor - with indentation, syntax highlighting and auto-complete support 6. GUI in the settings pane for configuring Bazel and setting additional flags, parameters for compilation 7. Writing appropriate unit tests Could you let me know if my approach is in the right direction and also if there is anything else I could do to add to the above. Thank you. Best Regards, Gowtham (Sree Gowtham Josyula) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.murison at gmail.com Fri Mar 9 19:09:01 2018 From: tim.murison at gmail.com (Tim Murison) Date: Fri, 09 Mar 2018 13:09:01 -0500 Subject: [Development] Qt for WebAssembly In-Reply-To: Message-ID: <1520618941.2022.12.camel@gmail.com> > > While I am excited about this, I still wonder that it's the right > approach. By right, I mean scalable. > After evaluating the WebGL platform (which I was excited about as > well) had having extreme performance issues, I foresee that this will > has performance issues as well, because of one defect: You're > rendering to a canvas what the browser can draw natively. If people > want to serve Qt apps to the web, then the best approach (IMHO) is to > use a server to send a client which is defined in HTML5 (name clash > with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a > QPainter). This will leverage the browser in the best way possible, > and let it handle the low-level drawing. To this end QMLWeb is an > existing approach (https://github.com/qmlweb/qmlweb). > > While I wish you the best of luck, I don't think it's going to work > out well. The other day I asked the question on the blog, "Why can't > we divorce behavior from the the UI?" (conceptually speaking) I was > asking it in the context of QtQuick/QWidgets consistency, but I'd > like to extend that to HTML elements as well. You should be able to > define the UI component and the behavior component of a GUI item > seperately and just attach the same behaviors to he various UIs. The > thing here is that the HTML version of it would already come with > some behaviors supplied by the browser, and the UI component would > similarly be rendered by the browser. I know this isn't do-able in 5, > or maybe even 6, but it's where I think things are headed. > > For example, a simple .ui file translator that gives you a HTML5 app > would be the start. If you don't think this is possible, you should > check out Webtoolkit (https://www.webtoolkit.eu/wt) which is a copy > of Qt for the web. It works. At one point I wrote a script t > translate Designer's .ui files from the Q* to the W* versions and it > worked, mostly. If Qt wants to target the web, properly then bringing > in Wt would be the 'proper' (IMHO) approach. > > We've had efforts to cram Qt binaries into browsers for over 10 years > now (ActiveQt). None of it has really succeeded. I speculate it's > because the initial load time is a huge turn-off. You can't use Qt > for regular web sites, soo the appeal is limited. The ideal approach > is one where Qt is advanced as a preferred web development > technology, as well as a native technology. Incidentally that also > opens Qt up to the biggest possible licensing base. > Qt can compete with (and IMHO is better than) React and Angular. But > this smallest-effort-to-the-browser is fundamentally broken, and I > think will only result in an "also-ran" situation. > > I don't want to steal your thunder, but what is fundamentally > different about this approach this time? Why will the results be any > different? > +1, I couldn't agree more with this sentiment. I work in software consulting doing mobile and web work. While Qt has a compelling offering in the mobile and desktop space with Qml, web work has to be done with another toolkit. These days, react-native or Angular are derigeur. As a result it is not possible to effectively evangelize for Qt until Qt can match these technologies. Qt needs a web solution that is as well adapted to the platform and as flexible as the existing Qt solutions for mobile and desktop are. As described this 'Qt for WebAssembly' feature seems to result in web applications that would not be acceptable in many use cases. I'd also like to echo and hopefully amplify what Jason H said about qmlweb. IMO, this is the solution that Qt should be embracing and integrating upstream. qmlweb aims to do what Qt has always done, make cross-platform development easy, efficient and indistinguishable from native development. From sreegowthamj at gmail.com Fri Mar 9 20:16:54 2018 From: sreegowthamj at gmail.com (Sree Gowtham Josyula) Date: Fri, 9 Mar 2018 12:16:54 -0700 Subject: [Development] GSoC 2018 : New Feature proposal Message-ID: Hello All, I am a Masters Student in Computer Engineering Program at Arizona State University. I am interested in participating in Google Summer of Code ​ ​ (GSoC) ​ ​ 2018 with Qt as my mentor ​ ​ organization. In this mail, I would like to propose a new feature for Qt Creator ​ ​ as my GSoC project , ​ ​ based on my experience at my previous company. Problem - In my previous company, we had our development environment in Windows and target platform as arm-linux machine. For that, we would develop code on Windows systems and then sync the project/workspace to the remote linux server and then compile with the cross-compilation tool-chain there and then deploy on the target machine elsewhere. In the above setup we faced the following problems - 1. Unavailability of code completion frameworks on the development machine as all the headers were not available locally 2. Frequently syncing the workspace was a wasteful of time In order to solve the above problem, I would like to propose a Remote System Development plug-in for editing & compiling & executing & debugging files ​ ​ on a remote system on the lines on Emacs Tramp package ( https://www.emacswiki.org/emacs/TrampMode). Features - 1. Public key setup of remote machine on development machine for seamless syncing of files between the two machines 2. Setting up a toolkit (Compiler, Debugger, Qt Tool-chain, cmake, qmake, qbs, sysroot) of a remote machine on the Development machine's Qt Creator IDE 3. Opening projects on remote machine in development machine (Using Ctrl + O) 4. Automatic syncing of workspace between development machine and remote machine(on every save & periodically) - could be done using rsync/librsync 5. Compilation of code on the remote machine with the tool-chain setup there 6. Execution & debugging of code on Remote machine 7. Supporting Clang based code completion - Might need to run the clang daemon on the remote machine and send the responses to development machine. Kindly let me know your thoughts about my above idea. Best Regards, Gowtham (Sree Gowtham Josyula) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorn.potter at gmail.com Fri Mar 9 20:16:55 2018 From: lorn.potter at gmail.com (Lorn Potter) Date: Sat, 10 Mar 2018 05:16:55 +1000 Subject: [Development] Qt for WebAssembly In-Reply-To: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> Message-ID: Hi, I would like to add... One of the guys over at https://qtmob.slack.com keeps a demonstration of the Qt examples for Qt Webassembly (thanks David!): https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/index.html Not all of the examples work, and not all of them work correctly. Firefox seems to be fastest. On 9/3/18 10:57 pm, Morten Sørvig wrote: > Hi all, > * Networking > > We are looking there approaches: (not mutually exclusive) > > - A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch. > > This allows making HTTP REST requests back to the origin server, or to other servers > by using CORS. > > - A QWebSocket (client) backend implemented using HTML5 WebSocket > > This would allow making websocket connections to any server. > > - Using the emscripten sockets implementation and websockify. > > This is a tunneling solution where the server runs e.g. websockify and will forward > to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work > is needed in Qt. While emscripten translates native sockets into websockets, the issue with just using sockets for networking like Qt internally does, is that there are no real DNS lookups due to the sandbox in which webassembly runs. Which is why we needed to use alternate methods. There are also emscripten's wget functions. At least to download, emscripten has various _wget* functions which are available. Probably the biggest gotcha, is that exec currently does not return in the way you would expect. So for example, the scribble example does not change the pen color. From jhihn at gmx.com Fri Mar 9 20:45:54 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 9 Mar 2018 20:45:54 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: <1520618941.2022.12.camel@gmail.com> References: <1520618941.2022.12.camel@gmail.com> Message-ID: > Sent: Friday, March 09, 2018 at 1:09 PM > From: "Tim Murison" > To: development at qt-project.org > Subject: Re: [Development] Qt for WebAssembly > > > ... > > > > +1, I couldn't agree more with this sentiment. > > I work in software consulting doing mobile and web work. While Qt has a > compelling offering in the mobile and desktop space with Qml, web work > has to be done with another toolkit. These days, react-native or > Angular are derigeur. As a result it is not possible to effectively > evangelize for Qt until Qt can match these technologies. Qt needs a web > solution that is as well adapted to the platform and as flexible as the > existing Qt solutions for mobile and desktop are. As described this 'Qt > for WebAssembly' feature seems to result in web applications that would > not be acceptable in many use cases. > > I'd also like to echo and hopefully amplify what Jason H said about > qmlweb. IMO, this is the solution that Qt should be embracing and > integrating upstream. qmlweb aims to do what Qt has always done, make > cross-platform development easy, efficient and indistinguishable from > native development. Thanks Tim, I'm glad to know I'm not the only one. I *highly* recommend the Wt toolkit (https://www.webtoolkit.eu/widgets) , even if it's not LGPL. The Widget gallery is implemented in Wt, and you can see they have everything, and even a working TreeView! Your QWidget experience will transfer directly, but you'll have to get used to using Boost. And it's fast. I "feels" faster than any other website. If it were me (and wishes were fishes, we'd all eat for free) I'd take on QMLWeb even as a loss-leader. Even though it's not able to be commercialized, having an API that applies across paradigms strengthens the position of Qt. You'll learn it for one paradigm, then be able to carry it into another. Given that there are far more web developers, it' more likely that you'll extend them into a licenseable Qt territory, rather than Qt licensers move out of licensable territory. It's the same thing that Qt has already done - make desktop developers able to target Raspberry Pi Zeros, except on a much, much larger scale. And at the end of the day, whenever I use a web technology I'm grumbling because I'm not using Qt. Qt is a far superior solution. But if it doesn't open itself to a wider audience it'll continue to be obscure (But still used by major companies). But my point is when I say "Qt" people ask what's that? Or they ask "you mean que tee"? (indicating a branding problem) From tim.murison at gmail.com Fri Mar 9 21:05:52 2018 From: tim.murison at gmail.com (Tim Murison) Date: Fri, 09 Mar 2018 15:05:52 -0500 Subject: [Development] Qt for WebAssembly In-Reply-To: References: <1520618941.2022.12.camel@gmail.com> Message-ID: <1520625952.2022.20.camel@gmail.com> > Thanks Tim, I'm glad to know I'm not the only one. I *highly* > recommend the Wt toolkit (https://www.webtoolkit.eu/widgets) , even > if it's not LGPL. The Widget gallery is implemented in Wt, and you > can see they have everything, and even a working TreeView! Your > QWidget experience will transfer directly, but you'll have to get > used to using Boost. And it's fast. I "feels" faster than any other > website. I looked into Wt briefly a few months ago, but for my kind of work, Qml is a much better fit than widgets, hence qmlweb would be ideal if it were integrated into Qt. In fact I'd go as far as saying that not having a qmlweb type of solution has been the primary reason I haven't been able to use Qt in at least 3 commercial products, so anecdotally it is a direct cause of revenue loss for TQtC. > And at the end of the day, whenever I use a web technology I'm > grumbling because I'm not using Qt. Qt is a far superior solution. > But if it doesn't open itself to a wider audience it'll continue to > be obscure (But still used by major companies). But my point is when > I say "Qt" people ask what's that? Or they ask "you mean que tee"? > (indicating a branding problem) I agree with this also. For what it's worth, developer surveys tend to include all sorts of flavour-of-the-week web/mobile toolkits in their lists, and they never have Qt. From jhihn at gmx.com Fri Mar 9 22:28:32 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 9 Mar 2018 22:28:32 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: <1520625952.2022.20.camel@gmail.com> References: <1520618941.2022.12.camel@gmail.com> <1520625952.2022.20.camel@gmail.com> Message-ID: > Sent: Friday, March 09, 2018 at 3:05 PM > From: "Tim Murison" > To: development at qt-project.org > Subject: Re: [Development] Qt for WebAssembly > > > > Thanks Tim, I'm glad to know I'm not the only one. I *highly* > > recommend the Wt toolkit (https://www.webtoolkit.eu/widgets) , even > > if it's not LGPL. The Widget gallery is implemented in Wt, and you > > can see they have everything, and even a working TreeView! Your > > QWidget experience will transfer directly, but you'll have to get > > used to using Boost. And it's fast. I "feels" faster than any other > > website. > > I looked into Wt briefly a few months ago, but for my kind of work, Qml > is a much better fit than widgets, hence qmlweb would be ideal if it > were integrated into Qt. In fact I'd go as far as saying that not > having a qmlweb type of solution has been the primary reason I haven't > been able to use Qt in at least 3 commercial products, so anecdotally > it is a direct cause of revenue loss for TQtC. QML is just amazing rockstar tech, approaching ideals. > > And at the end of the day, whenever I use a web technology I'm > > grumbling because I'm not using Qt. Qt is a far superior solution. > > But if it doesn't open itself to a wider audience it'll continue to > > be obscure (But still used by major companies). But my point is when > > I say "Qt" people ask what's that? Or they ask "you mean que tee"? > > (indicating a branding problem) > > I agree with this also. For what it's worth, developer surveys tend to > include all sorts of flavour-of-the-week web/mobile toolkits in their > lists, and they never have Qt. The RoW (rest of world) has no problem taking their web apps, and wrapping them in WebKit and making an app out of it. (Case, Point: Googles new Chat app is an Electron app) The web is trespassing into the space of applications. It's time the applications trespassed on the web. From Simon.Hausmann at qt.io Sun Mar 11 19:52:29 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sun, 11 Mar 2018 18:52:29 +0000 Subject: [Development] PSA: qtdeclarative and qt5 broken Message-ID: Hi, Any attempt to stage a change for declarative or qt5 in 5.9 or later will fail with a test failure in the ecmascript tests. Do not bother restaging, it will continue to fail until a fix is submitted. The issue is related to the tests expecting to run in pacific time, the CI machine being in finish time, since today the US obeys summer time and the tests attempt at overriding the time zone Qt detects from the system to be PST fails and results in a test failing. Simon From Simon.Hausmann at qt.io Mon Mar 12 09:29:13 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 12 Mar 2018 08:29:13 +0000 Subject: [Development] PSA: qtdeclarative and qt5 broken In-Reply-To: References: Message-ID: Hi, I filed QTBUG-67010 to track the issue. Preliminary investigation suggests that this only affects 5.11 and dev as a consequence of the TZ changes introduced with QTBUG-56787. Simon ________________________________ From: Development on behalf of Simon Hausmann Sent: Sunday, March 11, 2018 7:52:29 PM To: development at qt-project.org Subject: [Development] PSA: qtdeclarative and qt5 broken Hi, Any attempt to stage a change for declarative or qt5 in 5.9 or later will fail with a test failure in the ecmascript tests. Do not bother restaging, it will continue to fail until a fix is submitted. The issue is related to the tests expecting to run in pacific time, the CI machine being in finish time, since today the US obeys summer time and the tests attempt at overriding the time zone Qt detects from the system to be PST fails and results in a test failing. Simon _______________________________________________ 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 yugiohjcj-mailinglist at laposte.net Mon Mar 12 11:07:51 2018 From: yugiohjcj-mailinglist at laposte.net (YuGiOhJCJ Mailing-List) Date: Mon, 12 Mar 2018 11:07:51 +0100 Subject: [Development] ERROR: Feature 'webengine-system-libwebp' was enabled, but the pre-condition 'libs.webengine-webp' failed. Message-ID: <20180312110751.ac70277c266f0a80866dc211@laposte.net> Hello, I am trying to build Qt 5.10.1 on Slackware64 14.2 with the "-system-webengine-webp" option and libwebp 0.6.1: --- $ ./configure -v \ [...] -system-assimp \ -system-doubleconversion \ -system-freetype \ -system-harfbuzz \ -system-libjpeg \ -system-libpng \ -system-pcre \ -system-sqlite \ -system-xcb \ -system-webengine-icu \ -system-webengine-ffmpeg \ -system-webengine-opus \ -system-webengine-webp \ -system-zlib \ [...] -pulseaudio [...] Note: Also available for Linux: linux-clang linux-icc Note: -headerdir is not a subdirectory of -prefix. Note: -libdir is not a subdirectory of -prefix. Note: -docdir is not a subdirectory of -prefix. Note: -optimized-tools is not useful in -release mode. Note: Dropped compiler flags '-pthread' when detecting library 'glib'. Note: Dropped compiler flags '-pthread' when detecting library 'gtk3'. Note: No wayland-egl support detected. Cross-toolkit compatibility disabled. Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer'. Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer_app'. Note: Dropped compiler flags '-pthread' when detecting library 'webengine-protobuf'. ERROR: Feature 'webengine-system-libwebp' was enabled, but the pre-condition 'libs.webengine-webp' failed. ERROR: Feature 'webengine-system-ffmpeg' was enabled, but the pre-condition 'libs.webengine-ffmpeg && features.webengine-system-opus && features.webengine-system-libwebp' failed. --- As you can see in the output above, the error is about the libwebp library that is not found (or at least that is not working correctly). However, I found the test file that is checking the libwebp library and I tried it manually: --- $ cd qtimageformats/config.tests/libwebp $ qmake libwebp.pro $ make g++ -c -pipe -O2 -Wall -W -I/usr/lib64/qt/mkspecs/linux-g++ -I. -o libwebp.o libwebp.cpp libwebp.cpp: In function ‘int main(int, char**)’: libwebp.cpp:40:20: warning: unused variable ‘output_buffer’ [-Wunused-variable] WebPDecBuffer *output_buffer = &config.output; ^~~~~~~~~~~~~ libwebp.cpp:41:28: warning: unused variable ‘bitstream’ [-Wunused-variable] WebPBitstreamFeatures *bitstream = &config.input; ^~~~~~~~~ libwebp.cpp:42:17: warning: variable ‘picture’ set but not used [-Wunused-but-set-variable] WebPPicture picture; ^~~~~~~ libwebp.cpp:44:16: warning: variable ‘config2’ set but not used [-Wunused-but-set-variable] WebPConfig config2; ^~~~~~~ libwebp.cpp:47:18: warning: unused variable ‘demuxer’ [-Wunused-variable] WebPDemuxer *demuxer = WebPDemux(&data); ^~~~~~~ libwebp.cpp:48:18: warning: variable ‘iter’ set but not used [-Wunused-but-set-variable] WebPIterator iter; ^~~~ --- So, the test file is working. I am able to build it manually. Why the Qt build system is complaining about this library installed on my system please? Thank you. Best regards. From michal.klocek at qt.io Mon Mar 12 11:29:40 2018 From: michal.klocek at qt.io (Michal Klocek) Date: Mon, 12 Mar 2018 11:29:40 +0100 Subject: [Development] ERROR: Feature 'webengine-system-libwebp' was enabled, but the pre-condition 'libs.webengine-webp' failed. In-Reply-To: <20180312110751.ac70277c266f0a80866dc211@laposte.net> References: <20180312110751.ac70277c266f0a80866dc211@laposte.net> Message-ID: <9fba0ad0-9032-0cd9-47c7-f2b6c0290b72@qt.io> Hi With 'system-webengine-webp' option you are trying to force qwebenigne to use system webp. WebEngine uses pkg-config for webp, there is no separate test, you can check it yourself with: pkg-config --libs libwebp libwebpmux libwebpdemux Br Michal On 03/12/2018 11:07 AM, YuGiOhJCJ Mailing-List via Development wrote: > Hello, > > I am trying to build Qt 5.10.1 on Slackware64 14.2 with the "-system-webengine-webp" option and libwebp 0.6.1: > --- > $ ./configure -v \ > [...] > -system-assimp \ > -system-doubleconversion \ > -system-freetype \ > -system-harfbuzz \ > -system-libjpeg \ > -system-libpng \ > -system-pcre \ > -system-sqlite \ > -system-xcb \ > -system-webengine-icu \ > -system-webengine-ffmpeg \ > -system-webengine-opus \ > -system-webengine-webp \ > -system-zlib \ > [...] > -pulseaudio > [...] > Note: Also available for Linux: linux-clang linux-icc > > Note: -headerdir is not a subdirectory of -prefix. > Note: -libdir is not a subdirectory of -prefix. > Note: -docdir is not a subdirectory of -prefix. > > Note: -optimized-tools is not useful in -release mode. > > Note: Dropped compiler flags '-pthread' when detecting library 'glib'. > > Note: Dropped compiler flags '-pthread' when detecting library 'gtk3'. > > Note: No wayland-egl support detected. Cross-toolkit compatibility disabled. > > Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer'. > > Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer_app'. > > Note: Dropped compiler flags '-pthread' when detecting library 'webengine-protobuf'. > > ERROR: Feature 'webengine-system-libwebp' was enabled, but the pre-condition 'libs.webengine-webp' failed. > > ERROR: Feature 'webengine-system-ffmpeg' was enabled, but the pre-condition 'libs.webengine-ffmpeg && features.webengine-system-opus && features.webengine-system-libwebp' failed. > --- > > As you can see in the output above, the error is about the libwebp library that is not found (or at least that is not working correctly). > > However, I found the test file that is checking the libwebp library and I tried it manually: > --- > $ cd qtimageformats/config.tests/libwebp > $ qmake libwebp.pro > $ make > g++ -c -pipe -O2 -Wall -W -I/usr/lib64/qt/mkspecs/linux-g++ -I. -o libwebp.o libwebp.cpp > libwebp.cpp: In function ‘int main(int, char**)’: > libwebp.cpp:40:20: warning: unused variable ‘output_buffer’ [-Wunused-variable] > WebPDecBuffer *output_buffer = &config.output; > ^~~~~~~~~~~~~ > libwebp.cpp:41:28: warning: unused variable ‘bitstream’ [-Wunused-variable] > WebPBitstreamFeatures *bitstream = &config.input; > ^~~~~~~~~ > libwebp.cpp:42:17: warning: variable ‘picture’ set but not used [-Wunused-but-set-variable] > WebPPicture picture; > ^~~~~~~ > libwebp.cpp:44:16: warning: variable ‘config2’ set but not used [-Wunused-but-set-variable] > WebPConfig config2; > ^~~~~~~ > libwebp.cpp:47:18: warning: unused variable ‘demuxer’ [-Wunused-variable] > WebPDemuxer *demuxer = WebPDemux(&data); > ^~~~~~~ > libwebp.cpp:48:18: warning: variable ‘iter’ set but not used [-Wunused-but-set-variable] > WebPIterator iter; > ^~~~ > --- > > So, the test file is working. > I am able to build it manually. > > Why the Qt build system is complaining about this library installed on my system please? > > Thank you. > Best regards. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Morten.Sorvig at qt.io Mon Mar 12 11:58:09 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Mon, 12 Mar 2018 10:58:09 +0000 Subject: [Development] Qt for WebAssembly In-Reply-To: References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> Message-ID: <461FB813-CE8D-4956-9120-BFEC97E70094@qt.io> > On 9 Mar 2018, at 15:53, Jason H wrote: > > > I don't want to steal your thunder, but what is fundamentally different about this approach this time? Why will the results be any different? Oh, who knows what will happen. But there are indicators that this time may be different: * WebAssembly is a web standard * General support for web applications is getting better (e.g. service workers) * Canvas-rendering web apps now exist (Google Sheets) * Better connectivity makes “large” web apps more feasible. The project _may_ end up providing limited value to Qt users, but I think it would be a mistake to conclude so up front, Morten From Morten.Sorvig at qt.io Mon Mar 12 12:29:08 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Mon, 12 Mar 2018 11:29:08 +0000 Subject: [Development] Qt for WebAssembly In-Reply-To: <1520618941.2022.12.camel@gmail.com> References: <1520618941.2022.12.camel@gmail.com> Message-ID: > On 9 Mar 2018, at 19:09, Tim Murison wrote: > I'd also like to echo and hopefully amplify what Jason H said about > qmlweb. IMO, this is the solution that Qt should be embracing and > integrating upstream. qmlweb aims to do what Qt has always done, make > cross-platform development easy, efficient and indistinguishable from > native development. I think qmlweb and Qt for wasm are fundamentally different enough (reimplementing Qt Quick vs recompiling it for a new platform) that they are not mutually exclusive. We could accept either or both upstream, It could be interesting to make them API-compatible so that users can move between them with minimal effort. For example by providing a “QtQuick.QMLEngine()” Javascript API that can be used interchangeably with “QmlWeb.QMLEngine()”. var div = document.getElementById('embed'); var engine = new QmlWeb.QMLEngine(div); engine.loadFile('qml/main.qml'); engine.start(); Morten From jhihn at gmx.com Mon Mar 12 14:42:51 2018 From: jhihn at gmx.com (Jason H) Date: Mon, 12 Mar 2018 14:42:51 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: <461FB813-CE8D-4956-9120-BFEC97E70094@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <461FB813-CE8D-4956-9120-BFEC97E70094@qt.io> Message-ID: > Oh, who knows what will happen. But there are indicators that this time > may be different: > > 1. WebAssembly is a web standard > 2. General support for web applications is getting better (e.g. service workers) > 3. Canvas-rendering web apps now exist (Google Sheets) > 4. Better connectivity makes “large” web apps more feasible. > > 5. The project _may_ end up providing limited value to Qt users, but I think > it would be a mistake to conclude so up front, I have taken the liberty of changing your bulleted list to an ordered one. 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims. 2. I have no comment 3. Such apps are designed from ground-up for canvas. I don't know that a Qt app will scale accordingly. I tried WebGL for my app and it simply did not work. Maybe there are large gains, but he approaches are in the same vein. 4. a. While true, it hasn't been exponentially true like with most things in computing ( in terms of average speed https://www.pcmag.com/Fastest-Mobile-Networks ) Maybe with 5G that will change. Additionally, unless you can very slickly progressively load it, no one wants a 5-second delay or even 3 second delay. It's also rather biased to first-world countries and metropolitain customers. I doubt that's who Nokia had in mind for their "next billion". (The point being while now not technically limited by spec, you're still limited in practice) b. Another point here is that the mobile web is taking off with less powerful ARM processors... c. on Data plans that meter data... 5. Given the effort required it may be considered "low-hanging fruit" and provide value in the interim. However the maximally utilitarian solution is to stop cramming binaries into browsers, and run apps that properly utilize the browser no matter how twisted standards it uses. Given the limitations outlined above, and considering the ecosystem implications, I am left to conclude that Qt needs to include a proper web component. From jhihn at gmx.com Mon Mar 12 14:43:42 2018 From: jhihn at gmx.com (Jason H) Date: Mon, 12 Mar 2018 14:43:42 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: References: <1520618941.2022.12.camel@gmail.com> Message-ID: > Sent: Monday, March 12, 2018 at 7:29 AM > From: "Morten Sørvig" > To: "Qt Project Development Mailing-List" > Subject: Re: [Development] Qt for WebAssembly > > > > > On 9 Mar 2018, at 19:09, Tim Murison wrote: > > I'd also like to echo and hopefully amplify what Jason H said about > > qmlweb. IMO, this is the solution that Qt should be embracing and > > integrating upstream. qmlweb aims to do what Qt has always done, make > > cross-platform development easy, efficient and indistinguishable from > > native development. > > > I think qmlweb and Qt for wasm are fundamentally different enough > (reimplementing Qt Quick vs recompiling it for a new platform) that they > are not mutually exclusive. We could accept either or both upstream, > > It could be interesting to make them API-compatible so that users can > move between them with minimal effort. For example by providing a “QtQuick.QMLEngine()” > Javascript API that can be used interchangeably with “QmlWeb.QMLEngine()”. > > var div = document.getElementById('embed'); > var engine = new QmlWeb.QMLEngine(div); > engine.loadFile('qml/main.qml'); > engine.start(); Yes, exactly. From yugiohjcj-mailinglist at laposte.net Mon Mar 12 15:47:13 2018 From: yugiohjcj-mailinglist at laposte.net (YuGiOhJCJ Mailing-List) Date: Mon, 12 Mar 2018 15:47:13 +0100 Subject: [Development] ERROR: Feature 'webengine-system-libwebp' was enabled, but the pre-condition 'libs.webengine-webp' failed. In-Reply-To: <9fba0ad0-9032-0cd9-47c7-f2b6c0290b72@qt.io> References: <20180312110751.ac70277c266f0a80866dc211@laposte.net> <9fba0ad0-9032-0cd9-47c7-f2b6c0290b72@qt.io> Message-ID: <20180312154713.d35e441151f3ffb3c7c8730f@laposte.net> Thanks! I did: $ pkg-config --libs libwebp libwebpmux libwebpdemux Package libwebpmux was not found in the pkg-config search path. Perhaps you should add the directory containing `libwebpmux.pc' to the PKG_CONFIG_PATH environment variable No package 'libwebpmux' found Then I saw that libwebpmux was not found. The reason is that my libwebp library was built without the "--enable-libwebpmux" option. So, I rebuilt my libwebp library: $ ./configure \ --disable-static \ --enable-shared \ [...] --enable-libwebpmux \ [...] Now, libwebpmux is found: $ pkg-config --libs libwebp libwebpmux libwebpdemux -lwebpmux -lwebpdemux -lwebp And the Qt build system is happy: --- $ ./configure -v \ [...] -system-assimp \ -system-doubleconversion \ -system-freetype \ -system-harfbuzz \ -system-libjpeg \ -system-libpng \ -system-pcre \ -system-sqlite \ -system-xcb \ -system-webengine-icu \ -system-webengine-ffmpeg \ -system-webengine-opus \ -system-webengine-webp \ -system-zlib \ [...] -pulseaudio [...] Note: Also available for Linux: linux-clang linux-icc Note: -headerdir is not a subdirectory of -prefix. Note: -libdir is not a subdirectory of -prefix. Note: -docdir is not a subdirectory of -prefix. Note: -optimized-tools is not useful in -release mode. Note: Dropped compiler flags '-pthread' when detecting library 'glib'. Note: Dropped compiler flags '-pthread' when detecting library 'gtk3'. Note: No wayland-egl support detected. Cross-toolkit compatibility disabled. Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer'. Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer_app'. Note: Dropped compiler flags '-pthread' when detecting library 'webengine-protobuf'. Qt is now configured for building. Just run 'make'. Once everything is built, you must run 'make install'. Qt will be installed into '/usr/lib64/qt5'. Prior to reconfiguration, make sure you remove any leftovers from the previous build. --- Problem fixed! On Mon, 12 Mar 2018 11:29:40 +0100 Michal Klocek wrote: > Hi > > With 'system-webengine-webp' option you are trying to force qwebenigne > to use system webp. WebEngine uses pkg-config for webp, there is no > separate test, you can check it yourself with: > > pkg-config --libs libwebp libwebpmux libwebpdemux > > Br > > Michal > > On 03/12/2018 11:07 AM, YuGiOhJCJ Mailing-List via Development wrote: > > Hello, > > > > I am trying to build Qt 5.10.1 on Slackware64 14.2 with the "-system-webengine-webp" option and libwebp 0.6.1: > > --- > > $ ./configure -v \ > > [...] > > -system-assimp \ > > -system-doubleconversion \ > > -system-freetype \ > > -system-harfbuzz \ > > -system-libjpeg \ > > -system-libpng \ > > -system-pcre \ > > -system-sqlite \ > > -system-xcb \ > > -system-webengine-icu \ > > -system-webengine-ffmpeg \ > > -system-webengine-opus \ > > -system-webengine-webp \ > > -system-zlib \ > > [...] > > -pulseaudio > > [...] > > Note: Also available for Linux: linux-clang linux-icc > > > > Note: -headerdir is not a subdirectory of -prefix. > > Note: -libdir is not a subdirectory of -prefix. > > Note: -docdir is not a subdirectory of -prefix. > > > > Note: -optimized-tools is not useful in -release mode. > > > > Note: Dropped compiler flags '-pthread' when detecting library 'glib'. > > > > Note: Dropped compiler flags '-pthread' when detecting library 'gtk3'. > > > > Note: No wayland-egl support detected. Cross-toolkit compatibility disabled. > > > > Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer'. > > > > Note: Dropped compiler flags '-pthread' when detecting library 'gstreamer_app'. > > > > Note: Dropped compiler flags '-pthread' when detecting library 'webengine-protobuf'. > > > > ERROR: Feature 'webengine-system-libwebp' was enabled, but the pre-condition 'libs.webengine-webp' failed. > > > > ERROR: Feature 'webengine-system-ffmpeg' was enabled, but the pre-condition 'libs.webengine-ffmpeg && features.webengine-system-opus && features.webengine-system-libwebp' failed. > > --- > > > > As you can see in the output above, the error is about the libwebp library that is not found (or at least that is not working correctly). > > > > However, I found the test file that is checking the libwebp library and I tried it manually: > > --- > > $ cd qtimageformats/config.tests/libwebp > > $ qmake libwebp.pro > > $ make > > g++ -c -pipe -O2 -Wall -W -I/usr/lib64/qt/mkspecs/linux-g++ -I. -o libwebp.o libwebp.cpp > > libwebp.cpp: In function ‘int main(int, char**)’: > > libwebp.cpp:40:20: warning: unused variable ‘output_buffer’ [-Wunused-variable] > > WebPDecBuffer *output_buffer = &config.output; > > ^~~~~~~~~~~~~ > > libwebp.cpp:41:28: warning: unused variable ‘bitstream’ [-Wunused-variable] > > WebPBitstreamFeatures *bitstream = &config.input; > > ^~~~~~~~~ > > libwebp.cpp:42:17: warning: variable ‘picture’ set but not used [-Wunused-but-set-variable] > > WebPPicture picture; > > ^~~~~~~ > > libwebp.cpp:44:16: warning: variable ‘config2’ set but not used [-Wunused-but-set-variable] > > WebPConfig config2; > > ^~~~~~~ > > libwebp.cpp:47:18: warning: unused variable ‘demuxer’ [-Wunused-variable] > > WebPDemuxer *demuxer = WebPDemux(&data); > > ^~~~~~~ > > libwebp.cpp:48:18: warning: variable ‘iter’ set but not used [-Wunused-but-set-variable] > > WebPIterator iter; > > ^~~~ > > --- > > > > So, the test file is working. > > I am able to build it manually. > > > > Why the Qt build system is complaining about this library installed on my system please? > > > > Thank you. > > Best regards. > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > From sergio.martins at kdab.com Mon Mar 12 18:10:35 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 12 Mar 2018 17:10:35 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models Message-ID: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Hi, Although the wiki says Qt Models don't have a maintainer I'd say David Faure has been an unofficial maintainer. David is one of the top contributors to model related code and is someone you'll always want to add as reviewer. He's well known in the community and already maintains QtXmlPatterns, Qt mimetypes and Qt3Support. Disclaimer: David works with me at KDAB. (And if you're wondering if KDAB has any plans for this module, the answer is no. In fact I hope it remains low change volume). Finally, a big thanks to the previous maintainer, Stephen Kelly, who did a great job, both on Qt and KDE models! 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 edward.welbourne at qt.io Mon Mar 12 18:51:42 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 12 Mar 2018 17:51:42 +0000 Subject: [Development] PSA: qtdeclarative and qt5 broken In-Reply-To: References: , Message-ID: Simon Hausmann (12 March 2018 09:29) > I filed QTBUG-67010 to track the issue. Preliminary investigation suggests that this only affects 5.11 and dev as a consequence of the TZ changes introduced with QTBUG-56787. The test was flawed. https://github.com/tc39/test262/issues/1486 Closed (for us) by: https://codereview.qt-project.org/222906 https://codereview.qt-project.org/222909 so qtdeclarative should now be working OK on 5.11. Naturally, dev shall need an upmerge ... Eddy. From thiago.macieira at intel.com Mon Mar 12 18:59:11 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 12 Mar 2018 10:59:11 -0700 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <19288358.MfxmWPkYai@tjmaciei-mobl1> On Monday, 12 March 2018 10:10:35 PDT Sérgio Martins wrote: > Hi, > > > Although the wiki says Qt Models don't have a maintainer I'd say David > Faure has been an unofficial maintainer. By Qt Models, do you mean the Item Models? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sergio.martins at kdab.com Mon Mar 12 19:20:21 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 12 Mar 2018 18:20:21 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <19288358.MfxmWPkYai@tjmaciei-mobl1> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> <19288358.MfxmWPkYai@tjmaciei-mobl1> Message-ID: <59b286add1562fedb096d7c81f078a68@kdab.com> On 2018-03-12 17:59, Thiago Macieira wrote: > On Monday, 12 March 2018 10:10:35 PDT Sérgio Martins wrote: >> Hi, >> >> >> Although the wiki says Qt Models don't have a maintainer I'd say David >> Faure has been an unofficial maintainer. > > By Qt Models, do you mean the Item Models? Yes 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 Mon Mar 12 20:00:49 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 12 Mar 2018 12:00:49 -0700 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <59b286add1562fedb096d7c81f078a68@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> <19288358.MfxmWPkYai@tjmaciei-mobl1> <59b286add1562fedb096d7c81f078a68@kdab.com> Message-ID: <1971707.4fGTQ9HxgB@tjmaciei-mobl1> On Monday, 12 March 2018 11:20:21 PDT Sérgio Martins wrote: > On 2018-03-12 17:59, Thiago Macieira wrote: > > On Monday, 12 March 2018 10:10:35 PDT Sérgio Martins wrote: > >> Hi, > >> > >> > >> Although the wiki says Qt Models don't have a maintainer I'd say David > >> Faure has been an unofficial maintainer. > > > > By Qt Models, do you mean the Item Models? > > Yes Then yes, by all means, +1. I really need help with item models in QtCore, as I have absolutely no clue how to maintain them. Any bug reports I get in it get reassigned to "Widgets: Item Views" so at least someone will take a look. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lorn.potter at gmail.com Mon Mar 12 20:38:40 2018 From: lorn.potter at gmail.com (Lorn Potter) Date: Tue, 13 Mar 2018 05:38:40 +1000 Subject: [Development] Qt for WebAssembly In-Reply-To: References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <461FB813-CE8D-4956-9120-BFEC97E70094@qt.io> Message-ID: <69f69bd2-8e69-e061-1078-71f514283810@gmail.com> On 03/12/2018 11:42 PM, Jason H wrote: > 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims. In my experience WebAssembly is much more performant than asmjs, wasm also creates binaries that are at least 10x less huge than asmjs. > Given the limitations outlined above, and considering the ecosystem >implications, I am left to conclude that Qt needs to include a proper >web component. as they say... patches welcome :) From samuel.gaist at edeltech.ch Mon Mar 12 21:38:18 2018 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 12 Mar 2018 21:38:18 +0100 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <32DB5109-5AA2-4F64-9475-3B7440B47B0E@edeltech.ch> Big +1 Cheers, Samuel > On 12 Mar 2018, at 18:10, Sérgio Martins wrote: > > Hi, > > > Although the wiki says Qt Models don't have a maintainer I'd say David Faure has been an unofficial maintainer. > David is one of the top contributors to model related code and is someone you'll always want to add as reviewer. > > He's well known in the community and already maintains QtXmlPatterns, Qt mimetypes and Qt3Support. > > Disclaimer: David works with me at KDAB. > (And if you're wondering if KDAB has any plans for this module, the answer is no. In fact I hope it remains low change volume). > > > Finally, a big thanks to the previous maintainer, Stephen Kelly, who did a great job, both on Qt and KDE models! > > > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From rafael.roquetto at kdab.com Mon Mar 12 22:41:20 2018 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 13 Mar 2018 07:41:20 +1000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <20180312214119.GA15325@polaris.localdomain> +1 from me On Mon, Mar 12, 2018 at 05:10:35PM +0000, Sérgio Martins wrote: > Hi, > > > Although the wiki says Qt Models don't have a maintainer I'd say David Faure > has been an unofficial maintainer. > David is one of the top contributors to model related code and is someone > you'll always want to add as reviewer. > > He's well known in the community and already maintains QtXmlPatterns, Qt > mimetypes and Qt3Support. > > Disclaimer: David works with me at KDAB. > (And if you're wondering if KDAB has any plans for this module, the answer > is no. In fact I hope it remains low change volume). > > > Finally, a big thanks to the previous maintainer, Stephen Kelly, who did a > great job, both on Qt and KDE models! > > > 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 -- 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 - The Qt, C++ and OpenGL 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 kde at carewolf.com Mon Mar 12 23:41:17 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 12 Mar 2018 23:41:17 +0100 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <6372441.uoPgxEIKk4@twilight> +1 From annulen at yandex.ru Mon Mar 12 23:46:28 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 13 Mar 2018 01:46:28 +0300 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <3010371520894788@web35j.yandex.ru> 12.03.2018, 20:10, "Sérgio Martins" : > Hi, > > Although the wiki says Qt Models don't have a maintainer I'd say David > Faure has been an unofficial maintainer. > David is one of the top contributors to model related code and is > someone you'll always want to add as reviewer. > > He's well known in the community and already maintains QtXmlPatterns, Qt > mimetypes and Qt3Support. > > Disclaimer: David works with me at KDAB. > (And if you're wondering if KDAB has any plans for this module, the > answer is no. In fact I hope it remains low change volume). > > Finally, a big thanks to the previous maintainer, Stephen Kelly, who did > a great job, both on Qt and KDE models! +1 > > 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 jhihn at gmx.com Tue Mar 13 02:15:35 2018 From: jhihn at gmx.com (Jason H) Date: Tue, 13 Mar 2018 02:15:35 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: <69f69bd2-8e69-e061-1078-71f514283810@gmail.com> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <461FB813-CE8D-4956-9120-BFEC97E70094@qt.io> <69f69bd2-8e69-e061-1078-71f514283810@gmail.com> Message-ID: > On 03/12/2018 11:42 PM, Jason H wrote: > > 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims. > > In my experience WebAssembly is much more performant than asmjs, wasm > also creates binaries that are at least 10x less huge than asmjs. Active Qt was about 12mb IIRC for Tetris or samegame we're not we're still looking at the same sizes. > > Given the limitations outlined above, and considering the ecosystem > >implications, I am left to conclude that Qt needs to include a proper > >web component. > > as they say... patches welcome :) Sure. But how much refactoring is Qt going to accept without a commitment to the web agenda? How much prioritization will it be allowed? Will the Qt company support it as a real part of Qt? It's easy to say patches welcome, when there are none, but when there's a deluge will that love still be there? What if I got the QmlWeb people to bring it into Qt, how soon can we release it with fanfare and call Qt a web development platform? From bogdan at kdab.com Tue Mar 13 06:24:59 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Tue, 13 Mar 2018 07:24:59 +0200 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <5572882.q2K6GKNTYH@debian> +1 from me. Cheers, BogDan. În ziua de luni, 12 martie 2018, la 19:10:35 EET, Sérgio Martins a scris: > Hi, > > > Although the wiki says Qt Models don't have a maintainer I'd say David > Faure has been an unofficial maintainer. > David is one of the top contributors to model related code and is > someone you'll always want to add as reviewer. > > He's well known in the community and already maintains QtXmlPatterns, Qt > mimetypes and Qt3Support. > > Disclaimer: David works with me at KDAB. > (And if you're wondering if KDAB has any plans for this module, the > answer is no. In fact I hope it remains low change volume). > > > Finally, a big thanks to the previous maintainer, Stephen Kelly, who did > a great job, both on Qt and KDE models! > > > Regards, From tuukka.turunen at qt.io Tue Mar 13 07:39:36 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 13 Mar 2018 06:39:36 +0000 Subject: [Development] Qt for WebAssembly In-Reply-To: References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <461FB813-CE8D-4956-9120-BFEC97E70094@qt.io> <69f69bd2-8e69-e061-1078-71f514283810@gmail.com> Message-ID: <7D72FEDF-15A2-41F3-993D-E24CC215AC1A@qt.io> On 13/03/2018, 3.15, "Development on behalf of Jason H" wrote: > > Sure. But how much refactoring is Qt going to accept without a commitment to the web agenda? How much prioritization will it be allowed? Will the Qt company > support it as a real part of Qt? It's easy to say patches welcome, when there are none, but when there's a deluge will that love still be there? Currently this is still research, as I explained in my recent roadmap blog post. But there certainly is a lot of business interest towards this, and we are making good progress technically. Even rather complex and dynamic UIs work decently on a desktop machine. At least with Chrome, unfortunately not all browsers are yet on par with it when it comes to WebAssembly. Assumption is that this improves. Yours, Tuukka From alexei.fedotov at gmail.com Tue Mar 13 10:18:42 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 13 Mar 2018 12:18:42 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: <190050597.bTpa5menfU@tjmaciei-mobl1> References: <4942212.GksEE0fiAM@tjmaciei-mobl1> <190050597.bTpa5menfU@tjmaciei-mobl1> Message-ID: Thiago, thanks. The build finally passed for me after replacing perl with ActivePerl and skipping "qtscript". I'm currently trying to figure out how -prefix works for MSYS. -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Tue, Mar 6, 2018 at 8:18 PM, Thiago Macieira wrote: > On Tuesday, 6 March 2018 07:42:59 PST Alexei Fedotov wrote: >> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB > [cut] >> arch/qatomic_bootstrap.h -o .obj/header_qatomic_bootstrap.obj > > This is a header check of a file that shouldn't be header-checked. The header > in question (qatomic_bootstrap.h) has: > > #pragma qt_sync_skip_header_check > > So the problem is syncqt. Please delete your build, verify that Perl is > properly installed in your environment (it cannot be MSYS's) and and that you > don't have a stale syncqt somewhere. > > -- > 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 Morten.Sorvig at qt.io Tue Mar 13 10:21:35 2018 From: Morten.Sorvig at qt.io (=?iso-8859-1?Q?Morten_S=F8rvig?=) Date: Tue, 13 Mar 2018 09:21:35 +0000 Subject: [Development] Qt for WebAssembly In-Reply-To: References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <461FB813-CE8D-4956-9120-BFEC97E70094@qt.io> <69f69bd2-8e69-e061-1078-71f514283810@gmail.com> Message-ID: <8865D214-07CF-4B59-9F3A-CE3F42B8E60F@qt.io> > On 13 Mar 2018, at 02:15, Jason H wrote: > >> On 03/12/2018 11:42 PM, Jason H wrote: >>> 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims. >> >> In my experience WebAssembly is much more performant than asmjs, wasm >> also creates binaries that are at least 10x less huge than asmjs. > > Active Qt was about 12mb IIRC for Tetris or samegame we're not we're still looking at the same sizes. The download size for the current build of samegamne.wasm is 4.4mb. (compressed with brotli) Morten From announce at qt-project.org Tue Mar 13 13:11:11 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 13 Mar 2018 12:11:11 +0000 Subject: [Development] [Announce] Qt Creator 4.5.2 released Message-ID: We are happy to announce the release of Qt Creator 4.5.2! https://blog.qt.io/blog/2018/03/13/qt-creator-4-5-2-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From hsia.sun at gmail.com Tue Mar 13 14:39:54 2018 From: hsia.sun at gmail.com (=?UTF-8?B?5a2r5aSP?=) Date: Tue, 13 Mar 2018 21:39:54 +0800 Subject: [Development] GSoC 2018 Idea: a widget for 2D/3D image display Message-ID: Hello all, I am a student interested in participating in Google Summer of Code 2018 with Qt. As a Qt user before, I used Qt as the UI framework to develop my application in 3D medical image analysis and video processing. But I found there's no commonly used Qt widget for image display and interaction, not to mention a standard pipeline for 3D image processing. To my understanding, most 3D image jobs are done as multiple 2D image job. So I would like to develop a Qt widget that could display and maintain a 3D image dataset. Most commonly used interaction methods and possible APIs should also be included. I want to make this widget a standard widget for all common 2D/3D images and should include most image and video I/O, for example, OpenCV and GDCM. I wonder whether this idea could be considered as a GSoC project. Or on what points may I improve it? Thank you all. Best regards, Xia Sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Tue Mar 13 14:56:44 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 13 Mar 2018 14:56:44 +0100 Subject: [Development] GSoC 2018 Idea: a widget for 2D/3D image display In-Reply-To: References: Message-ID: > But I found there's no commonly used Qt widget for image display and interaction, not to mention a standard pipeline for 3D image processing. Isn't VTK commonly used for this ? AFAIK it has multiple Qt widget integrations, including QVTKWidget : https://www.vtk.org/doc/nightly/html/classQVTKWidget.html ------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Mar 13, 2018 at 2:39 PM, 孫夏 wrote: > Hello all, > > I am a student interested in participating in Google Summer of Code 2018 > with Qt. > > As a Qt user before, I used Qt as the UI framework to develop my > application in 3D medical image analysis and video processing. But I found > there's no commonly used Qt widget for image display and interaction, not > to mention a standard pipeline for 3D image processing. > > To my understanding, most 3D image jobs are done as multiple 2D image job. > So I would like to develop a Qt widget that could display and maintain a 3D > image dataset. Most commonly used interaction methods and possible APIs > should also be included. I want to make this widget a standard widget for > all common 2D/3D images and should include most image and video I/O, for > example, OpenCV and GDCM. > > I wonder whether this idea could be considered as a GSoC project. Or on > what points may I improve it? > > Thank you all. > > Best regards, > Xia Sun > > _______________________________________________ > 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 paolo.angelelli at qt.io Tue Mar 13 15:00:32 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Tue, 13 Mar 2018 15:00:32 +0100 Subject: [Development] GSoC 2018 Idea: a widget for 2D/3D image display In-Reply-To: References: Message-ID: <20180313150032.798ccc3d@qdesktop> Hi Xia, in my opinion the project you describe seems a very specific widget, that perhaps would fit best in a Qt-based visualization framework than in Qt itself. After all, where in Qt would such a flexible medical visualization widget live? QtWidgets is supposed to contain only building blocks such as QOpenGLWidget, that you would use as a basis of your specialized widget. Maybe you could look into something like inviwo.org, for creating medical data processing pipelines. best, Paolo On Tue, 13 Mar 2018 21:39:54 +0800 孫夏 wrote: > Hello all, > > I am a student interested in participating in Google Summer of Code 2018 > with Qt. > > As a Qt user before, I used Qt as the UI framework to develop my > application in 3D medical image analysis and video processing. But I found > there's no commonly used Qt widget for image display and interaction, not > to mention a standard pipeline for 3D image processing. > > To my understanding, most 3D image jobs are done as multiple 2D image job. > So I would like to develop a Qt widget that could display and maintain a 3D > image dataset. Most commonly used interaction methods and possible APIs > should also be included. I want to make this widget a standard widget for > all common 2D/3D images and should include most image and video I/O, for > example, OpenCV and GDCM. > > I wonder whether this idea could be considered as a GSoC project. Or on > what points may I improve it? > > Thank you all. > > Best regards, > Xia Sun From aapo.keskimolo at qt.io Tue Mar 13 15:25:27 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Tue, 13 Mar 2018 14:25:27 +0000 Subject: [Development] Coin maintenance notification Message-ID: Coin production will be updated with new baseline at 16:30. If you want to see what changes are part of the update, you can look at the attached change list. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20180313.log Type: application/octet-stream Size: 11744 bytes Desc: product_baseline_20180313.log URL: From svenn-arne.dragly at qt.io Tue Mar 13 15:27:33 2018 From: svenn-arne.dragly at qt.io (Svenn-Arne Dragly) Date: Tue, 13 Mar 2018 15:27:33 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> Message-ID: <7c399488-19b8-6814-d7bc-990d0669db11@qt.io> On 03/09/2018 03:53 PM, Jason H wrote: > While I am excited about this, I still wonder that it's the right approach. By right, I mean scalable. > After evaluating the WebGL platform (which I was excited about as well) had having extreme performance issues, I foresee that this will has performance issues as well, because of one defect: You're rendering to a canvas what the browser can draw natively. If people want to serve Qt apps to the web, then the best approach (IMHO) is to use a server to send a client which is defined in HTML5 (name clash with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a QPainter). This will leverage the browser in the best way possible, and let it handle the low-level drawing. To this end QMLWeb is an existing approach (https://github.com/qmlweb/qmlweb). I think this depends on the use case. QMLWeb is doing a great job of bringing the QML language to web applications, which I personally find much more appealing than working with HTML and CSS. And it is probably best to leverage the browser to draw efficiently in cases where using DOM elements makes sense. This is likely the case for social media applications, news readers, ticket services, database browsers, etc. However, for use cases where a canvas already is the main element, either for 2D or 3D content, I think Qt for WebAssembly makes a lot of sense. The difference then is just what language and framework you use to produce the code that ends up drawing the canvas. And you will still have plenty of UI elements available with buttons, sliders, and checkboxes for your menus. This could be a good fit for image editing, painting, 3D modeling, data visualization, games, simulators, etc. I also think Qt for WebAssembly is exciting because it opens up the possibility to show a minimal demo of a full application in the browser. Instead of showing a video of the application on a product page, a small demo with limited features can be presented. Sure, it might not be as fast and doesn't have the same features as the full application (after all, you want to keep the download size to a minimum for the demo), but it will give the user a much better idea of what your application really is like. And the best part is that you can create the demo from the same code base as you used in the full application. Svenn-Arne From thiago.macieira at intel.com Tue Mar 13 16:23:44 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Mar 2018 08:23:44 -0700 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: <190050597.bTpa5menfU@tjmaciei-mobl1> Message-ID: <95151508.J85BQgSu05@tjmaciei-mobl1> On Tuesday, 13 March 2018 02:18:42 PDT Alexei Fedotov wrote: > The build finally passed for me after replacing perl with ActivePerl > and skipping "qtscript". I'm currently trying to figure out how > -prefix works for MSYS. It should be the same as everything else, provided you're using ActivePerl. Because of that, no Qt application or script will know about MSYS mounts, so you need a full, absolute Windows path for the prefix. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Gabriel.deDietrich at qt.io Tue Mar 13 19:36:48 2018 From: Gabriel.deDietrich at qt.io (Gabriel de Dietrich) Date: Tue, 13 Mar 2018 18:36:48 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: +1 Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company On Mar 12, 2018, at 10:10 AM, Sérgio Martins > wrote: Hi, Although the wiki says Qt Models don't have a maintainer I'd say David Faure has been an unofficial maintainer. David is one of the top contributors to model related code and is someone you'll always want to add as reviewer. He's well known in the community and already maintains QtXmlPatterns, Qt mimetypes and Qt3Support. Disclaimer: David works with me at KDAB. (And if you're wondering if KDAB has any plans for this module, the answer is no. In fact I hope it remains low change volume). Finally, a big thanks to the previous maintainer, Stephen Kelly, who did a great job, both on Qt and KDE models! 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 jani.heikkinen at qt.io Wed Mar 14 08:03:50 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 14 Mar 2018 07:03:50 +0000 Subject: [Development] Qt API review process (was: Re: Qt 5.11 Alpha released) In-Reply-To: References: , , Message-ID: Hi all, We have API review ongoing for Qt 5.11. For me our process for that is a bit unclear; At which point we can say the review is really done? There are comments in the reviews but then pretty much nothing... At some there is -1, few +1 but that's it. I think we should clarify the process so that we can more easily see the status there. That's why I propose following: 1) API review for the module is ready when there is '+2' (from Module/Chief Maintainer) 2) During the review reviewer must add 'Code Review -1/-2' if there is something which should be corrected before we can agree API review to be ready. And vice versa: if API seems to be OK +1 should be added to indicate API is reviewed. 3) Reviewer needs to create a bug report about the findings. That makes it easier to follow up & we can add needed ones in the release blocker list. * These bug reports should be added in review's comment field as well. And if one is something which really needs to be fixed before release reviewer should add the issue in release blocker list. 4) API review for module needs to be updated in gerrit until it gets '+2'. After that no more updates. That way we can link the approved review in releasing wiki for the evidence :D br, Jani ________________________________________ From: Edward Welbourne Sent: Wednesday, February 21, 2018 6:43 PM To: development at qt-project.org Cc: releasing at qt-project.org; Jani Heikkinen Subject: Re: Qt 5.11 Alpha released Jani Heikkinen (20 February 2018 11:14) > We have release Qt 5.11 Alpha today, see http://blog.qt.io/blog/2018/02/20/qt-5-11-alpha-released/ and so, of course, we also have 5.11 API reviews, vs v5.10.1: https://codereview.qt-project.org/221039 qtbase https://codereview.qt-project.org/221040 qtdeclarative https://codereview.qt-project.org/221041 qtmultimedia https://codereview.qt-project.org/221042 qttools https://codereview.qt-project.org/221043 qtxmlpatterns https://codereview.qt-project.org/221044 qtlocation https://codereview.qt-project.org/221045 qtconnectivity https://codereview.qt-project.org/221046 qtwayland https://codereview.qt-project.org/221047 qt3d https://codereview.qt-project.org/221048 qtserialbus https://codereview.qt-project.org/221049 qtandroidextras https://codereview.qt-project.org/221050 qtwebengine https://codereview.qt-project.org/221051 qtcharts https://codereview.qt-project.org/221052 qtgamepad https://codereview.qt-project.org/221053 qtremoteobjects See the review comments for guidance, consult actual source for definitive views of code - note that these reviews are generated by a script that filters out changes deemed boring; it has learned, on this iteration, to not waste your time with s/Q_DECL_FINAL/final/ or s/Q_QDOC/Q_CLANG_QDOC/ changes; and to ignore the addition of Q_DECL_COLD_FUNCTION. Speaking of which, please accept my apologies for not delivering this two days ago - I got distracted by trying to revamp the script to be a bit smarter about detecting boring changes that add a line, among other things. Eddy. From Morten.Sorvig at qt.io Wed Mar 14 10:32:46 2018 From: Morten.Sorvig at qt.io (=?iso-8859-1?Q?Morten_S=F8rvig?=) Date: Wed, 14 Mar 2018 09:32:46 +0000 Subject: [Development] Qt for WebAssembly In-Reply-To: <7c399488-19b8-6814-d7bc-990d0669db11@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <7c399488-19b8-6814-d7bc-990d0669db11@qt.io> Message-ID: <9209DD79-DEE0-4353-879D-FBF0AA3E5AF8@qt.io> > On 13 Mar 2018, at 15:27, Svenn-Arne Dragly wrote: > > I also think Qt for WebAssembly is exciting because it opens up the possibility to show a minimal demo of a full application in the browser. Instead of showing a video of the application on a product page, a small demo with limited features can be presented. Sure, it might not be as fast and doesn't have the same features as the full application (after all, you want to keep the download size to a minimum for the demo), but it will give the user a much better idea of what your application really is like. And the best part is that you can create the demo from the same code base as you used in the full application. I also see this demo use case as a realistic short/medium term goal, where we can provide value for current Qt users. Morten From lars.knoll at qt.io Wed Mar 14 10:48:15 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 14 Mar 2018 09:48:15 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <6170944B-FCB2-42D0-9FFA-8A9A129DE993@qt.io> +1 Cheers, Lars On 13 Mar 2018, at 19:36, Gabriel de Dietrich > wrote: +1 Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company On Mar 12, 2018, at 10:10 AM, Sérgio Martins > wrote: Hi, Although the wiki says Qt Models don't have a maintainer I'd say David Faure has been an unofficial maintainer. David is one of the top contributors to model related code and is someone you'll always want to add as reviewer. He's well known in the community and already maintains QtXmlPatterns, Qt mimetypes and Qt3Support. Disclaimer: David works with me at KDAB. (And if you're wondering if KDAB has any plans for this module, the answer is no. In fact I hope it remains low change volume). Finally, a big thanks to the previous maintainer, Stephen Kelly, who did a great job, both on Qt and KDE models! 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Wed Mar 14 10:54:16 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Wed, 14 Mar 2018 09:54:16 +0000 Subject: [Development] Qt for WebAssembly In-Reply-To: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> Message-ID: <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> > On 9 Mar 2018, at 13:57, Morten Sørvig wrote: > > * (No) thread support > > Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer, > which has been disabled in all major browser after recent security incidents. > > So we are looking to upstream a no-thread configure option, and modules that > want to work on the web should support it. It’s still possible to develop with > pthreads enabled by enabling SharedArrayBuffer for your browser. It was pointed out to me that we already have pending patches in this area: https://codereview.qt-project.org/181112 https://codereview.qt-project.org/180973 https://codereview.qt-project.org/180971 https://codereview.qt-project.org/180972 https://codereview.qt-project.org/177459 I suggest we restore and merge those since we now have an additional use case in the form of a platform requirement. (The alternative would be to wait it out - perhaps threading support will be enabled and stable in all browsers before we get to merge wip/webassembly). Morten From jani.heikkinen at qt.io Wed Mar 14 12:01:32 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 14 Mar 2018 11:01:32 +0000 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready In-Reply-To: References: Message-ID: Hi! Branching from '5.9' to '5.9.5' is now competed. From now on '5.9' if for Qt 5.9.6 and all changes targeted to Qt 5.9.5 release must be done in '5.9.5'. And as usual no any 'nice-to-haves' in '5.9.5' anymore! We are targeting to get Qt 5.9.5 out as soon as possible (during March) so please make sure all release blockers are visible in blocker list (https://bugreports.qt.io/issues/?filter=19230) and all release blockers are fixed immediately. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Thursday, March 1, 2018 3:07 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' started Hi! We have soft branched '5.9.5' from '5.9'. Final downmerge from '5.9' to '5.9.5' will happen at the beginning of week 11 (most probably Monday 12.3.2018). Please start using '5.9.5' for new changes (cherry-picks from 5.11) targeted to Qt 5.9.5 release. And once again: No any 'nice to haves' in '5.9.5' anymore! We are targeting to release Qt 5.9.5 during March. br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From akulichalexander at gmail.com Wed Mar 14 15:20:52 2018 From: akulichalexander at gmail.com (Alexandr Akulich) Date: Wed, 14 Mar 2018 17:20:52 +0300 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready In-Reply-To: References: Message-ID: Hi Jani, Can we please get in a compilation fix for qreal configured as float? There is a very small yet critical issue with qMax in QFusionStyle. I submitted the fix [1] for 5.11 and it is approved, but I agreed to also fix the same line coding style issue before staging the change. I will submit the final patch for 5.11 in two hours (as soon as I'll get back to my ssh keys) and will submit cherry-pick for 5.9 immediately after the original patch staging. [1] https://codereview.qt-project.org/#/c/223101/ On Wed, Mar 14, 2018 at 2:01 PM, Jani Heikkinen wrote: > Hi! > > Branching from '5.9' to '5.9.5' is now competed. From now on '5.9' if for Qt 5.9.6 and all changes targeted to Qt 5.9.5 release must be done in '5.9.5'. And as usual no any 'nice-to-haves' in '5.9.5' anymore! > > We are targeting to get Qt 5.9.5 out as soon as possible (during March) so please make sure all release blockers are visible in blocker list (https://bugreports.qt.io/issues/?filter=19230) and all release blockers are fixed immediately. > > br, > Jani > ________________________________________ > From: Development on behalf of Jani Heikkinen > Sent: Thursday, March 1, 2018 3:07 PM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' started > > Hi! > > We have soft branched '5.9.5' from '5.9'. Final downmerge from '5.9' to '5.9.5' will happen at the beginning of week 11 (most probably Monday 12.3.2018). > > Please start using '5.9.5' for new changes (cherry-picks from 5.11) targeted to Qt 5.9.5 release. And once again: No any 'nice to haves' in '5.9.5' anymore! > > We are targeting to release Qt 5.9.5 during March. > > 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 From lorn.potter at gmail.com Thu Mar 15 00:09:55 2018 From: lorn.potter at gmail.com (Lorn Potter) Date: Thu, 15 Mar 2018 09:09:55 +1000 Subject: [Development] Qt for WebAssembly In-Reply-To: <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> Message-ID: <83eda320-95bd-851e-83bb-0b41959ab0d1@gmail.com> On 03/14/2018 07:54 PM, Morten Sørvig wrote: > >> On 9 Mar 2018, at 13:57, Morten Sørvig wrote: >> >> * (No) thread support >> >> Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer, >> which has been disabled in all major browser after recent security incidents. >> >> So we are looking to upstream a no-thread configure option, and modules that >> want to work on the web should support it. It’s still possible to develop with >> pthreads enabled by enabling SharedArrayBuffer for your browser. > > > It was pointed out to me that we already have pending patches in this area: > > https://codereview.qt-project.org/181112 not sure why anyone would want to stop/block execution of the one and only thread. > https://codereview.qt-project.org/180973 > https://codereview.qt-project.org/180971 > https://codereview.qt-project.org/180972 ^ these we already have :) > https://codereview.qt-project.org/177459 Certainly our thread feature needs to be fixed for non wasm builds. > > I suggest we restore and merge those since we now have an additional use > case in the form of a platform requirement. > > (The alternative would be to wait it out - perhaps threading support will be > enabled and stable in all browsers before we get to merge wip/webassembly). I keep watching out for this in wasm/emscripten. It's been a 'soon' feature for a while. From jani.heikkinen at qt.io Thu Mar 15 05:56:12 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 15 Mar 2018 04:56:12 +0000 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready In-Reply-To: References: Message-ID: Hi! Is there a bug report about the issue? If this is nothing new I think we can wait Qt 5.9.6 for that fix br, Jani > -----Original Message----- > From: Alexandr Akulich > Sent: keskiviikko 14. maaliskuuta 2018 16.21 > To: Jani Heikkinen > Cc: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready > > Hi Jani, > > Can we please get in a compilation fix for qreal configured as float? > There is a very small yet critical issue with qMax in QFusionStyle. > > I submitted the fix [1] for 5.11 and it is approved, but I agreed to also fix the > same line coding style issue before staging the change. > > I will submit the final patch for 5.11 in two hours (as soon as I'll get back to my > ssh keys) and will submit cherry-pick for 5.9 immediately after the original patch > staging. > > [1] https://codereview.qt-project.org/#/c/223101/ > > On Wed, Mar 14, 2018 at 2:01 PM, Jani Heikkinen wrote: > > Hi! > > > > Branching from '5.9' to '5.9.5' is now competed. From now on '5.9' if for Qt > 5.9.6 and all changes targeted to Qt 5.9.5 release must be done in '5.9.5'. And as > usual no any 'nice-to-haves' in '5.9.5' anymore! > > > > We are targeting to get Qt 5.9.5 out as soon as possible (during March) so > please make sure all release blockers are visible in blocker list > (https://bugreports.qt.io/issues/?filter=19230) and all release blockers are fixed > immediately. > > > > br, > > Jani > > ________________________________________ > > From: Development > > on behalf of > > Jani Heikkinen > > Sent: Thursday, March 1, 2018 3:07 PM > > To: development at qt-project.org > > Cc: releasing at qt-project.org > > Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' > > started > > > > Hi! > > > > We have soft branched '5.9.5' from '5.9'. Final downmerge from '5.9' to '5.9.5' > will happen at the beginning of week 11 (most probably Monday 12.3.2018). > > > > Please start using '5.9.5' for new changes (cherry-picks from 5.11) targeted to > Qt 5.9.5 release. And once again: No any 'nice to haves' in '5.9.5' anymore! > > > > We are targeting to release Qt 5.9.5 during March. > > > > 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 From ulf.hermann at qt.io Thu Mar 15 08:22:08 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 15 Mar 2018 08:22:08 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: <83eda320-95bd-851e-83bb-0b41959ab0d1@gmail.com> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> <83eda320-95bd-851e-83bb-0b41959ab0d1@gmail.com> Message-ID: <53a81698-949f-7ce1-7e17-3e820c4b851c@qt.io> >> https://codereview.qt-project.org/181112 > not sure why anyone would want to stop/block execution of the one and > only thread. sleep() and friends do have a place in single threaded applications. You can use them to do some backoff mechanism when waiting for an external event. You shouldn't do that when user interaction is allowed, but there is no reason not to have them in the API. Furthermore, not having them makes things more complicated as we are using them ourselves and some code would have to be wrapped in #ifdef to compile without them. Btw, if you look at the patch, you'll notice it doesn't actually add or remove any code. It only moves #ifdefs around. >> https://codereview.qt-project.org/180973 >> https://codereview.qt-project.org/180971 >> https://codereview.qt-project.org/180972 > ^ these we already have :) ... I guess I have to try "configure -no-feature-thread" again and see what happens. Ulf From akulichalexander at gmail.com Thu Mar 15 09:03:46 2018 From: akulichalexander at gmail.com (Alexandr Akulich) Date: Thu, 15 Mar 2018 11:03:46 +0300 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready In-Reply-To: References: Message-ID: I thought that it is an old issue (since 5.9 to 5.11) but in fact, it is a regression since change [1] in landed to 5.9.5. I staged the fix for 5.11 ten minutes ago and I will submit the change for 5.9 in two hours. [1] https://codereview.qt-project.org/#/c/212208/ On Thu, Mar 15, 2018 at 7:56 AM, Jani Heikkinen wrote: > Hi! > > Is there a bug report about the issue? If this is nothing new I think we can wait Qt 5.9.6 for that fix > > br, > Jani > >> -----Original Message----- >> From: Alexandr Akulich >> Sent: keskiviikko 14. maaliskuuta 2018 16.21 >> To: Jani Heikkinen >> Cc: development at qt-project.org; releasing at qt-project.org >> Subject: Re: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready >> >> Hi Jani, >> >> Can we please get in a compilation fix for qreal configured as float? >> There is a very small yet critical issue with qMax in QFusionStyle. >> >> I submitted the fix [1] for 5.11 and it is approved, but I agreed to also fix the >> same line coding style issue before staging the change. >> >> I will submit the final patch for 5.11 in two hours (as soon as I'll get back to my >> ssh keys) and will submit cherry-pick for 5.9 immediately after the original patch >> staging. >> >> [1] https://codereview.qt-project.org/#/c/223101/ >> >> On Wed, Mar 14, 2018 at 2:01 PM, Jani Heikkinen wrote: >> > Hi! >> > >> > Branching from '5.9' to '5.9.5' is now competed. From now on '5.9' if for Qt >> 5.9.6 and all changes targeted to Qt 5.9.5 release must be done in '5.9.5'. And as >> usual no any 'nice-to-haves' in '5.9.5' anymore! >> > >> > We are targeting to get Qt 5.9.5 out as soon as possible (during March) so >> please make sure all release blockers are visible in blocker list >> (https://bugreports.qt.io/issues/?filter=19230) and all release blockers are fixed >> immediately. >> > >> > br, >> > Jani >> > ________________________________________ >> > From: Development >> > on behalf of >> > Jani Heikkinen >> > Sent: Thursday, March 1, 2018 3:07 PM >> > To: development at qt-project.org >> > Cc: releasing at qt-project.org >> > Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' >> > started >> > >> > Hi! >> > >> > We have soft branched '5.9.5' from '5.9'. Final downmerge from '5.9' to '5.9.5' >> will happen at the beginning of week 11 (most probably Monday 12.3.2018). >> > >> > Please start using '5.9.5' for new changes (cherry-picks from 5.11) targeted to >> Qt 5.9.5 release. And once again: No any 'nice to haves' in '5.9.5' anymore! >> > >> > We are targeting to release Qt 5.9.5 during March. >> > >> > 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 From jani.heikkinen at qt.io Thu Mar 15 09:22:20 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 15 Mar 2018 08:22:20 +0000 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready In-Reply-To: References: , Message-ID: Ok, Then it would be good to get this fixed in Qt 5.9.5. Please remember to do the cherry-pick in '5.9.5', not in '5.9' br, Jani ________________________________________ From: Alexandr Akulich Sent: Thursday, March 15, 2018 10:03 AM To: Jani Heikkinen Cc: development at qt-project.org; releasing at qt-project.org Subject: Re: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready I thought that it is an old issue (since 5.9 to 5.11) but in fact, it is a regression since change [1] in landed to 5.9.5. I staged the fix for 5.11 ten minutes ago and I will submit the change for 5.9 in two hours. [1] https://codereview.qt-project.org/#/c/212208/ On Thu, Mar 15, 2018 at 7:56 AM, Jani Heikkinen wrote: > Hi! > > Is there a bug report about the issue? If this is nothing new I think we can wait Qt 5.9.6 for that fix > > br, > Jani > >> -----Original Message----- >> From: Alexandr Akulich >> Sent: keskiviikko 14. maaliskuuta 2018 16.21 >> To: Jani Heikkinen >> Cc: development at qt-project.org; releasing at qt-project.org >> Subject: Re: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' ready >> >> Hi Jani, >> >> Can we please get in a compilation fix for qreal configured as float? >> There is a very small yet critical issue with qMax in QFusionStyle. >> >> I submitted the fix [1] for 5.11 and it is approved, but I agreed to also fix the >> same line coding style issue before staging the change. >> >> I will submit the final patch for 5.11 in two hours (as soon as I'll get back to my >> ssh keys) and will submit cherry-pick for 5.9 immediately after the original patch >> staging. >> >> [1] https://codereview.qt-project.org/#/c/223101/ >> >> On Wed, Mar 14, 2018 at 2:01 PM, Jani Heikkinen wrote: >> > Hi! >> > >> > Branching from '5.9' to '5.9.5' is now competed. From now on '5.9' if for Qt >> 5.9.6 and all changes targeted to Qt 5.9.5 release must be done in '5.9.5'. And as >> usual no any 'nice-to-haves' in '5.9.5' anymore! >> > >> > We are targeting to get Qt 5.9.5 out as soon as possible (during March) so >> please make sure all release blockers are visible in blocker list >> (https://bugreports.qt.io/issues/?filter=19230) and all release blockers are fixed >> immediately. >> > >> > br, >> > Jani >> > ________________________________________ >> > From: Development >> > on behalf of >> > Jani Heikkinen >> > Sent: Thursday, March 1, 2018 3:07 PM >> > To: development at qt-project.org >> > Cc: releasing at qt-project.org >> > Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.5' >> > started >> > >> > Hi! >> > >> > We have soft branched '5.9.5' from '5.9'. Final downmerge from '5.9' to '5.9.5' >> will happen at the beginning of week 11 (most probably Monday 12.3.2018). >> > >> > Please start using '5.9.5' for new changes (cherry-picks from 5.11) targeted to >> Qt 5.9.5 release. And once again: No any 'nice to haves' in '5.9.5' anymore! >> > >> > We are targeting to release Qt 5.9.5 during March. >> > >> > 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 From tony.sarajarvi at qt.io Thu Mar 15 09:26:21 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 15 Mar 2018 08:26:21 +0000 Subject: [Development] About our CI update notifications Message-ID: Hi We're trying to improve our communication toward you regarding our CI and what's going on with it. So our suggestion comes as follows: · - In case of a scheduled update, we send an e-mail to the public developer mailing list the day before · - In case of emergency update or pure restart, no notifications are needed · - If Coin is unavailable for more than 30 min, we send an e-mail to the public developer mail list and inform about it followed by an e-mail when it's back up again. · - Keep community updated in case of prolonged downtime · - We mention a contact address where e-mails should be sent if abnormalities are seen after the update/restart, usually qt.ci@qt.io How does this sound to you recipients of these e-mails? Enough or would this be excess spam to some degree? -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Mar 15 09:33:16 2018 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 15 Mar 2018 09:33:16 +0100 Subject: [Development] About our CI update notifications In-Reply-To: References: Message-ID: <20180315083316.h6rcga2pesy5mt4p@hooch.localdomain> Hi, On Thu, Mar 15, 2018 at 08:26:21AM +0000, Tony Sarajärvi wrote: > How does this sound to you recipients of these e-mails? Enough or would this be excess spam to some degree? That sounds like useful information to me. However, I'm wondering: Would it be possible to display some kind of announcement banner on Gerrit instead of (or in addition to) the mails? That way, people would get that information right where they need it (when using Gerrit or trying to stage a change). I'm just a somewhat casual contributor though, I don't know how well that'd fit people's workflows - just my $0.02 ;-) Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From viktor.engelmann at qt.io Thu Mar 15 10:57:56 2018 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Thu, 15 Mar 2018 10:57:56 +0100 Subject: [Development] Qt for WebAssembly In-Reply-To: <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io> <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> Message-ID: <18a55f2f-4adf-8b99-6e7e-6649a68327ee@qt.io> I am personally quite excited about having a common standard for binaries on the web, that can be generated from C++ and I think there is a lot of potential and I am happy to see Qt going in that direction. Regarding the load-times: WebAssembly supports dynamic linking, so browsers might cache Qt libraries, so they would only have to download them once. If the pages loaded the libs from a common location (say download.qt.io), they would even only have to load them once for all pages that use them. (I do have to say that I've had bad experiences with the caching of wasm files - sometimes they aren't even reloaded after new versions are on the server... but that should only be a temporary problem). About the threading: there are Web Workers in the HTML5 standard. These basically are threads, but they are harder to use (for example because of /*strict*/ ownership of objects), so it might not be feasible to map threads to Web Workers... Just throwing it into the discussion. -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Thu Mar 15 11:22:06 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 15 Mar 2018 10:22:06 +0000 Subject: [Development] Qt for WebAssembly In-Reply-To: <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> References: <7707412F-6304-40A4-AF24-9F163B5932B5@qt.io>, <4CB8432E-4BF1-43B1-949A-9D110DA46BA9@qt.io> Message-ID: Morten Sørvig (14 March 2018 10:54) > (The alternative would be to wait it out - perhaps threading support will be > enabled and stable in all browsers before we get to merge wip/webassembly). >From recent discussion with a Firefox developer, I gather that browser vendors are generally trying to restore SharedArrayBuffer in wasm, at least; which is likely to result in it also being restored to JS. However, mitigating the Spectre weakness may involve constraining the use of SharedArrayBuffer; details remain unclear (and shall probably require developers from different browsers to reach a consensus on what's a good way to do this). He also noted that SharedArrayBuffer is a run-time preference in Firefox (about:config -> javascript.options.shared_memory); but it's a global option, not per-site, so enabling it may make expose you to Spectre exploits. Eddy. From tero.kojo at qt.io Thu Mar 15 12:43:28 2018 From: tero.kojo at qt.io (Tero Kojo) Date: Thu, 15 Mar 2018 11:43:28 +0000 Subject: [Development] Qt Contributors' Summit time, date and help needed Message-ID: Hello, This years' Qt Contributors' Summit (QtCS) 2018 is going to be in Oslo in June 11th - 12th. Qt Contributors' Summit is an annual event open to anyone who has contributed toward the Qt project in the past year. Contributions can include code, helping on the forum, maintaining the wiki, or any other form of moving the Qt project forward. We are also happy to have advanced Qt users at the event, as there can never be too much user feedback. If you are coming to QtCS 2018, please register with this link: https://www.surveymonkey.com/r/3P55B5C As usual QtCS is free for attendees, but you do need to get there and take care of your hotel or other accommodation. In the past QtCS has followed the unconference format, but we are thinking of making changes to the format of Qt Contributors' Summit. The unconference format works to some degree, but we would like to get into more detail and involve the participants more. If you would like to help with planning the format of the event, please reply to me. The work amount is attending a 30 minute meeting once a week for the next few weeks, and bringing in ideas for how to run the two days to the maximum benefit of the community. Best, Tero P.S. if your company is interested in sponsoring the event, please contact me Tero Kojo Commnity Manager The Qt Company Bertel Jungin Aukio D3A 02600, Espoo, Finland tero.kojo at qt.io +358 50 4869769 http://qt.io [The Qt Company logo] [Facebook] [Twitter] [LinkedIn] [Google+] [YouTube] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 8189 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.png Type: image/png Size: 868 bytes Desc: image014.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.png Type: image/png Size: 985 bytes Desc: image015.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.png Type: image/png Size: 911 bytes Desc: image016.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image017.png Type: image/png Size: 1038 bytes Desc: image017.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image018.png Type: image/png Size: 902 bytes Desc: image018.png URL: From tuukka.turunen at qt.io Thu Mar 15 13:20:41 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 15 Mar 2018 12:20:41 +0000 Subject: [Development] About our CI update notifications In-Reply-To: <20180315083316.h6rcga2pesy5mt4p@hooch.localdomain> References: <20180315083316.h6rcga2pesy5mt4p@hooch.localdomain> Message-ID: <19246026-984A-4B7D-91EB-36F6E411E977@qt.io> On 15/03/2018, 10.33, "Development on behalf of Florian Bruhin" wrote: Hi, On Thu, Mar 15, 2018 at 08:26:21AM +0000, Tony Sarajärvi wrote: > How does this sound to you recipients of these e-mails? Enough or would this be excess spam to some degree? That sounds like useful information to me. However, I'm wondering: Would it be possible to display some kind of announcement banner on Gerrit instead of (or in addition to) the mails? That way, people would get that information right where they need it (when using Gerrit or trying to stage a change). +1 There is good space for it in the footer. Should be quite easy to pull notification info there. -- Tuukka I'm just a somewhat casual contributor though, I don't know how well that'd fit people's workflows - just my $0.02 ;-) Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ From jani.heikkinen at qt.io Thu Mar 15 13:54:32 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 15 Mar 2018 12:54:32 +0000 Subject: [Development] Qt 5.11 beta2 released In-Reply-To: References: Message-ID: Hi all, We have published Qt 5.11 beta2 today. As earlier you can get it via online installer. Delta to beta1 attached. Please test the packages now & report all findings to Jira. Also make sure all release blockers can be found from release blocker list (https://bugreports.qt.io/issues/?filter=19209). It is really time to test the packages now; even the plan is to release at the end of May we will do it earlier if possible. br, Jani -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delta_qt511-beta1-qt511.beta2.txt URL: From announce at qt-project.org Thu Mar 15 13:55:17 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 15 Mar 2018 12:55:17 +0000 Subject: [Development] [Announce] Qt 5.11 beta2 released In-Reply-To: References: Message-ID: Hi all, We have published Qt 5.11 beta2 today. As earlier you can get it via online installer. br, Jani _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From adam.treat at qt.io Thu Mar 15 14:35:24 2018 From: adam.treat at qt.io (Adam Treat) Date: Thu, 15 Mar 2018 09:35:24 -0400 Subject: [Development] About our CI update notifications In-Reply-To: References: Message-ID: I would not regard this as excess spam at all. It is important to know when the CI is not available and what the status is. If a restart or scheduled update of any kind requires to restage commits for COIN, please include that info. On 03/15/2018 04:26 AM, Tony Sarajärvi wrote: > > Hi > > We’re trying to improve our communication toward you regarding our CI > and what’s going on with it. So our suggestion comes as follows: > > ·- In case of a scheduled update, we send an e-mail to the public > developer mailing list the day before > > ·- In case of emergency update or pure restart, no notifications are > needed > > ·- If Coin is unavailable for more than 30 min, we send an e-mail to > the public developer mail list and inform about it followed by an > e-mail when it’s back up again. > > ·- Keep community updated in case of prolonged downtime > > ·- We mention a contact address where e-mails should be sent if > abnormalities are seen after the update/restart, usually qt.ci > @qt.io > > How does this sound to you recipients of these e-mails? Enough or > would this be excess spam to some degree? > > -Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.treat at qt.io Thu Mar 15 16:57:41 2018 From: adam.treat at qt.io (Adam Treat) Date: Thu, 15 Mar 2018 11:57:41 -0400 Subject: [Development] About our CI update notifications In-Reply-To: References: Message-ID: Speaking of... https://codereview.qt-project.org/#/c/223224/ That integration is stuck and I don't know how to stop it and restage it. Apparently, the Windows 7 (mingw53-x86) VM crashed and COIN is not aware of that due to these: 1. https://bugreports.qt.io/browse/QTQAINFRA-1750 2. https://bugreports.qt.io/browse/QTQAINFRA-1748 Anyone know how to stop the integration so I can restage? Cheers, Adam On 03/15/2018 09:35 AM, Adam Treat wrote: > I would not regard this as excess spam at all. It is important to know > when the CI is not available and what the status is. If a restart or > scheduled update of any kind requires to restage commits for COIN, > please include that info. > > On 03/15/2018 04:26 AM, Tony Sarajärvi wrote: >> >> Hi >> >> We’re trying to improve our communication toward you regarding our CI >> and what’s going on with it. So our suggestion comes as follows: >> >> ·- In case of a scheduled update, we send an e-mail to the public >> developer mailing list the day before >> >> ·- In case of emergency update or pure restart, no notifications are >> needed >> >> ·- If Coin is unavailable for more than 30 min, we send an e-mail to >> the public developer mail list and inform about it followed by an >> e-mail when it’s back up again. >> >> ·- Keep community updated in case of prolonged downtime >> >> ·- We mention a contact address where e-mails should be sent if >> abnormalities are seen after the update/restart, usually qt.ci >> @qt.io >> >> How does this sound to you recipients of these e-mails? Enough or >> would this be excess spam to some degree? >> >> -Tony >> > > > > _______________________________________________ > 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 adam.treat at qt.io Thu Mar 15 17:02:40 2018 From: adam.treat at qt.io (Adam Treat) Date: Thu, 15 Mar 2018 12:02:40 -0400 Subject: [Development] About our CI update notifications In-Reply-To: References: Message-ID: NM, I figured out how to cancel it :P On 03/15/2018 11:57 AM, Adam Treat wrote: > Speaking of... > > https://codereview.qt-project.org/#/c/223224/ > > That integration is stuck and I don't know how to stop it and restage > it. Apparently, the Windows 7 (mingw53-x86) VM crashed and COIN is not > aware of that due to these: > > 1. https://bugreports.qt.io/browse/QTQAINFRA-1750 > 2. https://bugreports.qt.io/browse/QTQAINFRA-1748 > > Anyone know how to stop the integration so I can restage? > > Cheers, > > Adam > > > On 03/15/2018 09:35 AM, Adam Treat wrote: >> I would not regard this as excess spam at all. It is important to >> know when the CI is not available and what the status is. If a >> restart or scheduled update of any kind requires to restage commits >> for COIN, please include that info. >> >> On 03/15/2018 04:26 AM, Tony Sarajärvi wrote: >>> >>> Hi >>> >>> We’re trying to improve our communication toward you regarding our >>> CI and what’s going on with it. So our suggestion comes as follows: >>> >>> ·- In case of a scheduled update, we send an e-mail to the public >>> developer mailing list the day before >>> >>> ·- In case of emergency update or pure restart, no notifications are >>> needed >>> >>> ·- If Coin is unavailable for more than 30 min, we send an e-mail to >>> the public developer mail list and inform about it followed by an >>> e-mail when it’s back up again. >>> >>> ·- Keep community updated in case of prolonged downtime >>> >>> ·- We mention a contact address where e-mails should be sent if >>> abnormalities are seen after the update/restart, usually qt.ci >>> @qt.io >>> >>> How does this sound to you recipients of these e-mails? Enough or >>> would this be excess spam to some degree? >>> >>> -Tony >>> >> >> >> >> _______________________________________________ >> 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 perezmeyer at gmail.com Thu Mar 15 19:32:10 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Thu, 15 Mar 2018 15:32:10 -0300 Subject: [Development] License issue with Qt3D files, aka QTBUG-61415 Message-ID: Some time ago I filed QTBUG-61415 because Qt3D ships files which require permissions from the author in order to be able to ship them. The bug has been marked as P1 but so far we have not seen any changes. I think this should be really fixed soon, as we are talking about 3rd party stuff licenses. Thanks! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ From announce at qt-project.org Fri Mar 16 08:56:00 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 16 Mar 2018 07:56:00 +0000 Subject: [Development] [Announce] Qt Creator 4.6 RC released Message-ID: We are happy to announce the release of Qt Creator 4.6 RC! https://blog.qt.io/blog/2018/03/15/qt-creator-4-6-rc-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 edward.welbourne at qt.io Fri Mar 16 11:41:34 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 16 Mar 2018 10:41:34 +0000 Subject: [Development] Qt API review process (was: Re: Qt 5.11 Alpha released) In-Reply-To: References: , , , Message-ID: Jani Heikkinen (14 March 2018 08:03) wrote: > We have API review ongoing for Qt 5.11. > For me our process for that is a bit unclear; That sounds like something we should aim to turn into a QUIP, once discussion here has produced something close enough to a consensus to be worth documenting. Folks out there with opinions on the process Jani proposed, please speak up ! [...] > 4) API review for module needs to be updated in gerrit until it gets > '+2'. After that no more updates. If there are updates to the code that change API, I shall feel duty-bound to update the API review; of course, those shouldn't happen except in responses to the API review, but we do things asynchronously, so it's possible some change that's been on its way in for some time lands after my last update to the API review before it gets its +2; particularly if there was an objection to something in the API review, that someone set about addressing but despite which the maintainer decided to +2 (e.g. it might be in new API that's not yet subject to [BS]C promises; but its perpetrator sees the wisdom of the objection so addresses it). The QUIP shall, at least, need to document how we deal with such cases, if they arise, Eddy. From frederik.gladhorn at qt.io Fri Mar 16 12:44:23 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Fri, 16 Mar 2018 12:44:23 +0100 Subject: [Development] Nominating people from our release team for approver rights In-Reply-To: References: Message-ID: <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> Hello all, in 2014 we agreed to make the release team in The Qt Company approvers for the Qt Project to enable them to work efficiently. Since then we had Aapo join the team. Aapo is working hard on improving Coin and getting all our changes through CI smoothly. Sadly he doesn't have many commits in the public repos. Since he's been doing a lot of good work on Coin and the QA side of things, helping the release team, I'd like to propose him as approver. Cheers, Frederik On torsdag 9. januar 2014 15.18.56 CET Knoll Lars wrote: > Hi, > > I’d like to nominate a couple of people from the release team for approver > rights. They’ve been working for the last 14 month with our release and CI > infrastructure, and even though many of their contributions are not as > directly visible (and often aren’t visible in gerrit), they are highly > important to the project. I believe they all know the approval process > well, and them being Approvers will also make it easier to get releases > out in the future. > > The people I’d like to nominate are: > > Tony Sarajärvi > Simo Fält > Matti Paaso > Akseli Salovaara > Jani Heikkinen > > Cheers, > Lars > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Fri Mar 16 12:48:26 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 16 Mar 2018 14:48:26 +0300 Subject: [Development] Nominating people from our release team for approver rights In-Reply-To: <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> References: <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> Message-ID: <1753691521200906@web6g.yandex.ru> 16.03.2018, 14:44, "Frederik Gladhorn" : > Hello all, > > in 2014 we agreed to make the release team in The Qt Company approvers for the > Qt Project to enable them to work efficiently. > > Since then we had Aapo join the team. Aapo is working hard on improving Coin > and getting all our changes through CI smoothly. Sadly he doesn't have many > commits in the public repos. > > Since he's been doing a lot of good work on Coin and the QA side of things, > helping the release team, I'd like to propose him as approver. +1 -- Regards, Konstantin From Simon.Hausmann at qt.io Fri Mar 16 13:01:46 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 16 Mar 2018 12:01:46 +0000 Subject: [Development] Nominating people from our release team for approver rights In-Reply-To: <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> References: , <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> Message-ID: +1. Aapo is evidently familiar with the CI code base and has demonstrated that numerous times with own changes as well as code reviews. I trust him to approve and reject changes made by others. Simon ________________________________ From: Development on behalf of Frederik Gladhorn Sent: Friday, March 16, 2018 12:44:23 PM To: development at qt-project.org; Aapo Keskimölö Subject: Re: [Development] Nominating people from our release team for approver rights Hello all, in 2014 we agreed to make the release team in The Qt Company approvers for the Qt Project to enable them to work efficiently. Since then we had Aapo join the team. Aapo is working hard on improving Coin and getting all our changes through CI smoothly. Sadly he doesn't have many commits in the public repos. Since he's been doing a lot of good work on Coin and the QA side of things, helping the release team, I'd like to propose him as approver. Cheers, Frederik On torsdag 9. januar 2014 15.18.56 CET Knoll Lars wrote: > Hi, > > I’d like to nominate a couple of people from the release team for approver > rights. They’ve been working for the last 14 month with our release and CI > infrastructure, and even though many of their contributions are not as > directly visible (and often aren’t visible in gerrit), they are highly > important to the project. I believe they all know the approval process > well, and them being Approvers will also make it easier to get releases > out in the future. > > The people I’d like to nominate are: > > Tony Sarajärvi > Simo Fält > Matti Paaso > Akseli Salovaara > Jani Heikkinen > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Fri Mar 16 13:03:38 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 16 Mar 2018 09:03:38 -0300 Subject: [Development] License issue with Qt3D files, aka QTBUG-61415 In-Reply-To: References: Message-ID: <1962745.TLuHlLr89f@tonks> Lars: I'm explicitely CCing you because I undertand you are the one that must accept 3rd party stuff in the sources. El jueves, 15 de marzo de 2018 15:32:10 -03 Lisandro Damián Nicanor Pérez Meyer escribió: > Some time ago I filed QTBUG-61415 because Qt3D ships files which > require permissions from the author in order to be able to ship them. > The bug has been marked as P1 but so far we have not seen any changes. > > I think this should be really fixed soon, as we are talking about 3rd > party stuff licenses. > > Thanks! -- Hacer algo siempre te llevará más tiempo del que esperabas, incluso si tienes en cuenta la ley de Hofstadter. Douglas Hofstadter http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From jani.heikkinen at qt.io Fri Mar 16 13:24:43 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 16 Mar 2018 12:24:43 +0000 Subject: [Development] License issue with Qt3D files, aka QTBUG-61415 In-Reply-To: <1962745.TLuHlLr89f@tonks> References: , <1962745.TLuHlLr89f@tonks> Message-ID: Hi! Thanks notifying this now. I put this in Qt 5.9.5 and Qt 5.11 RC blocker list. Qt3D team will fix the issue as soon as possible. br, jani ________________________________________ From: Development on behalf of Lisandro Damián Nicanor Pérez Meyer Sent: Friday, March 16, 2018 2:03 PM To: development at qt-project.org Subject: Re: [Development] License issue with Qt3D files, aka QTBUG-61415 Lars: I'm explicitely CCing you because I undertand you are the one that must accept 3rd party stuff in the sources. El jueves, 15 de marzo de 2018 15:32:10 -03 Lisandro Damián Nicanor Pérez Meyer escribió: > Some time ago I filed QTBUG-61415 because Qt3D ships files which > require permissions from the author in order to be able to ship them. > The bug has been marked as P1 but so far we have not seen any changes. > > I think this should be really fixed soon, as we are talking about 3rd > party stuff licenses. > > Thanks! -- Hacer algo siempre te llevará más tiempo del que esperabas, incluso si tienes en cuenta la ley de Hofstadter. Douglas Hofstadter http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ From jani.heikkinen at qt.io Fri Mar 16 14:21:23 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 16 Mar 2018 13:21:23 +0000 Subject: [Development] Maintainers, your actions needed: Qt 5.9.5 changes files Message-ID: Hi all, Initial ones done. Please do needed modifications & get approval as soon as possible. Files here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.9.5%22,n,z br, Jani Heikkinen Release Manager From lars.knoll at qt.io Fri Mar 16 18:26:07 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 16 Mar 2018 17:26:07 +0000 Subject: [Development] Nominating people from our release team for approver rights In-Reply-To: References: <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> Message-ID: Another +1 from me. Cheers, Lars On 16 Mar 2018, at 13:01, Simon Hausmann > wrote: +1. Aapo is evidently familiar with the CI code base and has demonstrated that numerous times with own changes as well as code reviews. I trust him to approve and reject changes made by others. Simon ________________________________ From: Development > on behalf of Frederik Gladhorn > Sent: Friday, March 16, 2018 12:44:23 PM To: development at qt-project.org; Aapo Keskimölö Subject: Re: [Development] Nominating people from our release team for approver rights Hello all, in 2014 we agreed to make the release team in The Qt Company approvers for the Qt Project to enable them to work efficiently. Since then we had Aapo join the team. Aapo is working hard on improving Coin and getting all our changes through CI smoothly. Sadly he doesn't have many commits in the public repos. Since he's been doing a lot of good work on Coin and the QA side of things, helping the release team, I'd like to propose him as approver. Cheers, Frederik On torsdag 9. januar 2014 15.18.56 CET Knoll Lars wrote: > Hi, > > I’d like to nominate a couple of people from the release team for approver > rights. They’ve been working for the last 14 month with our release and CI > infrastructure, and even though many of their contributions are not as > directly visible (and often aren’t visible in gerrit), they are highly > important to the project. I believe they all know the approval process > well, and them being Approvers will also make it easier to get releases > out in the future. > > The people I’d like to nominate are: > > Tony Sarajärvi > Simo Fält > Matti Paaso > Akseli Salovaara > Jani Heikkinen > > 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 _______________________________________________ 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 tony.sarajarvi at qt.io Sat Mar 17 07:02:54 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sat, 17 Mar 2018 06:02:54 +0000 Subject: [Development] The CI is down atm Message-ID: Hi The CI is down atm and I can't even log in to the server right now. I'm trying to fix this somehow right away. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Sat Mar 17 07:42:30 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Sat, 17 Mar 2018 06:42:30 +0000 Subject: [Development] The CI is down atm In-Reply-To: References: Message-ID: Ok I brought it up again. Hosts seem to be dying left and right. The current MAAS provided Ubuntu 16.04 LTS seem to have at least 3 different symptoms of how it crashes. kernel BUG at /build/linux-Fk60NP/linux-4.10.0/include/linux/swapops.h:129! kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:494! or kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:68! + possible memory corruptions on multiple host causing crashes. These are being checked by memtest, but it hasn’t found anything wrong. So, coin is building again, but more crashes are due. I should swap to 17.04 or 17.10 even though they have their own share of problems. They _might_ have gotten fixed during this period when we went back to 16.04. And as 16.04 went from bad to worse recently, the 17.xx are surely more stable right now. Fingers crossed! -Tony Oh, and capacity is heavily reduced before the crashed servers are deployed back. And a long queue is in already naturally. ☹ We aren’t monitoring 24/7, so please inform at qt.ci at qt.io if you suspect the CI has crashed. Thank you! From: Tony Sarajärvi Sent: lauantai 17. maaliskuuta 2018 8.03 To: development at qt-project.org Subject: The CI is down atm Hi The CI is down atm and I can’t even log in to the server right now. I’m trying to fix this somehow right away. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From allan.jensen at qt.io Sat Mar 17 10:24:41 2018 From: allan.jensen at qt.io (Allan Sandfeld Jensen) Date: Sat, 17 Mar 2018 10:24:41 +0100 Subject: [Development] The CI is down atm In-Reply-To: References: Message-ID: <2499390.Q4EyknUKBR@twilight> On Samstag, 17. März 2018 07:42:30 CET Tony Sarajärvi wrote: > Ok I brought it up again. Hosts seem to be dying left and right. The current > MAAS provided Ubuntu 16.04 LTS seem to have at least 3 different symptoms > of how it crashes. > > > > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/include/linux/swapops.h:129! > > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:494! > > or > > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:68! > > > > + possible memory corruptions on multiple host causing crashes. These are > being checked by memtest, but it hasn’t found anything wrong. > Googling around a bit, these errors seems to be pretty common and happen across many different distros and for years. The general conclusion seems to be that fscache is just not very stable. Can't you somehow avoid NFS instead? 'Allan From tony.sarajarvi at qt.io Sat Mar 17 12:14:09 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Sat, 17 Mar 2018 11:14:09 +0000 Subject: [Development] The CI is down atm In-Reply-To: <2499390.Q4EyknUKBR@twilight> References: <2499390.Q4EyknUKBR@twilight> Message-ID: (top posting, thank you outlook) The NFS is the backbone of how our CI works. I've been drawing a describing picture of how our infra is set up so that everyone can understand the bits and pieces of it, but I've seen so super busy lately that it hasn't progressed lately. Began working on it during the slower period at Christmas. Basically we have 20 hosts that need access to the same data. For this we have a Dell Compellent storage system in the background and OpenNebula having the qcow2 images stored there. Now these qcow2 images are shared over NFS and we have 20 hosts reading that data. If they constantly read that data over the local network, the NFS server would not cope with it. So that's why all hosts have NFS caches so that the data they need is mostly available every time it's needed. It would be a dramatic change in the infra setup if we distributed all these qcow2 images to the hosts beforehand, and we don't have the storage space on the hosts to store the images either ☹ -Tony -----Original Message----- From: Allan Jensen Sent: lauantai 17. maaliskuuta 2018 11.25 To: Tony Sarajärvi Cc: development at qt-project.org Subject: Re: The CI is down atm On Samstag, 17. März 2018 07:42:30 CET Tony Sarajärvi wrote: > Ok I brought it up again. Hosts seem to be dying left and right. The > current MAAS provided Ubuntu 16.04 LTS seem to have at least 3 > different symptoms of how it crashes. > > > > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/include/linux/swapops.h:129! > > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:494! > > or > > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:68! > > > > + possible memory corruptions on multiple host causing crashes. These > + are > being checked by memtest, but it hasn’t found anything wrong. > Googling around a bit, these errors seems to be pretty common and happen across many different distros and for years. The general conclusion seems to be that fscache is just not very stable. Can't you somehow avoid NFS instead? 'Allan From tony.sarajarvi at qt.io Sat Mar 17 12:54:23 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sat, 17 Mar 2018 11:54:23 +0000 Subject: [Development] Problems in provisioning Message-ID: Hi You probably have seen that we have problems in provisioning. grub-update command isn't found and hdiutil can't unmount while installing Java on macOS'es. I'm suspecting the culprit for these problems is an update in Coin where it began enforcing errors in the scripts. Yes, we had the problems in the scripts before, but we just ignored the errors. So, now as we enforce, we hit a stand still until they are fixed (or we revert the Coin change). Sadly it's a Saturday and people working on this is close to 0. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Mon Mar 19 06:42:59 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 19 Mar 2018 05:42:59 +0000 Subject: [Development] HEADS UP : Qt 5.11 soft string freeze Message-ID: Hi all, First beta releases from Qt 5.11 are already out so it is time to start keeping translatable strings as it is. Let's have official string freeze Mon 26th March 2018. br, Jani From jedrzej.nowacki at qt.io Mon Mar 19 08:58:06 2018 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 19 Mar 2018 08:58:06 +0100 Subject: [Development] The CI is down atm In-Reply-To: References: Message-ID: <1957856.J2dQ5uut1X@snoll> Oh, thanks for sharing it. For the first time we have something that really points to fscache, or at least has it in the logs. I suggest to replace NFS + fscache, with a distributed files system with _good_ local caching (could be cephfs?). The current setup requires only that used part of images is cached locally and that all images are permanently stored in one location. As a bonus we would migrate from a stat setup to a mesh, that would be good too.That can not be hard to achieve ;-) Cheers, Jędrek Dnia sobota, 17 marca 2018 07:42:30 CET Tony Sarajärvi pisze: > Ok I brought it up again. Hosts seem to be dying left and right. The current > MAAS provided Ubuntu 16.04 LTS seem to have at least 3 different symptoms > of how it crashes. > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/include/linux/swapops.h:129! > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:494! > or > kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:68! > > + possible memory corruptions on multiple host causing crashes. These are > being checked by memtest, but it hasn’t found anything wrong. > So, coin is building again, but more crashes are due. I should swap to 17.04 > or 17.10 even though they have their own share of problems. They _might_ > have gotten fixed during this period when we went back to 16.04. And as > 16.04 went from bad to worse recently, the 17.xx are surely more stable > right now. > Fingers crossed! > > -Tony > > Oh, and capacity is heavily reduced before the crashed servers are deployed > back. And a long queue is in already naturally. ☹ > We aren’t monitoring 24/7, so please inform at qt.ci at qt.io if you suspect > the CI has crashed. Thank you! > From: Tony Sarajärvi > Sent: lauantai 17. maaliskuuta 2018 8.03 > To: development at qt-project.org > Subject: The CI is down atm > > Hi > > The CI is down atm and I can’t even log in to the server right now. I’m > trying to fix this somehow right away. > -Tony From gunnar at crimson.no Mon Mar 19 13:39:50 2018 From: gunnar at crimson.no (Gunnar Sletta) Date: Mon, 19 Mar 2018 13:39:50 +0100 Subject: [Development] Stepping down as maintainer Message-ID: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Hi, After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: Tor Arne Vestby - QPA and window system integration Laszlo Agocs - OpenGL/Vulkan Eirik Aavitsland - Image Formats and QPainter Andy Nichols - Scene Graph (Other specific maintainers in QtGui stay unchanged) Thanks, Gunnar From denis.shienkov at gmail.com Mon Mar 19 13:59:47 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 19 Mar 2018 15:59:47 +0300 Subject: [Development] Stepping down as maintainer In-Reply-To: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: Hi all, As I can see recently, is is not a good tendence in Qt... Many peoples leaves from Qt.. What happens? Or I'm mistake? :) 19.03.2018 15:39, Gunnar Sletta пишет: > Hi, > > After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. > > I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: > > Tor Arne Vestby - QPA and window system integration > Laszlo Agocs - OpenGL/Vulkan > Eirik Aavitsland - Image Formats and QPainter > Andy Nichols - Scene Graph > > (Other specific maintainers in QtGui stay unchanged) > > Thanks, > Gunnar > _______________________________________________ > 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 vladstelmahovsky at gmail.com Mon Mar 19 14:03:48 2018 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Mon, 19 Mar 2018 14:03:48 +0100 Subject: [Development] Stepping down as maintainer In-Reply-To: References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: JavaScript easier On Mon, Mar 19, 2018 at 1:59 PM, Denis Shienkov wrote: > Hi all, > > As I can see recently, is is not a good tendence in Qt... Many peoples > leaves from Qt.. What happens? Or I'm mistake? :) > > 19.03.2018 15:39, Gunnar Sletta пишет: > > Hi, > > After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. > > I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: > > Tor Arne Vestby - QPA and window system integration > Laszlo Agocs - OpenGL/Vulkan > Eirik Aavitsland - Image Formats and QPainter > Andy Nichols - Scene Graph > > (Other specific maintainers in QtGui stay unchanged) > > Thanks, > Gunnar > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From nospam at vuorela.dk Mon Mar 19 18:31:07 2018 From: nospam at vuorela.dk (Sune Vuorela) Date: Mon, 19 Mar 2018 17:31:07 +0000 (UTC) Subject: [Development] Stepping down as maintainer References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: On 2018-03-19, Denis Shienkov wrote: > As I can see recently, is is not a good tendence in Qt... Many peoples > leaves from Qt.. What happens? Or I'm mistake? :) Let's do some math. There is around 160 maintainer positions in Qt (a quick count of on the maintainers wiki page) Many maintainers are a maintainer as part of their job duties. Not many people these days have the same job for more than 5-6 years. If it takes 1-2 years to get to a state to become maintainer, that leaves around 4 years as a maintainer. If we assume that the maintainer is around for 4 years and there is effective 10 months per year, then we should have 4 replacement maintainers each month. I'm not sure I see something worrying in numbers alone. /Sune From alexander.blasche at qt.io Tue Mar 20 08:28:48 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 20 Mar 2018 07:28:48 +0000 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: References: Message-ID: Congratulations to Ville. Approver rights have been set. -- Alex ________________________________________ From: Development on behalf of Simon Hausmann Sent: Tuesday, 27 February 2018 10:36:07 AM To: development at qt-project.org Subject: [Development] Nominating Ville Voutilainen as approver Hi, I would like to nominate Ville as approver. Due to his work in the GCC project he is certainly experienced with strict code reviews. Based on my interaction with him I'm convinced that he has successfully demonstrated the same skill set during code reviews in Qt. Simon From tuukka.turunen at qt.io Tue Mar 20 09:09:13 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 20 Mar 2018 08:09:13 +0000 Subject: [Development] Stepping down as maintainer In-Reply-To: References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: Hi, It would be very good to get more contributors and maintainers also from the community and companies who offer Qt services. Lately we have had some community maintainers step down and replaced by people from The Qt Company. This is fine to some degree, but we should also have new persons from the community and ecosystem step up. Overall the amount of community contributions to Qt is still around the same 30% as it has been. So we have not been getting any better or worse in that regard. Yours, Tuukka On 19/03/2018, 19.33, "Development on behalf of Sune Vuorela" wrote: On 2018-03-19, Denis Shienkov wrote: > As I can see recently, is is not a good tendence in Qt... Many peoples > leaves from Qt.. What happens? Or I'm mistake? :) Let's do some math. There is around 160 maintainer positions in Qt (a quick count of on the maintainers wiki page) Many maintainers are a maintainer as part of their job duties. Not many people these days have the same job for more than 5-6 years. If it takes 1-2 years to get to a state to become maintainer, that leaves around 4 years as a maintainer. If we assume that the maintainer is around for 4 years and there is effective 10 months per year, then we should have 4 replacement maintainers each month. I'm not sure I see something worrying in numbers alone. /Sune _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at qt.io Tue Mar 20 09:34:35 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 20 Mar 2018 08:34:35 +0000 Subject: [Development] Qt API review process (was: Re: Qt 5.11 Alpha released) In-Reply-To: References: , , Message-ID: (comment below) > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Jani Heikkinen > Subject: [Development] Qt API review process (was: Re: Qt 5.11 Alpha > released) > > Hi all, > > We have API review ongoing for Qt 5.11. For me our process for that is a bit > unclear; At which point we can say the review is really done? There are > comments in the reviews but then pretty much nothing... At some there is -1, > few +1 but that's it. I think we should clarify the process so that we can more > easily see the status there. That's why I propose following: > > 1) API review for the module is ready when there is '+2' (from Module/Chief > Maintainer) > 2) During the review reviewer must add 'Code Review -1/-2' if there is > something which should be corrected before we can agree API review to be > ready. And vice versa: if API seems to be OK +1 should be added to indicate API > is reviewed. > 3) Reviewer needs to create a bug report about the findings. That makes it > easier to follow up & we can add needed ones in the release blocker list. > * These bug reports should be added in review's comment field as well. And if > one is something which really needs to be fixed before release reviewer should > add the issue in release blocker list. > 4) API review for module needs to be updated in gerrit until it gets '+2'. After > that no more updates. That way we can link the approved review in releasing > wiki for the evidence :D I would rather create a task in JIRA for the review itself, with priority 1 and appropriate fixVersion. Any subsequent findings could be made subtasks of this task. This automatically makes the API review part of the blockers list, and makes sure everyone understands that this needs to be done before a release. Regards Kai From alexander.blasche at qt.io Tue Mar 20 10:32:09 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 20 Mar 2018 09:32:09 +0000 Subject: [Development] Stepping down as maintainer In-Reply-To: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Gunnar Sletta > Sent: Monday, 19 March 2018 13:40 ... > I've already spoken with Eskil and Lars, and propose the following list of people > to formally take over my areas: > > Tor Arne Vestby - QPA and window system integration > Laszlo Agocs - OpenGL/Vulkan > Eirik Aavitsland - Image Formats and QPainter > Andy Nichols - Scene Graph We have a couple of QTBUG components for which Gunnar is default assignee. Would the following reallocation reflect the above agreements? GUI: Basic Input System (keyboard, mouse, touch) -> Tor Arne GUI: Graphics Performance -> Laszlo GUI: OpenGL -> Laszlo GUI: Painting -> Erik QtQuick: Graphical Effects -> Laszlo QtQuick: Scenegraph -> Andy Nicols If not, please suggest specific changes. -- Alex From denis.shienkov at gmail.com Tue Mar 20 10:35:52 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 20 Mar 2018 12:35:52 +0300 Subject: [Development] Stepping down as maintainer In-Reply-To: References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: <41d57ab7-15cb-3f6a-2b88-e10231dac469@gmail.com> Hi. Maybe, you can to consider some "yum-yum" for attraction of community maintainers? For example, to allow them to use the commercial license in own purposes, or, something else. ;) 20.03.2018 11:09, Tuukka Turunen пишет: > Hi, > > It would be very good to get more contributors and maintainers also from the community and companies who offer Qt services. Lately we have had some community maintainers step down and replaced by people from The Qt Company. This is fine to some degree, but we should also have new persons from the community and ecosystem step up. > > Overall the amount of community contributions to Qt is still around the same 30% as it has been. So we have not been getting any better or worse in that regard. > > Yours, > > Tuukka > > On 19/03/2018, 19.33, "Development on behalf of Sune Vuorela" wrote: > > On 2018-03-19, Denis Shienkov wrote: > > As I can see recently, is is not a good tendence in Qt... Many peoples > > leaves from Qt.. What happens? Or I'm mistake? :) > > Let's do some math. > > There is around 160 maintainer positions in Qt (a quick count of on > the maintainers wiki page) > > Many maintainers are a maintainer as part of their job duties. Not many > people these days have the same job for more than 5-6 years. If it takes > 1-2 years to get to a state to become maintainer, that leaves around 4 > years as a maintainer. > > If we assume that the maintainer is around for 4 years and there is > effective 10 months per year, then we should have 4 replacement > maintainers each month. > > I'm not sure I see something worrying in numbers alone. > > /Sune > > > _______________________________________________ > 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 edward.welbourne at qt.io Tue Mar 20 11:19:08 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 20 Mar 2018 10:19:08 +0000 Subject: [Development] Qt API review process (was: Re: Qt 5.11 Alpha released) In-Reply-To: References: , , , Message-ID: Kai Koehne (20 March 2018 09:34) > I would rather create a task in JIRA for the review itself, with priority 1 > and appropriate fixVersion. Any subsequent findings could be made subtasks of > this task. > > This automatically makes the API review part of the blockers list, and makes sure > everyone understands that this needs to be done before a release. Good idea - I'll add a --task[-number] option to the api-review-gen script; if you open that bug and tell me its ID, I'll exercise this option when next I run the script (hopefully later today) to pick up all the changes folk have made in response to reviews so far, How will the fact that I abandon reviews once they have +2 (or we ship a release) bear on that task's view of them ? Eddy. From jeanmichael.celerier at gmail.com Tue Mar 20 11:26:13 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 20 Mar 2018 11:26:13 +0100 Subject: [Development] Stepping down as maintainer In-Reply-To: <41d57ab7-15cb-3f6a-2b88-e10231dac469@gmail.com> References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> <41d57ab7-15cb-3f6a-2b88-e10231dac469@gmail.com> Message-ID: > For example, to allow them to use the commercial license in own purposes, or, something else. ;) Are there that many people interested in commercial licenses ? I think that more people are looking to have *fun* and feel welcome contributing, especially in the OSS world. Look for instance how contributions are handled in: * Rust: https://github.com/rust-lang/rust/pull/49173 * Electron: https://github.com/electron/electron/pull/12301 * Dear ImGui: https://github.com/ocornut/imgui/pull/1638 * Python: https://github.com/python/cpython/pull/6142 Overall, it feels much more frictionless to contribute to these kinds of project - and it does not really matter if this is true in practice it is or not: most people don't judge with cold, hard scientific facts, for the better or worse, especially when considering decisions such as "to which famous open source project should I contribute?". Another point is that there is no real Qt ecosystem : it's either contribute to big entities such as Qt itself & KDE or have a small forgotten library used by a whole 3 people on github / inqlude / qpm, but there does not seem to be easy "entryway drug" which can easily discourage newcomers. Best, Jean-Michaël ------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Mar 20, 2018 at 10:35 AM, Denis Shienkov wrote: > Hi. > > Maybe, you can to consider some "yum-yum" for attraction of community > maintainers? > > For example, to allow them to use the commercial license in own purposes, > or, something else. ;) > > 20.03.2018 11:09, Tuukka Turunen пишет: > > Hi, > > It would be very good to get more contributors and maintainers also from the community and companies who offer Qt services. Lately we have had some community maintainers step down and replaced by people from The Qt Company. This is fine to some degree, but we should also have new persons from the community and ecosystem step up. > > Overall the amount of community contributions to Qt is still around the same 30% as it has been. So we have not been getting any better or worse in that regard. > > Yours, > > Tuukka > > On 19/03/2018, 19.33, "Development on behalf of Sune Vuorela" wrote: > > On 2018-03-19, Denis Shienkov wrote: > > As I can see recently, is is not a good tendence in Qt... Many peoples > > leaves from Qt.. What happens? Or I'm mistake? :) > > Let's do some math. > > There is around 160 maintainer positions in Qt (a quick count of on > the maintainers wiki page) > > Many maintainers are a maintainer as part of their job duties. Not many > people these days have the same job for more than 5-6 years. If it takes > 1-2 years to get to a state to become maintainer, that leaves around 4 > years as a maintainer. > > If we assume that the maintainer is around for 4 years and there is > effective 10 months per year, then we should have 4 replacement > maintainers each month. > > I'm not sure I see something worrying in numbers alone. > > /Sune > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Tue Mar 20 11:46:30 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 20 Mar 2018 10:46:30 +0000 Subject: [Development] Stepping down as maintainer In-Reply-To: References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: > On 20 Mar 2018, at 10:32, Alex Blasche wrote: > > We have a couple of QTBUG components for which Gunnar is default assignee. Would the following reallocation reflect the above agreements? > > GUI: Basic Input System (keyboard, mouse, touch) -> Tor Arne Typically I take care of Wacom tablet bugs on macOS and Linux, I or Gatis or Laszlo take care of touch and mouse on Linux, and Gatis takes care of keyboard (at least on Linux). Other people do more of the work on other platforms: Tor Arne (and sometimes others) on macOS and iOS, Friedemann (and sometimes others) on Windows. But the rules can’t be that fine-grained since people don’t always fill in the platform, and it’s a free-text field. (Unless we can make platform a required multiple-choice field? Should we?) So I wouldn’t mind being the default assignee for those, and can triage further. From alexander.blasche at qt.io Tue Mar 20 12:00:27 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 20 Mar 2018 11:00:27 +0000 Subject: [Development] Stepping down as maintainer In-Reply-To: References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: > -----Original Message----- > From: Shawn Rutledge > > GUI: Basic Input System (keyboard, mouse, touch) -> Tor Arne > > Typically I take care of Wacom tablet bugs on macOS and Linux, I or Gatis or > Laszlo take care of touch and mouse on Linux, and Gatis takes care of keyboard > (at least on Linux). Other people do more of the work on other platforms: Tor > Arne (and sometimes others) on macOS and iOS, Friedemann (and sometimes > others) on Windows. But the rules can’t be that fine-grained since people don’t > always fill in the platform, and it’s a free-text field. (Unless we can make > platform a required multiple-choice field? Should we?) So I wouldn’t mind being > the default assignee for those, and can triage further. Thank you for stepping up. I can add additional people to the notification. It means that you are default assignee but everybody on the component watch list gets an email when an issue is created for this component. Unless anybody objects then I will add the relevant people to the notification list. -- Alex From jani.heikkinen at qt.io Tue Mar 20 12:17:40 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 20 Mar 2018 11:17:40 +0000 Subject: [Development] Maintainers, your actions needed: Qt 5.9.5 changes files In-Reply-To: References: Message-ID: Still some changes files under work. Please finalize remaining ones now br, jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, March 16, 2018 3:21 PM To: development at qt-project.org Subject: [Development] Maintainers, your actions needed: Qt 5.9.5 changes files Hi all, Initial ones done. Please do needed modifications & get approval as soon as possible. Files here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.9.5%22,n,z br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From eskil.abrahamsen-blomfeldt at qt.io Tue Mar 20 13:11:38 2018 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Tue, 20 Mar 2018 13:11:38 +0100 Subject: [Development] Stepping down as maintainer In-Reply-To: References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: Den 20.03.2018 10:32, skrev Alex Blasche: >> -----Original Message----- >> From: Development [mailto:development- >> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Gunnar Sletta >> Sent: Monday, 19 March 2018 13:40 > ... > >> I've already spoken with Eskil and Lars, and propose the following list of people >> to formally take over my areas: >> >> Tor Arne Vestby - QPA and window system integration >> Laszlo Agocs - OpenGL/Vulkan >> Eirik Aavitsland - Image Formats and QPainter >> Andy Nichols - Scene Graph > We have a couple of QTBUG components for which Gunnar is default assignee. Would the following reallocation reflect the above agreements? > > GUI: Basic Input System (keyboard, mouse, touch) -> Tor Arne > GUI: Graphics Performance -> Laszlo > GUI: OpenGL -> Laszlo > GUI: Painting -> Erik > QtQuick: Graphical Effects -> Laszlo > QtQuick: Scenegraph -> Andy Nicols Hi, QtQuick: Graphical Effects can be assigned to Graphics Team in Qt if no other candidate steps up. It currently has no maintainer in the official list, so we didn't actually discuss it yet, but in practice, there has been very little activity in that repository and I have usually been handling meta-stuff like the changelog. It would be great to have a dedicated maintainer for it, in my opinion, but if no one volunteers, I can take it for now. -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io The Future is Written with Qt www.qtworldsummit.com From Christian.Stromme at qt.io Tue Mar 20 13:55:48 2018 From: Christian.Stromme at qt.io (=?iso-8859-1?Q?Christian_Str=F8mme?=) Date: Tue, 20 Mar 2018 12:55:48 +0000 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status Message-ID: Hi, I'd like to nominate Valentyn Doroshchuk for Approver status. Val has been working full time for The Qt Company since mid 2017, and has and has actively been fixing and improving QtMultimedia since (which includes upstream fixes to GStreamer). This is his dashboard: https://codereview.qt-project.org/#/q/owner:%22VaL+Doroshchuk%22+status:merged,n,z -- Christian From eskil.abrahamsen-blomfeldt at qt.io Tue Mar 20 14:14:48 2018 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Tue, 20 Mar 2018 14:14:48 +0100 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status In-Reply-To: References: Message-ID: <8f7435ef-cadb-9a3a-3563-97ea2c5a0718@qt.io> Den 20.03.2018 13:55, skrev Christian Strømme: > Hi, > > I'd like to nominate Valentyn Doroshchuk for Approver status. Val has been working full time for The Qt Company since mid 2017, and has and has actively been fixing and improving QtMultimedia since (which includes upstream fixes to GStreamer). > > This is his dashboard: > https://codereview.qt-project.org/#/q/owner:%22VaL+Doroshchuk%22+status:merged,n,z Hi, +1 from me! Val is doing great work on Qt Multimedia and is currently one of the main contributor to this module. :) -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io The Future is Written with Qt www.qtworldsummit.com From Shawn.Rutledge at qt.io Tue Mar 20 14:27:37 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 20 Mar 2018 13:27:37 +0000 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status In-Reply-To: References: Message-ID: +1 from me From laszlo.agocs at qt.io Tue Mar 20 14:29:08 2018 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Tue, 20 Mar 2018 13:29:08 +0000 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status In-Reply-To: References: Message-ID: +1 from me as well. Cheers, Laszlo -----Original Message----- From: Development On Behalf Of Shawn Rutledge Sent: tirsdag 20. mars 2018 14.28 To: development at qt-project.org Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status +1 from me _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andre.hartmann at iseg-hv.de Tue Mar 20 15:02:11 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Tue, 20 Mar 2018 15:02:11 +0100 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status In-Reply-To: References: Message-ID: <780c9dfe-3f1a-99df-31ce-64fd20288755@iseg-hv.de> +1 from my side also :) André Am 20.03.2018 um 14:29 schrieb Laszlo Agocs: > +1 from me as well. > > Cheers, > Laszlo > > -----Original Message----- > From: Development On Behalf Of Shawn Rutledge > Sent: tirsdag 20. mars 2018 14.28 > To: development at qt-project.org > Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status > > +1 from me > _______________________________________________ > 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 timur.pocheptsov at qt.io Tue Mar 20 15:14:05 2018 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Tue, 20 Mar 2018 14:14:05 +0000 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status In-Reply-To: <780c9dfe-3f1a-99df-31ce-64fd20288755@iseg-hv.de> References: , <780c9dfe-3f1a-99df-31ce-64fd20288755@iseg-hv.de> Message-ID: +1 from me. Best regards, Timur. ________________________________ From: Development on behalf of André Hartmann Sent: Tuesday, March 20, 2018 3:02:11 PM To: Laszlo Agocs; development at qt-project.org Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status +1 from my side also :) André Am 20.03.2018 um 14:29 schrieb Laszlo Agocs: > +1 from me as well. > > Cheers, > Laszlo > > -----Original Message----- > From: Development On Behalf Of Shawn Rutledge > Sent: tirsdag 20. mars 2018 14.28 > To: development at qt-project.org > Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status > > +1 from me > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.shaw at qt.io Tue Mar 20 17:19:35 2018 From: andy.shaw at qt.io (Andy Shaw) Date: Tue, 20 Mar 2018 16:19:35 +0000 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status In-Reply-To: References: , <780c9dfe-3f1a-99df-31ce-64fd20288755@iseg-hv.de>, Message-ID: +1 from me too. Andy ________________________________ Fra: Development på vegne av Timur Pocheptsov Sendt: 20. mars 2018 15:14:05 Til: André Hartmann; Laszlo Agocs; development at qt-project.org Emne: Re: [Development] Nominating Valentyn Doroshchuk for Approver status +1 from me. Best regards, Timur. ________________________________ From: Development on behalf of André Hartmann Sent: Tuesday, March 20, 2018 3:02:11 PM To: Laszlo Agocs; development at qt-project.org Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status +1 from my side also :) André Am 20.03.2018 um 14:29 schrieb Laszlo Agocs: > +1 from me as well. > > Cheers, > Laszlo > > -----Original Message----- > From: Development On Behalf Of Shawn Rutledge > Sent: tirsdag 20. mars 2018 14.28 > To: development at qt-project.org > Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status > > +1 from me > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.savi at gaess.ch Tue Mar 20 21:07:06 2018 From: daniel.savi at gaess.ch (Daniel Savi) Date: Tue, 20 Mar 2018 21:07:06 +0100 Subject: [Development] Problem with merging a patch Message-ID: Dear developers My journey into Qt development came again to a sudden halt. I've commited this patch (Iaa8ec0246aaba004d98c9e8c66609795101519a9) and Lars Knoll gave it green light after comments from him, André Hartman and Edward Welbourne. Now, when I hit the "Merge patch Set to Staging"-button, I'm getting this message: Code Review - Error Your change could not be merged due to a path conflict. Make sure you staged all dependencies of this change. If the change has dependencies which are currently INTEGRATING, try again when the integration finishes. Otherwise please rebase the change locally and upload the rebased commit for review. I thought that my local history looks pretty clean. "git log --oneline" gives me this: 2702f9d3fe Add image quality handling to QTextImageFormat 36385fb2fa Add more formatting to QTextDocumentWriter when writing ODF files 96340a6556 Mark QCoreApplication::applicationPid() as const function The third patch is from upstream. Can anyone give me a hint what I should do to solve this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Tue Mar 20 21:12:45 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 20 Mar 2018 20:12:45 +0000 Subject: [Development] Problem with merging a patch In-Reply-To: References: Message-ID: <35AC4B84-C196-42AC-A66B-CC764B30D4E6@qt.io> Hi Daniel, Gerrit detected a conflict when it tried to merge your patch. The solution to the problem is usually to rebase your patches onto the latest HEAD of the branch you're targeting. Basically: git fetch git rebase origin/branch (dev or 5.11, whichever one you're targeting) (if required resolve any conflicts) git push HEAD:refs/for/branch Cheers, Lars > On 20 Mar 2018, at 21:07, Daniel Savi wrote: > > Dear developers > My journey into Qt development came again to a sudden halt. I've commited this patch (Iaa8ec0246aaba004d98c9e8c66609795101519a9) and Lars Knoll gave it green light after comments from him, André Hartman and Edward Welbourne. > Now, when I hit the "Merge patch Set to Staging"-button, I'm getting this message: > > Code Review - Error > Your change could not be merged due to a path conflict. Make sure you staged all dependencies of this change. If the change has dependencies which are currently INTEGRATING, try again when the integration finishes. Otherwise please rebase the change locally and upload the rebased commit for review. > > I thought that my local history looks pretty clean. "git log --oneline" gives me this: > 2702f9d3fe Add image quality handling to QTextImageFormat > 36385fb2fa Add more formatting to QTextDocumentWriter when writing ODF files > 96340a6556 Mark QCoreApplication::applicationPid() as const function > > The third patch is from upstream. > Can anyone give me a hint what I should do to solve this? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tony.sarajarvi at qt.io Wed Mar 21 06:59:50 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 21 Mar 2018 05:59:50 +0000 Subject: [Development] CI maintenance break on March 21 @ 8:00 - 9:00 EET In-Reply-To: References: Message-ID: Hi Reminding you all that this maintenance break is about to happen now. Good luck to us all. -T From: Tony Sarajärvi Sent: perjantai 9. maaliskuuta 2018 14.08 To: development at qt-project.org Cc: Qt Development Subject: CI maintenance break on March 21 @ 8:00 - 9:00 EET Hi We'd like to have a small maintenance break. If the suggested time doesn't fit you at all, please contact us and we'll reschedule. Purpose: We'd like to update the firmware on the hardware running Coin. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Wed Mar 21 07:52:41 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 21 Mar 2018 06:52:41 +0000 Subject: [Development] CI maintenance break on March 21 @ 8:00 - 9:00 EET In-Reply-To: References: Message-ID: Hi No problems so far, but so many firmware updates one after the other that this one hour window is not going to be enough. We are going to run it a few minutes past that. -Tony From: Tony Sarajärvi Sent: keskiviikko 21. maaliskuuta 2018 8.00 To: development at qt-project.org Cc: Qt Development Subject: RE: CI maintenance break on March 21 @ 8:00 - 9:00 EET Hi Reminding you all that this maintenance break is about to happen now. Good luck to us all. -T From: Tony Sarajärvi Sent: perjantai 9. maaliskuuta 2018 14.08 To: development at qt-project.org Cc: Qt Development > Subject: CI maintenance break on March 21 @ 8:00 - 9:00 EET Hi We'd like to have a small maintenance break. If the suggested time doesn't fit you at all, please contact us and we'll reschedule. Purpose: We'd like to update the firmware on the hardware running Coin. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Wed Mar 21 08:17:59 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 21 Mar 2018 07:17:59 +0000 Subject: [Development] CI maintenance break on March 21 @ 8:00 - 9:00 EET In-Reply-To: References: Message-ID: All back up again! If you see unexpected problems, due contact us again at qt.ci at qt.io -Tony From: Tony Sarajärvi Sent: keskiviikko 21. maaliskuuta 2018 8.53 To: 'development at qt-project.org' Cc: Qt Development Subject: RE: CI maintenance break on March 21 @ 8:00 - 9:00 EET Hi No problems so far, but so many firmware updates one after the other that this one hour window is not going to be enough. We are going to run it a few minutes past that. -Tony From: Tony Sarajärvi Sent: keskiviikko 21. maaliskuuta 2018 8.00 To: development at qt-project.org Cc: Qt Development > Subject: RE: CI maintenance break on March 21 @ 8:00 - 9:00 EET Hi Reminding you all that this maintenance break is about to happen now. Good luck to us all. -T From: Tony Sarajärvi Sent: perjantai 9. maaliskuuta 2018 14.08 To: development at qt-project.org Cc: Qt Development > Subject: CI maintenance break on March 21 @ 8:00 - 9:00 EET Hi We'd like to have a small maintenance break. If the suggested time doesn't fit you at all, please contact us and we'll reschedule. Purpose: We'd like to update the firmware on the hardware running Coin. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Wed Mar 21 08:28:45 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 21 Mar 2018 07:28:45 +0000 Subject: [Development] Stepping down as maintainer In-Reply-To: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: <29DE5CA0-5A3A-478F-9E01-6B44891C025B@qt.io> Hi, Thanks a lot Gunnar for having maintained these modules over the past years! +1 from my side for all the new nominations. Cheers, Lars > On 19 Mar 2018, at 13:39, Gunnar Sletta wrote: > > Hi, > > After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. > > I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: > > Tor Arne Vestby - QPA and window system integration > Laszlo Agocs - OpenGL/Vulkan > Eirik Aavitsland - Image Formats and QPainter > Andy Nichols - Scene Graph > > (Other specific maintainers in QtGui stay unchanged) > > Thanks, > Gunnar > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From eskil.abrahamsen-blomfeldt at qt.io Wed Mar 21 09:17:51 2018 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Wed, 21 Mar 2018 09:17:51 +0100 Subject: [Development] Stepping down as maintainer In-Reply-To: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: <2de8a55f-e1d7-7076-c5d1-a9abf07ce545@qt.io> Den 19.03.2018 13:39, skrev Gunnar Sletta: > Hi, > > After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. > > I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: > > Tor Arne Vestby - QPA and window system integration > Laszlo Agocs - OpenGL/Vulkan > Eirik Aavitsland - Image Formats and QPainter > Andy Nichols - Scene Graph > > (Other specific maintainers in QtGui stay unchanged) As Gunnar mentioned, all the nominations have a +1 from me :) Note that Paul Olav Tvete is actually the current maintainer of QPA, but when reorganizing we though it made sense to put it together with the "windowing system bits". -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io The Future is Written with Qt www.qtworldsummit.com From sergio.martins at kdab.com Wed Mar 21 12:33:06 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 21 Mar 2018 11:33:06 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver Message-ID: <7768537419eb3a899b639c7172d353cd@kdab.com> Hi, Albert has been a long time contributor to KDE and Qt and very well known in the community. His dashboards speak for himself, with many bugs fixed: (For some reason pasting-and-opening URLs from gerrit is broken, so you'll have to search yourself) at KDAB: owner:"Albert Astals Cid " at Canonical: owner:albert.astals at canonical.com on his free-time with KDE hat: owner:"Albert Astals Cid " And recently he was tricked into fixing many printing and CUPS bugs, so thanks Albert! Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives somewhat near me, in the Iberian peninsula. 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 Wed Mar 21 12:49:10 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 21 Mar 2018 11:49:10 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <7768537419eb3a899b639c7172d353cd@kdab.com> References: <7768537419eb3a899b639c7172d353cd@kdab.com> Message-ID: <61B8A48D-7FB3-4C22-B3DF-2ECC46A6481D@qt.io> He isn’t an approver yet? I agree, that we should change that :) +1 from my side! Cheers, Lars > On 21 Mar 2018, at 12:33, Sérgio Martins wrote: > > Hi, > > > Albert has been a long time contributor to KDE and Qt and very well known in the community. > > His dashboards speak for himself, with many bugs fixed: > (For some reason pasting-and-opening URLs from gerrit is broken, so you'll have to search yourself) > > > at KDAB: > owner:"Albert Astals Cid " > > > at Canonical: > owner:albert.astals at canonical.com > > > on his free-time with KDE hat: > owner:"Albert Astals Cid " > > > > And recently he was tricked into fixing many printing and CUPS bugs, so thanks Albert! > > > Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives somewhat near me, in the Iberian peninsula. > > > > 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 From cavendish.qi at gmail.com Wed Mar 21 12:56:38 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 21 Mar 2018 12:56:38 +0100 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <7768537419eb3a899b639c7172d353cd@kdab.com> References: <7768537419eb3a899b639c7172d353cd@kdab.com> Message-ID: https://codereview.qt-project.org/#/q/owner:%22Albert+Astals+Cid+%253Calbert.astals.cid%2540kdab.com%253E%22,n,z https://codereview.qt-project.org/#/q/owner:albert.astals%2540canonical.com,n,z https://codereview.qt-project.org/#/q/owner:%22Albert+Astals+Cid+%253Caacid%2540kde.org%253E%22,n,z Chrome is good to copy and paste those urls. +1, but which one of above three gerrit accounts will get the permission? And how about his career future? --Liang On 21 March 2018 at 12:33, Sérgio Martins wrote: > Hi, > > > Albert has been a long time contributor to KDE and Qt and very well known > in the community. > > His dashboards speak for himself, with many bugs fixed: > (For some reason pasting-and-opening URLs from gerrit is broken, so you'll > have to search yourself) > > > at KDAB: > owner:"Albert Astals Cid " > > > at Canonical: > owner:albert.astals at canonical.com > > > on his free-time with KDE hat: > owner:"Albert Astals Cid " > > > > And recently he was tricked into fixing many printing and CUPS bugs, so > thanks Albert! > > > Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives > somewhat near me, in the Iberian peninsula. > > > > 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 andre.hartmann at iseg-hv.de Wed Mar 21 13:02:44 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Wed, 21 Mar 2018 13:02:44 +0100 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <61B8A48D-7FB3-4C22-B3DF-2ECC46A6481D@qt.io> References: <7768537419eb3a899b639c7172d353cd@kdab.com> <61B8A48D-7FB3-4C22-B3DF-2ECC46A6481D@qt.io> Message-ID: <060c9398-bd67-e19a-ddf6-491e6e56cf78@iseg-hv.de> +1 of course :) André Am 21.03.2018 um 12:49 schrieb Lars Knoll: > He isn’t an approver yet? I agree, that we should change that :) > > +1 from my side! > > Cheers, > Lars > >> On 21 Mar 2018, at 12:33, Sérgio Martins wrote: >> >> Hi, >> >> >> Albert has been a long time contributor to KDE and Qt and very well known in the community. >> >> His dashboards speak for himself, with many bugs fixed: >> (For some reason pasting-and-opening URLs from gerrit is broken, so you'll have to search yourself) >> >> >> at KDAB: >> owner:"Albert Astals Cid " >> >> >> at Canonical: >> owner:albert.astals at canonical.com >> >> >> on his free-time with KDE hat: >> owner:"Albert Astals Cid " >> >> >> >> And recently he was tricked into fixing many printing and CUPS bugs, so thanks Albert! >> >> >> Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives somewhat near me, in the Iberian peninsula. >> >> >> >> 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 > From edward.welbourne at qt.io Wed Mar 21 13:00:05 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 21 Mar 2018 12:00:05 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <61B8A48D-7FB3-4C22-B3DF-2ECC46A6481D@qt.io> References: <7768537419eb3a899b639c7172d353cd@kdab.com>, <61B8A48D-7FB3-4C22-B3DF-2ECC46A6481D@qt.io> Message-ID: Lars Knoll (21 March 2018 12:49) > He isn’t an approver yet? I agree, that we should change that :) My thought entirely ! +1, Eddy. From Shawn.Rutledge at qt.io Wed Mar 21 13:00:25 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 21 Mar 2018 12:00:25 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <7768537419eb3a899b639c7172d353cd@kdab.com> References: <7768537419eb3a899b639c7172d353cd@kdab.com> Message-ID: <9518C34C-7B4E-41D2-B5C5-7CD4A3E57562@qt.io> +1 from me From sergio.martins at kdab.com Wed Mar 21 13:07:17 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 21 Mar 2018 12:07:17 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: References: <7768537419eb3a899b639c7172d353cd@kdab.com> Message-ID: <7a3b9e1c1793b7d2624970a65768f5d1@kdab.com> On 2018-03-21 11:56, Liang Qi wrote: > https://codereview.qt-project.org/#/q/owner:%22Albert+Astals+Cid+%253Calbert.astals.cid%2540kdab.com%253E%22,n,z > > > https://codereview.qt-project.org/#/q/owner:albert.astals%2540canonical.com,n,z > > > https://codereview.qt-project.org/#/q/owner:%22Albert+Astals+Cid+%253Caacid%2540kde.org%253E%22,n,z > > > Chrome is good to copy and paste those urls. Still doesn't open on Firefox, but indeed opens on Chrome! > +1, but which one of above three gerrit accounts will get the > permission? > And how about his career future? Albert works for KDAB and that's his most active account. But since approvership sticks to the person and not the company I don't see a problem in giving it to his KDE account as well. 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 igor.mironchik at gmail.com Wed Mar 21 13:07:28 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Wed, 21 Mar 2018 15:07:28 +0300 Subject: [Development] Qt3D benchmark Message-ID: <04baeeaf-a8ab-82b9-3cb2-4a75326eb736@gmail.com> Hello, Would you like to see another benchmark application for Qt3D in the sources tree? I'm talking about 3DTree. Sources you can find at https://github.com/igormironchik/3Dtree ScreenShot If you would like to see this benchmark in Qt's sources I can prepare sources and submit a patch. What do you think? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20180321_150141.png Type: image/png Size: 303968 bytes Desc: not available URL: From rich at kde.org Wed Mar 21 15:59:01 2018 From: rich at kde.org (Richard Moore) Date: Wed, 21 Mar 2018 14:59:01 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: References: <7768537419eb3a899b639c7172d353cd@kdab.com> <61B8A48D-7FB3-4C22-B3DF-2ECC46A6481D@qt.io> Message-ID: +1 On 21 March 2018 at 12:00, Edward Welbourne wrote: > Lars Knoll (21 March 2018 12:49) > > He isn’t an approver yet? I agree, that we should change that :) > > My thought entirely ! > > +1, > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Wed Mar 21 16:27:38 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 21 Mar 2018 16:27:38 +0100 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <7768537419eb3a899b639c7172d353cd@kdab.com> References: <7768537419eb3a899b639c7172d353cd@kdab.com> Message-ID: <4052230.IsPnHTtaVS@frederik-thinkcentre-m93p> A big +1 from me as well :) Cheers, Frederik On onsdag 21. mars 2018 12.33.06 CET Sérgio Martins wrote: > Hi, > > > Albert has been a long time contributor to KDE and Qt and very well > known in the community. > > His dashboards speak for himself, with many bugs fixed: > (For some reason pasting-and-opening URLs from gerrit is broken, so > you'll have to search yourself) > > > at KDAB: > owner:"Albert Astals Cid " > > > at Canonical: > owner:albert.astals at canonical.com > > > on his free-time with KDE hat: > owner:"Albert Astals Cid " > > > > And recently he was tricked into fixing many printing and CUPS bugs, so > thanks Albert! > > > Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives > somewhat near me, in the Iberian peninsula. > > > > Regards, From andy.shaw at qt.io Wed Mar 21 17:02:35 2018 From: andy.shaw at qt.io (Andy Shaw) Date: Wed, 21 Mar 2018 16:02:35 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <4052230.IsPnHTtaVS@frederik-thinkcentre-m93p> References: <7768537419eb3a899b639c7172d353cd@kdab.com> <4052230.IsPnHTtaVS@frederik-thinkcentre-m93p> Message-ID: A +1 from me too, his help with the printing side has been really valuable! Andy Development på vegne av Frederik Gladhorn skrev følgende den 21.03.2018, 16.27: A big +1 from me as well :) Cheers, Frederik On onsdag 21. mars 2018 12.33.06 CET Sérgio Martins wrote: > Hi, > > > Albert has been a long time contributor to KDE and Qt and very well > known in the community. > > His dashboards speak for himself, with many bugs fixed: > (For some reason pasting-and-opening URLs from gerrit is broken, so > you'll have to search yourself) > > > at KDAB: > owner:"Albert Astals Cid " > > > at Canonical: > owner:albert.astals at canonical.com > > > on his free-time with KDE hat: > owner:"Albert Astals Cid " > > > > And recently he was tricked into fixing many printing and CUPS bugs, so > thanks Albert! > > > Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives > somewhat near me, in the Iberian peninsula. > > > > Regards, _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From igor.mironchik at gmail.com Wed Mar 21 18:03:19 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Wed, 21 Mar 2018 20:03:19 +0300 Subject: [Development] Qt3D benchmark In-Reply-To: <04baeeaf-a8ab-82b9-3cb2-4a75326eb736@gmail.com> References: <04baeeaf-a8ab-82b9-3cb2-4a75326eb736@gmail.com> Message-ID: <593ae8de-8c67-f626-ff59-f79a19c1c529@gmail.com> Hi, I added possibility to turn off/on instanced rendering and random death. Waiting for your $0.02 :) On 21.03.2018 15:07, Igor Mironchik wrote: > > Hello, > > Would you like to see another benchmark application for Qt3D in the > sources tree? > > I'm talking about 3DTree. Sources you can find at > https://github.com/igormironchik/3Dtree > > ScreenShot > > If you would like to see this benchmark in Qt's sources I can prepare > sources and submit a patch. > > What do you think? > > Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20180321_150141.png Type: image/png Size: 303968 bytes Desc: not available URL: From jpnurmi at qt.io Wed Mar 21 22:10:41 2018 From: jpnurmi at qt.io (J-P Nurmi) Date: Wed, 21 Mar 2018 21:10:41 +0000 Subject: [Development] Stepping down as maintainer In-Reply-To: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: <5E7C05D4-E484-4FF5-80B2-C076F534FC66@qt.io> > On 19 Mar 2018, at 13:39, Gunnar Sletta wrote: > > Hi, > > After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. > > I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: > > Tor Arne Vestby - QPA and window system integration > Laszlo Agocs - OpenGL/Vulkan > Eirik Aavitsland - Image Formats and QPainter > Andy Nichols - Scene Graph > > (Other specific maintainers in QtGui stay unchanged) Gunnar, thank you for all the awesomeness you have contributed to Qt. +1 for the new nominees. -- J-P Nurmi From andre.hartmann at iseg-hv.de Fri Mar 23 08:13:35 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 23 Mar 2018 08:13:35 +0100 Subject: [Development] Patch stucking in integration Message-ID: <442585d8-8123-941d-1701-420082e66690@iseg-hv.de> Hello, my patch is stucking in integration since yesterday: https://codereview.qt-project.org/#/c/223840/ Can someone with mighty powers have a look please? Normally, the integration takes 10 minutes. Thanks, André From andre.hartmann at iseg-hv.de Fri Mar 23 08:15:08 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 23 Mar 2018 08:15:08 +0100 Subject: [Development] Patch stucking in integration In-Reply-To: <442585d8-8123-941d-1701-420082e66690@iseg-hv.de> References: <442585d8-8123-941d-1701-420082e66690@iseg-hv.de> Message-ID: Sorry, wrong link: I meant THIS one: https://codereview.qt-project.org/#/c/224190/ Thanks. Am 23.03.2018 um 08:13 schrieb André Hartmann: > Hello, > > my patch is stucking in integration since yesterday: > > https://codereview.qt-project.org/#/c/223840/ > > Can someone with mighty powers have a look please? Normally, the > integration takes 10 minutes. > > Thanks, > André > From jani.heikkinen at qt.io Fri Mar 23 08:25:47 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 23 Mar 2018 07:25:47 +0000 Subject: [Development] Patch stucking in integration In-Reply-To: References: <442585d8-8123-941d-1701-420082e66690@iseg-hv.de>, Message-ID: I have informed CI team about the issue. I could cancel the integration & re-stage it but I didn't because CI team might want to do some studies first. br, Jani ________________________________________ From: Development on behalf of André Hartmann Sent: Friday, March 23, 2018 9:15 AM To: development at qt-project.org Subject: Re: [Development] Patch stucking in integration Sorry, wrong link: I meant THIS one: https://codereview.qt-project.org/#/c/224190/ Thanks. Am 23.03.2018 um 08:13 schrieb André Hartmann: > Hello, > > my patch is stucking in integration since yesterday: > > https://codereview.qt-project.org/#/c/223840/ > > Can someone with mighty powers have a look please? Normally, the > integration takes 10 minutes. > > Thanks, > André > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andre.hartmann at iseg-hv.de Fri Mar 23 08:38:35 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 23 Mar 2018 08:38:35 +0100 Subject: [Development] Patch stucking in integration In-Reply-To: References: <442585d8-8123-941d-1701-420082e66690@iseg-hv.de> Message-ID: <23da3db6-d2cd-f23b-b770-6956dd060101@iseg-hv.de> Thanks Jani! Am 23.03.2018 um 08:25 schrieb Jani Heikkinen: > I have informed CI team about the issue. I could cancel the integration & re-stage it but I didn't because CI team might want to do some studies first. > > br, > Jani > ________________________________________ > From: Development on behalf of André Hartmann > Sent: Friday, March 23, 2018 9:15 AM > To: development at qt-project.org > Subject: Re: [Development] Patch stucking in integration > > Sorry, wrong link: I meant THIS one: > > https://codereview.qt-project.org/#/c/224190/ > > Thanks. > > Am 23.03.2018 um 08:13 schrieb André Hartmann: >> Hello, >> >> my patch is stucking in integration since yesterday: >> >> https://codereview.qt-project.org/#/c/223840/ >> >> Can someone with mighty powers have a look please? Normally, the >> integration takes 10 minutes. >> >> Thanks, >> André >> > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Dipl.-Ing. (FH) André Hartmann Softwareentwicklung / Software Development E-Mail: andre.hartmann at iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 26996-21 iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY. iseg-hv.de | iseg-hv.com | download.iseg-hv.com Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Umsatzsteuer-Id: / VAT-ID: DE812508942 News / Information https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - Unified Control Software https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep the price https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM Detectors https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! Product catalog 2017 / 2018 released https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with reversible polarity Links https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay connected! https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE | Tutorials and more ... https://www.twitter.com/iseg_hv iseg on TWITTER | please follow! https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg CATALOG | download product catalog as PDF http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, firmware and more... 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 destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From mitch.curtis at qt.io Fri Mar 23 14:44:03 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 23 Mar 2018 13:44:03 +0000 Subject: [Development] Rendering only items that are visible in Qt Quick Message-ID: I'd like to get some discussion going around this: https://bugreports.qt.io/browse/QTBUG-67274 As I understand it, clipping (the "clip" property) doesn't prevent items that aren't visible (in the sense of being out of the viewport, not the "visible" property) from actually being rendered. It would be useful if we had a way to do this with minimal effort from the user. I'm thinking of a e.g. a property or flag in QQuickItem that, when set, would cause the scenegraph to use the shape (could start off as just being a bounding rect) of child items to determine whether or not that item is visible with regards to its parents bounding rect. That way, any regular old item can benefit from it easily. Does anyone else have ideas about this? Comments about how it will never work and I should feel bad for suggesting it? Far superior alternatives? Please, share your thoughts! :D From paolo.angelelli at qt.io Fri Mar 23 15:03:14 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Fri, 23 Mar 2018 15:03:14 +0100 Subject: [Development] Rendering only items that are visible in Qt Quick In-Reply-To: References: Message-ID: <20180323150314.525f23b7@qdesktop> Could one way be to change QList QQuickItemPrivate::paintOrderChildItems() const; into a virtual method, and reimplement it like in flickables or the like to prevent returning what isn't currently visible? That was at least my idea when i was looking at how to do this on maps (where there are potentially plenty of items, but also potentially only few are visible). Could this work? or what cases would this break? On Fri, 23 Mar 2018 13:44:03 +0000 Mitch Curtis wrote: > I'd like to get some discussion going around this: > > https://bugreports.qt.io/browse/QTBUG-67274 > > As I understand it, clipping (the "clip" property) doesn't prevent items that aren't visible (in the sense of being out of the viewport, not the "visible" property) from actually being rendered. > > It would be useful if we had a way to do this with minimal effort from the user. I'm thinking of a e.g. a property or flag in QQuickItem that, when set, would cause the scenegraph to use the shape (could start off as just being a bounding rect) of child items to determine whether or not that item is visible with regards to its parents bounding rect. That way, any regular old item can benefit from it easily. > > Does anyone else have ideas about this? > > Comments about how it will never work and I should feel bad for suggesting it? > > Far superior alternatives? > > Please, share your thoughts! :D > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jeanmichael.celerier at gmail.com Fri Mar 23 15:21:43 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 23 Mar 2018 15:21:43 +0100 Subject: [Development] Rendering only items that are visible in Qt Quick In-Reply-To: References: Message-ID: > Far superior alternatives? Maybe not "far" superior, but AFAIK QGraphicsScene / QGraphicsView handles this. ------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, Mar 23, 2018 at 2:44 PM, Mitch Curtis wrote: > I'd like to get some discussion going around this: > > https://bugreports.qt.io/browse/QTBUG-67274 > > As I understand it, clipping (the "clip" property) doesn't prevent items > that aren't visible (in the sense of being out of the viewport, not the > "visible" property) from actually being rendered. > > It would be useful if we had a way to do this with minimal effort from the > user. I'm thinking of a e.g. a property or flag in QQuickItem that, when > set, would cause the scenegraph to use the shape (could start off as just > being a bounding rect) of child items to determine whether or not that item > is visible with regards to its parents bounding rect. That way, any regular > old item can benefit from it easily. > > Does anyone else have ideas about this? > > Comments about how it will never work and I should feel bad for suggesting > it? > > Far superior alternatives? > > Please, share your thoughts! :D > _______________________________________________ > 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 albert.astals.cid at kdab.com Fri Mar 23 16:08:12 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Fri, 23 Mar 2018 16:08:12 +0100 Subject: [Development] Rendering only items that are visible in Qt Quick In-Reply-To: References: Message-ID: <4159118.ibYsM2mKDi@yoga> El divendres, 23 de març de 2018, a les 14:44:03 CET, Mitch Curtis va escriure: > I'd like to get some discussion going around this: > > https://bugreports.qt.io/browse/QTBUG-67274 > > As I understand it, clipping (the "clip" property) doesn't prevent items > that aren't visible (in the sense of being out of the viewport, not the > "visible" property) from actually being rendered. > > It would be useful if we had a way to do this with minimal effort from the > user. I'm thinking of a e.g. a property or flag in QQuickItem that, when > set, would cause the scenegraph to use the shape (could start off as just > being a bounding rect) of child items to determine whether or not that item > is visible with regards to its parents bounding rect. That way, any regular > old item can benefit from it easily. > > Does anyone else have ideas about this? The culled property of QQuickItemPrivate makes things be skipped for rendering, so you could add something like QQuickItemPrivate::setChildrenCulled that used the geometries of children to set it's culled property. The problem is that this can get relatively inefficient if those geometries change (animations, etc) since you have to recalculate the culled property for every single change so given how supposedly fast graphics are at clipping you may be better of just using clipping? Cheers, Albert > > Comments about how it will never work and I should feel bad for suggesting > it? > > Far superior alternatives? > > Please, share your thoughts! :D > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Albert Astals Cid | albert.astals.cid 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 - The Qt, C++ and OpenGL Experts From Uwe.Rathmann at tigertal.de Fri Mar 23 16:32:16 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Fri, 23 Mar 2018 15:32:16 +0000 (UTC) Subject: [Development] Rendering only items that are visible in Qt Quick References: Message-ID: On Fri, 23 Mar 2018 13:44:03 +0000, Mitch Curtis wrote: > As I understand it, clipping (the "clip" property) doesn't prevent items > that aren't visible (in the sense of being out of the viewport, not the > "visible" property) from actually being rendered. In my framework ( https://github.com/uwerat/qskinny ) I'm blocking scene graph nodes for all invisible items, and also played with an implementation doing the same for items being outside the window ( or some other clip ). The challenge is not about preventing unnecessary nodes - it is about, how to call update, when an item, that had been blocked before, comes into a visible region. Item coordinates are relative to the parent and there is no notification when the absolute coordinates have changed. Introducing such a notification means running over the complete subtree below an item each time its position changes. At this point I gave up as I didn't saw how to implement it without introducing other significant performance penalties ? > Comments about how it will never work and I should feel bad for > suggesting it? Well, I never found something being written in the docs, but from reading the code I got the impression, that one very fundamental concept of Qt/ Quick is: fill the caches ( f.e scene graph ) as early and as much as possible, so that you don't have any delays later. Of course you have to pay with memory and startup performance, but you can't have both. Just to mention it - my framework implements exactly the opposite strategy: don't do anything expensive before it is really needed. My 2 cents, Uwe From yetanotherandreyev at gmail.com Fri Mar 23 17:39:17 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Fri, 23 Mar 2018 19:39:17 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style Message-ID: Hello! My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc project? I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ and want to create a proposal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Fri Mar 23 19:40:04 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 23 Mar 2018 18:40:04 +0000 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: Message-ID: Hello. Are there any screenshots of it? I read that entire page and the Silica docs but couldn’t see anything. Cheers. From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Alexey Andreyev Sent: Friday, 23 March 2018 5:39 PM To: development at qt-project.org Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style Hello! My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc project? I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ and want to create a proposal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yetanotherandreyev at gmail.com Fri Mar 23 19:55:31 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Fri, 23 Mar 2018 21:55:31 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: Message-ID: Silica cheat sheet: https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png Theme cheat sheet: https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png Icon reference: https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png code example: https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 Youtube video with timestamp for platform-specific PulleyMenu element example: https://youtu.be/jByW7UNmbxU?t=11m38s 2018-03-23 21:40 GMT+03:00 Mitch Curtis : > Hello. > > > > Are there any screenshots of it? I read that entire page and the Silica > docs but couldn’t see anything. > > > > Cheers. > > > > *From:* Development [mailto:development-bounces+mitch.curtis= > qt.io at qt-project.org] *On Behalf Of *Alexey Andreyev > *Sent:* Friday, 23 March 2018 5:39 PM > *To:* development at qt-project.org > *Subject:* [Development] [Google Summer of Code] [Project Ideas] Qt Quick > Controls 2 Sailfish Silica Style > > > > Hello! > My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc > project? > I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ > > and want to create a proposal. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yetanotherandreyev at gmail.com Fri Mar 23 20:48:59 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Fri, 23 Mar 2018 22:48:59 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: Message-ID: Thank you Mitch for the feedback! I've also tried to record current controls on a real device: https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) 2018-03-23 21:55 GMT+03:00 Alexey Andreyev : > Silica cheat sheet: > https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png > Theme cheat sheet: > https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png > Icon reference: > https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png > code example: > https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 > > Youtube video with timestamp for platform-specific PulleyMenu element > example: https://youtu.be/jByW7UNmbxU?t=11m38s > > > 2018-03-23 21:40 GMT+03:00 Mitch Curtis : > >> Hello. >> >> >> >> Are there any screenshots of it? I read that entire page and the Silica >> docs but couldn’t see anything. >> >> >> >> Cheers. >> >> >> >> *From:* Development [mailto:development-bounces+mitch.curtis= >> qt.io at qt-project.org] *On Behalf Of *Alexey Andreyev >> *Sent:* Friday, 23 March 2018 5:39 PM >> *To:* development at qt-project.org >> *Subject:* [Development] [Google Summer of Code] [Project Ideas] Qt >> Quick Controls 2 Sailfish Silica Style >> >> >> >> Hello! >> My name is Alexey, what do you think about Silica Style for QQC2 as a >> gsoc project? >> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >> >> and want to create a proposal. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cooljay.gupta at gmail.com Sat Mar 24 17:58:09 2018 From: cooljay.gupta at gmail.com (Jay Gupta) Date: Sat, 24 Mar 2018 22:28:09 +0530 Subject: [Development] [Google Summer of Code] Meson Native support for Qt Creator Message-ID: Hello all , i want to share my gsoc proposal with you all for the feedback . I have been in touch with Tobias Hunger and Jussi Pakkanen ( from meson) regarding this project. i have shared the draft on summerofcode site , please review it there OR here is the direct link : https://docs.google.com/document/d/18vL8XAgOruIHuo2FlSwn2dhvlYiBt vRG-SvPI5WzXYw/edit?usp=sharing thanks !! Best Regards, Jayaditya Gupta -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.mironchik at gmail.com Mon Mar 26 06:07:25 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 07:07:25 +0300 Subject: [Development] qDebug() Message-ID: Hello, Built sources from git repository (5.11 branch) doesn't print qDebug() messages to console. What I missed during the configuration process? Thank you. From timur.pocheptsov at qt.io Mon Mar 26 06:33:26 2018 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Mon, 26 Mar 2018 04:33:26 +0000 Subject: [Development] qDebug() In-Reply-To: References: Message-ID: On which platform is it? Are you sure it's 5.11 only? See, for example, the solution proposed here: https://stackoverflow.com/questions/48474897/qt-qdebug-stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu [https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon at 2.png?v=73d79a89bded] QT qDebug() stopped to work (no more printing to console ... stackoverflow.com After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() macro stopped working and no longer displays the messages on the console. How can the debug output be re ... Best regards, Timur. ________________________________ From: Development on behalf of Igor Mironchik Sent: Monday, March 26, 2018 6:07:25 AM To: development at qt-project.org Subject: [Development] qDebug() Hello, Built sources from git repository (5.11 branch) doesn't print qDebug() messages to console. What I missed during the configuration process? Thank you. _______________________________________________ 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 igor.mironchik at gmail.com Mon Mar 26 06:36:42 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 07:36:42 +0300 Subject: [Development] qDebug() In-Reply-To: References: Message-ID: Hi, On 26.03.2018 07:33, Timur Pocheptsov wrote: > > On which platform is it? Are you sure it's 5.11 only? > I'm on Kubuntu 16.04. It is on 5.10 and 5.11 build from sources by myself. > > See, for example, the solution proposed here: > > > https://stackoverflow.com/questions/48474897/qt-qdebug-stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu > > > > QT qDebug() stopped to work (no more printing to console ... > > stackoverflow.com > After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() macro > stopped working and no longer displays the messages on the console. > How can the debug output be re ... > > Best regards, > >     Timur. > > ------------------------------------------------------------------------ > *From:* Development > on behalf > of Igor Mironchik > *Sent:* Monday, March 26, 2018 6:07:25 AM > *To:* development at qt-project.org > *Subject:* [Development] qDebug() > Hello, > > Built sources from git repository (5.11 branch) doesn't print qDebug() > messages to console. What I missed during the configuration process? > > Thank you. > > _______________________________________________ > 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 igor.mironchik at gmail.com Mon Mar 26 06:49:03 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 07:49:03 +0300 Subject: [Development] qDebug() In-Reply-To: References: Message-ID: What more interesting that in console applications qDebug() works... So I guess that this is not a problem of configuration process. And with Qt 5.9.4 installed with online installer qDebug() works in gui mode too. On 26.03.2018 07:33, Timur Pocheptsov wrote: > > On which platform is it? Are you sure it's 5.11 only? > > > See, for example, the solution proposed here: > > > https://stackoverflow.com/questions/48474897/qt-qdebug-stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu > > > > QT qDebug() stopped to work (no more printing to console ... > > stackoverflow.com > After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() macro > stopped working and no longer displays the messages on the console. > How can the debug output be re ... > > Best regards, > >     Timur. > > ------------------------------------------------------------------------ > *From:* Development > on behalf > of Igor Mironchik > *Sent:* Monday, March 26, 2018 6:07:25 AM > *To:* development at qt-project.org > *Subject:* [Development] qDebug() > Hello, > > Built sources from git repository (5.11 branch) doesn't print qDebug() > messages to console. What I missed during the configuration process? > > Thank you. > > _______________________________________________ > 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 akulichalexander at gmail.com Mon Mar 26 06:50:14 2018 From: akulichalexander at gmail.com (Alexander Akulich) Date: Mon, 26 Mar 2018 07:50:14 +0300 Subject: [Development] qDebug() In-Reply-To: References: Message-ID: Hello Igor, Does the linked solution help? See also comment #2 at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1731646 (referenced in the stackoverflow answer). (The subject question belongs to interest@, not development at . Please drop development at qt-project.org in further replies). On Mon, Mar 26, 2018 at 7:36 AM, Igor Mironchik wrote: > Hi, > > On 26.03.2018 07:33, Timur Pocheptsov wrote: > > On which platform is it? Are you sure it's 5.11 only? > > > I'm on Kubuntu 16.04. It is on 5.10 and 5.11 build from sources by myself. > > > See, for example, the solution proposed here: > > > https://stackoverflow.com/questions/48474897/qt-qdebug- > stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu > > > QT qDebug() stopped to work (no more printing to console ... > > stackoverflow.com > After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() macro stopped > working and no longer displays the messages on the console. How can the > debug output be re ... > Best regards, > > Timur. > ------------------------------ > *From:* Development pocheptsov=qt.io at qt-project.org> > on behalf of > Igor Mironchik > *Sent:* Monday, March 26, 2018 6:07:25 AM > *To:* development at qt-project.org > *Subject:* [Development] qDebug() > > Hello, > > Built sources from git repository (5.11 branch) doesn't print qDebug() > messages to console. What I missed during the configuration process? > > Thank you. > > _______________________________________________ > 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 aha_1980 at gmx.de Mon Mar 26 06:57:17 2018 From: aha_1980 at gmx.de (aha_1980 at gmx.de) Date: Mon, 26 Mar 2018 04:57:17 +0000 Subject: [Development] qDebug() In-Reply-To: References: Message-ID: Hi Igor, Which platform are you on? Also, please check the output of configure regarding the logger backend (stdout vs. syslog etc.) It *may* also be a QtCreator bug. I have heard about your problem quite some time recently, you might want to use google and co. Regards, Andre Am Montag, 26. März 2018 schrieb Igor Mironchik: > Hello, > > Built sources from git repository (5.11 branch) doesn't print qDebug() > messages to console. What I missed during the configuration process? > > Thank you. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Von meinem Jolla gesendet From igor.mironchik at gmail.com Mon Mar 26 07:02:28 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 08:02:28 +0300 Subject: [Development] qDebug() In-Reply-To: References: Message-ID: <67c2aa1a-fca4-f2e7-439d-450d8fea08c5@gmail.com> On 26.03.2018 07:50, Alexander Akulich wrote: > Hello Igor, > > Does the linked solution help? See also comment #2 at > https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1731646 > > (referenced in the stackoverflow answer). No, this solution didn't help. I guess that there is another reason. > > (The subject question belongs to interest@, not development at . Please > drop development at qt-project.org in > further replies). > > On Mon, Mar 26, 2018 at 7:36 AM, Igor Mironchik > > wrote: > > Hi, > > > On 26.03.2018 07:33, Timur Pocheptsov wrote: >> >> On which platform is it? Are you sure it's 5.11 only? >> > > I'm on Kubuntu 16.04. It is on 5.10 and 5.11 build from sources by > myself. > >> >> See, for example, the solution proposed here: >> >> >> https://stackoverflow.com/questions/48474897/qt-qdebug-stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu >> >> >> >> >> QT qDebug() stopped to work (no more printing to console ... >> >> stackoverflow.com >> After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() macro >> stopped working and no longer displays the messages on the >> console. How can the debug output be re ... >> >> Best regards, >> >>     Timur. >> >> ------------------------------------------------------------------------ >> *From:* Development >> >> >> on behalf of Igor Mironchik >> >> *Sent:* Monday, March 26, 2018 6:07:25 AM >> *To:* development at qt-project.org >> *Subject:* [Development] qDebug() >> Hello, >> >> Built sources from git repository (5.11 branch) doesn't print >> qDebug() >> messages to console. What I missed during the configuration process? >> >> Thank you. >> >> _______________________________________________ >> 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 timur.pocheptsov at qt.io Mon Mar 26 07:50:52 2018 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Mon, 26 Mar 2018 05:50:52 +0000 Subject: [Development] qDebug() In-Reply-To: <67c2aa1a-fca4-f2e7-439d-450d8fea08c5@gmail.com> References: , <67c2aa1a-fca4-f2e7-439d-450d8fea08c5@gmail.com> Message-ID: Have you tried creating an empty qtlogging.ini (as suggested on stackowerflow)? Best regards, Timur. ________________________________ From: Development on behalf of Igor Mironchik Sent: Monday, March 26, 2018 7:02:28 AM To: Alexander Akulich; interest at qt-project.org Cc: development at qt-project.org Subject: Re: [Development] qDebug() On 26.03.2018 07:50, Alexander Akulich wrote: Hello Igor, Does the linked solution help? See also comment #2 at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1731646 (referenced in the stackoverflow answer). No, this solution didn't help. I guess that there is another reason. (The subject question belongs to interest@, not development at . Please drop development at qt-project.org in further replies). On Mon, Mar 26, 2018 at 7:36 AM, Igor Mironchik > wrote: Hi, On 26.03.2018 07:33, Timur Pocheptsov wrote: On which platform is it? Are you sure it's 5.11 only? I'm on Kubuntu 16.04. It is on 5.10 and 5.11 build from sources by myself. See, for example, the solution proposed here: https://stackoverflow.com/questions/48474897/qt-qdebug-stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu [https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon at 2.png?v=73d79a89bded] QT qDebug() stopped to work (no more printing to console ... stackoverflow.com After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() macro stopped working and no longer displays the messages on the console. How can the debug output be re ... Best regards, Timur. ________________________________ From: Development on behalf of Igor Mironchik Sent: Monday, March 26, 2018 6:07:25 AM To: development at qt-project.org Subject: [Development] qDebug() Hello, Built sources from git repository (5.11 branch) doesn't print qDebug() messages to console. What I missed during the configuration process? Thank you. _______________________________________________ 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 igor.mironchik at gmail.com Mon Mar 26 07:52:02 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 08:52:02 +0300 Subject: [Development] qDebug() In-Reply-To: References: <67c2aa1a-fca4-f2e7-439d-450d8fea08c5@gmail.com> Message-ID: <06cb2833-efec-d65c-f005-9b638cca3da7@gmail.com> On 26.03.2018 08:50, Timur Pocheptsov wrote: > > Have you tried creating an empty qtlogging.ini (as suggested on > stackowerflow)? > Sure. > > Best regards, > >     Timur. > > ------------------------------------------------------------------------ > *From:* Development > on behalf > of Igor Mironchik > *Sent:* Monday, March 26, 2018 7:02:28 AM > *To:* Alexander Akulich; interest at qt-project.org > *Cc:* development at qt-project.org > *Subject:* Re: [Development] qDebug() > > > > On 26.03.2018 07:50, Alexander Akulich wrote: >> Hello Igor, >> >> Does the linked solution help? See also comment #2 at >> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1731646 >> >> (referenced in the stackoverflow answer). > > No, this solution didn't help. I guess that there is another reason. > >> >> (The subject question belongs to interest@, not development at . Please >> drop development at qt-project.org >> in further replies). >> >> On Mon, Mar 26, 2018 at 7:36 AM, Igor Mironchik >> > wrote: >> >> Hi, >> >> >> On 26.03.2018 07:33, Timur Pocheptsov wrote: >>> >>> On which platform is it? Are you sure it's 5.11 only? >>> >> >> I'm on Kubuntu 16.04. It is on 5.10 and 5.11 build from sources >> by myself. >> >>> >>> See, for example, the solution proposed here: >>> >>> >>> https://stackoverflow.com/questions/48474897/qt-qdebug-stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu >>> >>> >>> >>> >>> QT qDebug() stopped to work (no more printing to console ... >>> >>> stackoverflow.com >>> After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() >>> macro stopped working and no longer displays the messages on the >>> console. How can the debug output be re ... >>> >>> Best regards, >>> >>> Timur. >>> >>> ------------------------------------------------------------------------ >>> *From:* Development >>> >>> >>> on behalf of Igor Mironchik >>> >>> *Sent:* Monday, March 26, 2018 6:07:25 AM >>> *To:* development at qt-project.org >>> *Subject:* [Development] qDebug() >>> Hello, >>> >>> Built sources from git repository (5.11 branch) doesn't print >>> qDebug() >>> messages to console. What I missed during the configuration process? >>> >>> Thank you. >>> >>> _______________________________________________ >>> 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 igor.mironchik at gmail.com Mon Mar 26 07:57:44 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 08:57:44 +0300 Subject: [Development] qDebug() In-Reply-To: References: <67c2aa1a-fca4-f2e7-439d-450d8fea08c5@gmail.com> Message-ID: <8fd2537d-039d-0374-98c3-42a21f7c4470@gmail.com> Simple: #include #include #include #include #include class Obj     :    public QWidget {     Q_OBJECT public:     Obj()     {}     ~Obj()     {} public slots:     void start()     {         show();         QTextStream st( stdout );         st << "QTextStream works...";         qDebug() << "Started and stopped.";     } }; int main( int argc, char ** argv ) {     QApplication app( argc, argv );     Obj o;     QTimer::singleShot( 0, &o, &Obj::start );     return app.exec(); } #include "main.moc" Produces: Starting /home/igor/Tmp/build-debug-Qt_5_10_0_qt5-Debug/debug... QTextStream works... /home/igor/Tmp/build-debug-Qt_5_10_0_qt5-Debug/debug exited with code 0 But it's so only with Qt built from sources (5.11 branch)... On 26.03.2018 08:50, Timur Pocheptsov wrote: > > Have you tried creating an empty qtlogging.ini (as suggested on > stackowerflow)? > > Best regards, > >     Timur. > > ------------------------------------------------------------------------ > *From:* Development > on behalf > of Igor Mironchik > *Sent:* Monday, March 26, 2018 7:02:28 AM > *To:* Alexander Akulich; interest at qt-project.org > *Cc:* development at qt-project.org > *Subject:* Re: [Development] qDebug() > > > On 26.03.2018 07:50, Alexander Akulich wrote: >> Hello Igor, >> >> Does the linked solution help? See also comment #2 at >> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1731646 >> >> (referenced in the stackoverflow answer). > > No, this solution didn't help. I guess that there is another reason. > >> >> (The subject question belongs to interest@, not development at . Please >> drop development at qt-project.org >> in further replies). >> >> On Mon, Mar 26, 2018 at 7:36 AM, Igor Mironchik >> > wrote: >> >> Hi, >> >> >> On 26.03.2018 07:33, Timur Pocheptsov wrote: >>> >>> On which platform is it? Are you sure it's 5.11 only? >>> >> >> I'm on Kubuntu 16.04. It is on 5.10 and 5.11 build from sources >> by myself. >> >>> See, for example, the solution proposed here: >>> >>> https://stackoverflow.com/questions/48474897/qt-qdebug-stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu >>> >>> >>> >>> >>> QT qDebug() stopped to work (no more printing to console ... >>> >>> stackoverflow.com >>> After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() >>> macro stopped working and no longer displays the messages on the >>> console. How can the debug output be re ... >>> >>> Best regards, >>> >>>     Timur. >>> >>> ------------------------------------------------------------------------ >>> *From:* Development >>> >>> >>> on behalf of Igor Mironchik >>> >>> *Sent:* Monday, March 26, 2018 6:07:25 AM >>> *To:* development at qt-project.org >>> *Subject:* [Development] qDebug() >>> Hello, >>> >>> Built sources from git repository (5.11 branch) doesn't print >>> qDebug() >>> messages to console. What I missed during the configuration process? >>> >>> Thank you. >>> >>> _______________________________________________ >>> 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 mitch.curtis at qt.io Mon Mar 26 08:15:44 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 26 Mar 2018 06:15:44 +0000 Subject: [Development] qDebug() In-Reply-To: References: Message-ID: <65AEFE6A-5BB0-47E1-AF94-12F2C700B193@qt.io> You might be running into https://bugreports.qt.io/browse/QTBUG-66153 Try setting QT_LOGGING_TO_CONSOLE=1 On 3/26/18, 6:08 AM, "Development on behalf of Igor Mironchik" wrote: Hello, Built sources from git repository (5.11 branch) doesn't print qDebug() messages to console. What I missed during the configuration process? Thank you. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From igor.mironchik at gmail.com Mon Mar 26 08:18:39 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 09:18:39 +0300 Subject: [Development] qDebug() In-Reply-To: <65AEFE6A-5BB0-47E1-AF94-12F2C700B193@qt.io> References: <65AEFE6A-5BB0-47E1-AF94-12F2C700B193@qt.io> Message-ID: Yes, it helped, thanks. On 26.03.2018 09:15, Mitch Curtis wrote: > You might be running into https://bugreports.qt.io/browse/QTBUG-66153 > > Try setting QT_LOGGING_TO_CONSOLE=1 > > On 3/26/18, 6:08 AM, "Development on behalf of Igor Mironchik" wrote: > > Hello, > > Built sources from git repository (5.11 branch) doesn't print qDebug() > messages to console. What I missed during the configuration process? > > Thank you. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > From Tor.arne.Vestbo at qt.io Mon Mar 26 13:22:56 2018 From: Tor.arne.Vestbo at qt.io (=?iso-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Mon, 26 Mar 2018 11:22:56 +0000 Subject: [Development] qDebug() In-Reply-To: <65AEFE6A-5BB0-47E1-AF94-12F2C700B193@qt.io> References: <65AEFE6A-5BB0-47E1-AF94-12F2C700B193@qt.io> Message-ID: https://bugreports.qt.io/browse/QTBUG-66153 was fixed in 5.11-alpha1. Which sha1 of qtbase are you building? Tor Arne > On 26 Mar 2018, at 08:15, Mitch Curtis wrote: > > You might be running into https://bugreports.qt.io/browse/QTBUG-66153 > > Try setting QT_LOGGING_TO_CONSOLE=1 > > On 3/26/18, 6:08 AM, "Development on behalf of Igor Mironchik" wrote: > > Hello, > > Built sources from git repository (5.11 branch) doesn't print qDebug() > messages to console. What I missed during the configuration process? > > Thank you. > > _______________________________________________ > 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 igor.mironchik at gmail.com Mon Mar 26 13:31:15 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 26 Mar 2018 14:31:15 +0300 Subject: [Development] qDebug() In-Reply-To: References: <65AEFE6A-5BB0-47E1-AF94-12F2C700B193@qt.io> Message-ID: On 26.03.2018 14:22, Tor Arne Vestbø wrote: > https://bugreports.qt.io/browse/QTBUG-66153 was fixed in 5.11-alpha1. > > Which sha1 of qtbase are you building? 4ca0d764546908dd31fc3794ddcead5582436097 > > Tor Arne > >> On 26 Mar 2018, at 08:15, Mitch Curtis wrote: >> >> You might be running into https://bugreports.qt.io/browse/QTBUG-66153 >> >> Try setting QT_LOGGING_TO_CONSOLE=1 >> >> On 3/26/18, 6:08 AM, "Development on behalf of Igor Mironchik" wrote: >> >> Hello, >> >> Built sources from git repository (5.11 branch) doesn't print qDebug() >> messages to console. What I missed during the configuration process? >> >> Thank you. >> >> _______________________________________________ >> 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 Tor.arne.Vestbo at qt.io Mon Mar 26 13:43:38 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Mon, 26 Mar 2018 11:43:38 +0000 Subject: [Development] qDebug() In-Reply-To: References: <65AEFE6A-5BB0-47E1-AF94-12F2C700B193@qt.io> Message-ID: <617138EB-8715-41AD-BF02-D6D8FCBB5806@qt.io> > On 26 Mar 2018, at 13:31, Igor Mironchik wrote: > > > > On 26.03.2018 14:22, Tor Arne Vestbø wrote: >> https://bugreports.qt.io/browse/QTBUG-66153 was fixed in 5.11-alpha1. >> >> Which sha1 of qtbase are you building? > > 4ca0d764546908dd31fc3794ddcead5582436097 That’s not the HEAD of the 5.11 branch, that’s from Jan 23, and the fix for QTBUG-66153 landed Feb 2. Do a git pull. Tor Arne > >> >> Tor Arne >> >>> On 26 Mar 2018, at 08:15, Mitch Curtis wrote: >>> >>> You might be running into https://bugreports.qt.io/browse/QTBUG-66153 >>> >>> Try setting QT_LOGGING_TO_CONSOLE=1 >>> >>> On 3/26/18, 6:08 AM, "Development on behalf of Igor Mironchik" wrote: >>> >>> Hello, >>> >>> Built sources from git repository (5.11 branch) doesn't print qDebug() >>> messages to console. What I missed during the configuration process? >>> >>> Thank you. >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development > From Simon.Hausmann at qt.io Mon Mar 26 15:12:16 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 26 Mar 2018 13:12:16 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: References: <7768537419eb3a899b639c7172d353cd@kdab.com> <4052230.IsPnHTtaVS@frederik-thinkcentre-m93p>, Message-ID: +1 for sure. Simon ________________________________ From: Development on behalf of Andy Shaw Sent: Wednesday, March 21, 2018 5:02:35 PM To: development at qt-project.org Subject: Re: [Development] Proposing Albert Astals Cid for Approver A +1 from me too, his help with the printing side has been really valuable! Andy Development på vegne av Frederik Gladhorn skrev følgende den 21.03.2018, 16.27: A big +1 from me as well :) Cheers, Frederik On onsdag 21. mars 2018 12.33.06 CET Sérgio Martins wrote: > Hi, > > > Albert has been a long time contributor to KDE and Qt and very well > known in the community. > > His dashboards speak for himself, with many bugs fixed: > (For some reason pasting-and-opening URLs from gerrit is broken, so > you'll have to search yourself) > > > at KDAB: > owner:"Albert Astals Cid " > > > at Canonical: > owner:albert.astals at canonical.com > > > on his free-time with KDE hat: > owner:"Albert Astals Cid " > > > > And recently he was tricked into fixing many printing and CUPS bugs, so > thanks Albert! > > > Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives > somewhat near me, in the Iberian peninsula. > > > > Regards, _______________________________________________ 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 aapo.keskimolo at qt.io Mon Mar 26 18:07:01 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Mon, 26 Mar 2018 16:07:01 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin production will be updated tomorrow Tue Mar 27 12:00 EEST 2018 See the log attached for details about the new features and bug fixes. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20180326.log Type: application/octet-stream Size: 40403 bytes Desc: product_baseline_20180326.log URL: From jani.heikkinen at qt.io Tue Mar 27 08:01:03 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 27 Mar 2018 06:01:03 +0000 Subject: [Development] HEADS UP : Qt 5.11 string freeze In-Reply-To: References: Message-ID: Hi, As informed a week ago string freeze for Qt 5.11 is now in effect. So please, no changes to translatable strings from this point, unless approved by the documentation team. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, March 19, 2018 7:42 AM To: localization at qt-project.org Cc: development at qt-project.org; releasing at qt-project.org Subject: [Development] HEADS UP : Qt 5.11 soft string freeze Hi all, First beta releases from Qt 5.11 are already out so it is time to start keeping translatable strings as it is. Let's have official string freeze Mon 26th March 2018. br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Mar 27 08:06:32 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 27 Mar 2018 06:06:32 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: , Message-ID: Hi! Please do not update production before fix for https://bugreports.qt.io/browse/QTQAINFRA-1887 is in (at least https://codereview.qt-project.org/#/c/224379/). Otherwise export tool will be broken & all releases, snapshots etc blocked... br, Jani ________________________________________ From: Development on behalf of Aapo Keskimölö Sent: Monday, March 26, 2018 7:07 PM To: development at qt-project.org Subject: [Development] Coin maintenance notification Coin production will be updated tomorrow Tue Mar 27 12:00 EEST 2018 See the log attached for details about the new features and bug fixes. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From ville.voutilainen at gmail.com Tue Mar 27 10:53:08 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 27 Mar 2018 11:53:08 +0300 Subject: [Development] Maintainer action requested on tests Message-ID: As many of you know, we've been operating a task force to reduce autotest flakiness and improve the stability of COIN and related CI infra. This has resulted in fair amounts of newly-blacklisted tests. What we need maintainers of various modules to do is as follows: 1) look at the blacklisted tests and see whether anything could be done to un-blacklist them, aka fix the root cause 2) improve tests in general to reduce remaining flakiness. Grafana is your friend to see which tests are flaky: https://testresults.qt.io/grafana/d/000000012/overview?orgId=1 Please be careful about un-blacklisting; if you have trouble reproducing flaky results or test failures, avoid the urge to blacklist just because something works on your machine; that doesn't help if the tests don't work in COIN. Talk to Sami Nurmenniemi, Kari Oikarinen or me if you need help with reproduction recipes etc. Thanks in advance, -me From aapo.keskimolo at qt.io Tue Mar 27 11:26:19 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Tue, 27 Mar 2018 09:26:19 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: , Message-ID: I have updated production with the release export tool fix and reversal of the potential mac breakages. See attach text file for the cherry-picks. -----Original Message----- From: Jani Heikkinen Sent: Tuesday, March 27, 2018 8:07 AM To: Aapo Keskimölö ; development at qt-project.org Subject: Re: Coin maintenance notification Hi! Please do not update production before fix for https://bugreports.qt.io/browse/QTQAINFRA-1887 is in (at least https://codereview.qt-project.org/#/c/224379/). Otherwise export tool will be broken & all releases, snapshots etc blocked... br, Jani ________________________________________ From: Development on behalf of Aapo Keskimölö Sent: Monday, March 26, 2018 7:07 PM To: development at qt-project.org Subject: [Development] Coin maintenance notification Coin production will be updated tomorrow Tue Mar 27 12:00 EEST 2018 See the log attached for details about the new features and bug fixes. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cherry_picks_20180327.txt URL: From aapo.keskimolo at qt.io Tue Mar 27 12:21:47 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Tue, 27 Mar 2018 10:21:47 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: , Message-ID: The production baseline was found broken and therefore I reverted the baseline with only one cherry-pick that is recommended by https://bugreports.qt.io/browse/QTQAINFRA-1889 -----Original Message----- From: Aapo Keskimölö Sent: Tuesday, March 27, 2018 11:26 AM To: Jani Heikkinen ; development at qt-project.org Subject: RE: Coin maintenance notification I have updated production with the release export tool fix and reversal of the potential mac breakages. See attach text file for the cherry-picks. -----Original Message----- From: Jani Heikkinen Sent: Tuesday, March 27, 2018 8:07 AM To: Aapo Keskimölö ; development at qt-project.org Subject: Re: Coin maintenance notification Hi! Please do not update production before fix for https://bugreports.qt.io/browse/QTQAINFRA-1887 is in (at least https://codereview.qt-project.org/#/c/224379/). Otherwise export tool will be broken & all releases, snapshots etc blocked... br, Jani ________________________________________ From: Development on behalf of Aapo Keskimölö Sent: Monday, March 26, 2018 7:07 PM To: development at qt-project.org Subject: [Development] Coin maintenance notification Coin production will be updated tomorrow Tue Mar 27 12:00 EEST 2018 See the log attached for details about the new features and bug fixes. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From jani.heikkinen at qt.io Tue Mar 27 12:28:40 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 27 Mar 2018 10:28:40 +0000 Subject: [Development] Maintainers, your actions needed: Qt 5.9.5 changes files In-Reply-To: References: , Message-ID: Qtbase still waiting for +2, see https://codereview.qt-project.org/#/c/223464/ br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, March 20, 2018 1:17 PM To: development at qt-project.org Subject: Re: [Development] Maintainers, your actions needed: Qt 5.9.5 changes files Still some changes files under work. Please finalize remaining ones now br, jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, March 16, 2018 3:21 PM To: development at qt-project.org Subject: [Development] Maintainers, your actions needed: Qt 5.9.5 changes files Hi all, Initial ones done. Please do needed modifications & get approval as soon as possible. Files here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.9.5%22,n,z br, Jani Heikkinen Release Manager _______________________________________________ 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 announce at qt-project.org Wed Mar 28 11:36:37 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 28 Mar 2018 09:36:37 +0000 Subject: [Development] [Announce] Qt Creator 4.6.0 released Message-ID: We are happy to announce the release of Qt Creator 4.6.0! http://blog.qt.io/blog/2018/03/28/qt-creator-4-6-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 aapo.keskimolo at qt.io Thu Mar 29 16:56:12 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Thu, 29 Mar 2018 14:56:12 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: , Message-ID: Coin service has suffered from some down time today after failed production update. We are currently working on bringing the service back up. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From aapo.keskimolo at qt.io Thu Mar 29 17:48:11 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Thu, 29 Mar 2018 15:48:11 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: , Message-ID: Coin service is running again. -----Original Message----- From: Aapo Keskimölö Sent: Thursday, March 29, 2018 4:56 PM To: 'development at qt-project.org' Subject: Coin maintenance notification Coin service has suffered from some down time today after failed production update. We are currently working on bringing the service back up. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From jhihn at gmx.com Thu Mar 29 19:00:45 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 29 Mar 2018 19:00:45 +0200 Subject: [Development] Fw: [Interest] ComboBox styling problems References: Message-ID: I've posted this to interest twice now, but never got a response. Could I solicit some help from the devs? > I'm trying to style ComboBox, but I am getting a highlight (pink) that is not placed correctly, and there seems to be a semi-transparent black overlay that is also applying itself over the highlight? (it's a darker shade of pink) > > Can someone tell me what I'm doing wrong? -------------- next part -------------- A non-text attachment was scrubbed... Name: main.qml Type: application/octet-stream Size: 1726 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: model.js Type: text/javascript Size: 377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-02-18 at 12.12.33 AM.png Type: image/png Size: 9404 bytes Desc: not available URL: