From alexander.blasche at qt.io Wed Nov 1 08:06:20 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 1 Nov 2017 07:06:20 +0000 Subject: [Development] Nominating Andras Mantia for approver In-Reply-To: <20171010120146.GA15536@polaris.localdomain> References: <20171010120146.GA15536@polaris.localdomain> Message-ID: Congratulations. Access rights have been updated. -- Alex ________________________________________ From: Development on behalf of Rafael Roquetto Sent: Tuesday, 10 October 2017 2:01:47 PM To: Qt Project Development Mailing-List Subject: [Development] Nominating Andras Mantia for approver Howdy, I would like to nominate Andras Mantia, a fellow colleague at KDAB, for approver status. Andras has been a key contributor in the develpment of the recently unveiled Qt3DStudio. His continuous involvement with the project and deep understanding of the code makes his nomination very pertinent. For those who have access, you can check out his contributions here: https://codereview.qt-project.org/#/q/owner:"Andras+Mantia"+status:merged,n,z Thanks, Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From alexander.blasche at qt.io Wed Nov 1 08:08:24 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 1 Nov 2017 07:08:24 +0000 Subject: [Development] =?windows-1252?q?Nominating_Tomi_Korpip=E4=E4_for_?= =?windows-1252?q?approver?= In-Reply-To: References: , Message-ID: Congratulations. Access rights have been updated. -- Alex ________________________________________ From: Development on behalf of Antti Määttä Sent: Wednesday, 11 October 2017 10:21:45 AM To: Miikka Heikkinen; Pasi Keränen; development at qt-project.org Subject: Re: [Development] Nominating Tomi Korpipää for approver +1 -Antti From: Development [mailto:development-bounces+antti.maatta=qt.io at qt-project.org] On Behalf Of Miikka Heikkinen Sent: keskiviikko 11. lokakuuta 2017 10.03 To: Pasi Keränen ; development at qt-project.org Subject: Re: [Development] Nominating Tomi Korpipää for approver +1 from me. -Miikka From: Development [mailto:development-bounces+miikka.heikkinen=qt.io at qt-project.org] On Behalf Of Pasi Keränen Sent: 11. lokakuuta 2017 7:13 To: development at qt-project.org Subject: [Development] Nominating Tomi Korpipää for approver Hi, I’d like to nominate Tomi Korpipää from my team here at The Qt Company for approver status. Tomi has been key contributor in Qt Charts, Qt DataVizualisation, Qt3D Editor and in the recently unveiled Qt 3D Studio. I think this nomination is long overdue as Tomi has been one of the carrying forces in those components. Those with access, you can see his contributions here: https://codereview.qt-project.org/#/q/owner:"Tomi Korpipää"+status:merged,n,z Regards, Pasi Keränen From jedrzej.nowacki at qt.io Wed Nov 1 08:50:06 2017 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 01 Nov 2017 08:50:06 +0100 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: References: Message-ID: <1923972.F2YcVzzU1F@43> On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote: > Hi all, > > we've had a bunch of unfortunate small things piling up, so sadly Coin is > down right now. I expect it to be up tomorrow (so in roughly 10 hours from > now) assuming everything now goes smooth. > Small update. Now everything is going back to a working state. Durring the process we droppped provisioned images and these are being re-created now. Self healing process can take 1-3h, everything is populated in parallel and heavily depends on network, so the ETA is hard to estimate. NOTE: Some integrations may break in provisioning step, in that case feel free to restage. Cheers, Jędrek From andras.mantia at kdab.com Wed Nov 1 09:37:17 2017 From: andras.mantia at kdab.com (Andras Mantia) Date: Wed, 01 Nov 2017 10:37:17 +0200 Subject: [Development] Nominating Andras Mantia for approver In-Reply-To: References: <20171010120146.GA15536@polaris.localdomain> Message-ID: <2008049.7UnElZxEU4@stein.andtib> On Wednesday, November 1, 2017 9:06:20 AM EET Alex Blasche wrote: > Congratulations. Access rights have been updated. Thank you! Andras -- András Mantia | andras.mantia at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From jedrzej.nowacki at qt.io Wed Nov 1 10:16:53 2017 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 01 Nov 2017 10:16:53 +0100 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: <1923972.F2YcVzzU1F@43> References: <1923972.F2YcVzzU1F@43> Message-ID: <754774669.GT6YySCDiA@43> On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote: > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote: > > Hi all, > > > > we've had a bunch of unfortunate small things piling up, so sadly Coin is > > down right now. I expect it to be up tomorrow (so in roughly 10 hours from > > now) assuming everything now goes smooth. > > Small update. Now everything is going back to a working state. Durring the > process we droppped provisioned images and these are being re-created now. > Self healing process can take 1-3h, everything is populated in parallel and > heavily depends on network, so the ETA is hard to estimate. > > NOTE: > Some integrations may break in provisioning step, in that case feel free to > restage. RHEL 7.2 fails to provision as we have a subscription issue. That effectively blocks 5.10 branch in all modules. We will probably just update the RHEL to 7.4 as it is needed anyway. More details can give Liang and Heikki. Ossi, Frederik: could you disable staging button for 5.10 branch? Cheers, Jędrek From Richard.Gustavsen at qt.io Wed Nov 1 10:45:35 2017 From: Richard.Gustavsen at qt.io (Richard Gustavsen) Date: Wed, 1 Nov 2017 09:45:35 +0000 Subject: [Development] Repository request: MaterialWidgets In-Reply-To: <803961509373282@web41j.yandex.ru> References: <3DEEA0C4-DD06-4D44-BBEC-8B65CC537287@qt.io> <20171030115625.GA12392@troll08> <697CEDD9-341C-40BD-9759-10C72F32724B@qt.io> <20171030133308.GA23975@troll08> , <803961509373282@web41j.yandex.ru> Message-ID: 30.10.2017, 17:18, "iman ahmadvand" : > Well. > If it's OK to add new classes then we can create our classes And do the style related things in private part until Qt6 release, on that time we can move our changes to QStyle API. Adding new and missing controls into QtWidgets, like QSwitch, is very welcome. I would prefer adding new widgets rather than changing the API of the existing ones (with ifdefs etc), unless you only need to _add_ some functions. If two widgets are conceptually different (e.g a QSwitch is not really a QCheckBox, or a "discrete slider" is not really a QSlider), they probably deserve to be separate widgets. But, those widgets need to conform to the current styling API. You cannot undermine that, and just hard-code the style in the private parts of the new widgets (even if QStyle wasn't really written with animations and transitions in mind). But, like already mentioned earlier in the thread, you can (and will have to) add new enums to QStyle that backs the new widgets, and provide a default style implementation for them (in e.g QCommonStyle) that will be picked up as last resort on all platforms. If you think that your new widget set /style cannot conform to this, then it should probably be shipped outside Qt5. -Richard ________________________________ Fra: Development på vegne av Konstantin Tokarev Sendt: 30. oktober 2017 15:21:22 Til: iman ahmadvand; Qt development mailing list Emne: Re: [Development] Repository request: MaterialWidgets 30.10.2017, 17:18, "iman ahmadvand" : > Well. > If it's OK to add new classes then we can create our classes And do the style related things in private part until Qt6 release, on that time we can move our changes to QStyle API. > And also in this way the application setting will go away. > in result: > 1.We have our new widgets > 2.We have overcame qstyle api changes > > On Mon, Oct 30, 2017 at 5:03 PM, Oswald Buddenhagen wrote: >> On Mon, Oct 30, 2017 at 04:34:25PM +0330, iman ahmadvand wrote: >>> I was thinking of something like this to achieve: >>> QApplication::setStyle("material"); >>> >>> Which bring completely new styled and animated appearance. >>> That would be nice AND Qt way though. >>> But we've some new widgets beside the existing widgets, for >>> example: [...] >>> >>> Which requires changes in QStyle enumerators. >>> The two build step was a good option but what about these new widgets ? >>> unfortunately it seems there is no way to porting this to Qt. >>> >> adding entirely new widgets (classes) can be done any time. > > But How? if it's not going to be a module ? Just add new widgets to QtWidgets module. > >> the only challenge is that they may need new qstyle primitives, which >> may then need custom implementations in the other styles as well. but i >> guess "this widget doesn't look well unless you use the material style" >> might be an acceptable policy. >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at qt.io Wed Nov 1 11:19:51 2017 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 01 Nov 2017 11:19:51 +0100 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: <754774669.GT6YySCDiA@43> References: <1923972.F2YcVzzU1F@43> <754774669.GT6YySCDiA@43> Message-ID: <3496979.lGfoDNtG9L@43> On Wednesday, November 1, 2017 10:16:53 AM CET Jedrzej Nowacki wrote: > On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote: > > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote: > > > Hi all, > > > > > > we've had a bunch of unfortunate small things piling up, so sadly Coin > > > is > > > down right now. I expect it to be up tomorrow (so in roughly 10 hours > > > from > > > now) assuming everything now goes smooth. > > > > Small update. Now everything is going back to a working state. Durring the > > process we droppped provisioned images and these are being re-created now. > > Self healing process can take 1-3h, everything is populated in parallel > > and > > heavily depends on network, so the ETA is hard to estimate. > > > > NOTE: > > Some integrations may break in provisioning step, in that case feel free > > to > > restage. > > RHEL 7.2 fails to provision as we have a subscription issue. That > effectively blocks 5.10 branch in all modules. We will probably just update > the RHEL to 7.4 as it is needed anyway. More details can give Liang and > Heikki. And now we are experiencing unexpected, extremely slow IO on the OpenNebula host. Our IT is working on it, but I'm afraid that nothing will pass until it is fixed, we run at ~5% of standard computation power. Cheers, Jędrek From jani.heikkinen at qt.io Wed Nov 1 11:59:42 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 1 Nov 2017 10:59:42 +0000 Subject: [Development] Qt 5.10 beta 3 released Message-ID: Hi all, Qt 5.10 beta3 is out. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. So please test the packages and make sure all issues which must be fixed before final Qt 5.10.0 release are visible in rc blocker list (https://bugreports.qt.io/issues/?filter=18957#) Diff to beta2 can be found as an attachment. br, Jani Heikkinen Release Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.10-beta2-delta-beta3-commits Type: application/octet-stream Size: 22136 bytes Desc: qt5.10-beta2-delta-beta3-commits URL: From announce at qt-project.org Wed Nov 1 12:00:05 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 1 Nov 2017 11:00:05 +0000 Subject: [Development] [Announce] Qt 5.10 beta3 released Message-ID: Hi all, Qt 5.10 beta3 is available. You can update it at the top of your Qt 5.10 beta(2) online installation or do clean installation by using qt online installer. Detailed instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From abbapoh at gmail.com Wed Nov 1 13:23:04 2017 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Wed, 1 Nov 2017 15:23:04 +0300 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> Message-ID: Sorry for digging the thread, but how is * use qssize_t and ** Wrapping std::{unordered_}map may be acceptable combines? std::*map uses size_t in it's API (size, max_size, count, reserve, begin(size_type), end(size_type)) And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philwave at gmail.com Wed Nov 1 13:30:12 2017 From: philwave at gmail.com (Philippe) Date: Wed, 01 Nov 2017 13:30:12 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: Message-ID: <20171101133011.AC94.6F0322A@gmail.com> And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString? Something sure, a Qt6 feature such as std::pmr::memory_resource (cf. https://www.youtube.com/watch?v=v3dz-AKOVL8) would be more than welcome for Qt containers and strings. Philippe On Wed, 1 Nov 2017 15:23:04 +0300 ???? ?????????? wrote: Sorry for digging the thread, but how is > * use qssize_t > and > ** Wrapping std::{unordered_}map may be acceptable > combines? > > std::*map uses size_t in it's API (size, max_size, count, reserve, begin(size_type), end(size_type)) > > > And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Nov 1 13:32:23 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 01 Nov 2017 15:32:23 +0300 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <20171101133011.AC94.6F0322A@gmail.com> References: <20171101133011.AC94.6F0322A@gmail.com> Message-ID: <52611509539543@web10g.yandex.ru> 01.11.2017, 15:30, "Philippe" : > And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString? > > Something sure, a Qt6 feature such as std::pmr::memory_resource (cf. https://www.youtube.com/watch?v=v3dz-AKOVL8) would be more than welcome for Qt containers and strings. Using virtual functions for allocation/deallocation doesn't seem like a bright idea > > Philippe > > On Wed, 1 Nov 2017 15:23:04 +0300 > ???? ?????????? wrote: > >> Sorry for digging the thread, but how is >> *  use qssize_t >> and >> ** Wrapping std::{unordered_}map may be acceptable >>  combines? >> std::*map uses size_t in it's API (size, max_size, count, reserve, begin(size_type), end(size_type)) >> >> And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString? > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From philwave at gmail.com Wed Nov 1 13:48:27 2017 From: philwave at gmail.com (Philippe) Date: Wed, 01 Nov 2017 13:48:27 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <52611509539543@web10g.yandex.ru> References: <20171101133011.AC94.6F0322A@gmail.com> <52611509539543@web10g.yandex.ru> Message-ID: <20171101134826.EDF9.6F0322A@gmail.com> > Using virtual functions for allocation/deallocation doesn't seem like a bright idea If you speak about performances, then you are wrong. The impact is neglictable compared to the rest of the allocations. This has been proved by the guys that pushed that C++17 feature, with extensive benchmarks. You can find a very complete study here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0089r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0213r0.pdf And if you like some videos on the topic, here the latest one from John Lakos: https://www.youtube.com/watch?v=nZNd5FjSquk https://www.youtube.com/watch?v=CFzuFNSpycI&t=8s Personnaly (and with a long experience with custom memory allocation), I am convinced about this new C+++17 approach. Philippe On Wed, 01 Nov 2017 15:32:23 +0300 Konstantin Tokarev wrote: > > > 01.11.2017, 15:30, "Philippe" : > > And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString? > > > > Something sure, a Qt6 feature such as std::pmr::memory_resource (cf. https://www.youtube.com/watch?v=v3dz-AKOVL8) would be more than welcome for Qt containers and strings. > > Using virtual functions for allocation/deallocation doesn't seem like a bright idea > > > > > Philippe > > > > On Wed, 1 Nov 2017 15:23:04 +0300 > > ???? ?????????? wrote: > > > >> Sorry for digging the thread, but how is > >> *  use qssize_t > >> and > >> ** Wrapping std::{unordered_}map may be acceptable > >>  combines? > >> std::*map uses size_t in it's API (size, max_size, count, reserve, begin(size_type), end(size_type)) > >> > >> And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString? > > > > , > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > --  > Regards, > Konstantin From jani.heikkinen at qt.io Wed Nov 1 14:09:46 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 1 Nov 2017 13:09:46 +0000 Subject: [Development] HEADS-UP: Branching '5.9.3' started Message-ID: Hi all, We have soft branched '5.9.3' from '5.9'. So please start using '5.9.3' for new changes targeted to Qt 5.9.3 release. Final downmerge from '5.9' to '5.9.3' will happen Wed 8th November so there should be enough time to finalize ongoing changes in '5.9' and start using '5.9.3' for new ones. We are targeting to release Qt 5.9.3 as soon as possible so please make sure all blockers are fixed immediately. Qt 5.9.3 blocker list here: https://bugreports.qt.io/issues/?filter=18995 We (release team) will start creating initial change files for Qt 5.9.3 now. So Maintainers: Please finalize those initial ones immediately when available. We need those now really soon to be able to proceed with final release. br, Jani Heikkinen Release Manager From Jedrzej.Nowacki at qt.io Wed Nov 1 15:59:22 2017 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 1 Nov 2017 14:59:22 +0000 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: <3496979.lGfoDNtG9L@43> References: <1923972.F2YcVzzU1F@43> <754774669.GT6YySCDiA@43>, <3496979.lGfoDNtG9L@43> Message-ID: Hi, Yet another update. We narrowed down the IO issue. The network update from 1G to 10G, mentioned before, brought compellent into the picture and that one didn't want to cooperate nicely with our btrfs installation, for an unknown reason. The link will be downgraded and we would go back to a SSD storage as soon as possible (currently there are some disk operations that can not be interrupted). Regarding 5.10 branch, it is still locked, but I guess it is not a surprise. https://codereview.qt-project.org/#/c/209970/ needs to be get integrated, but in the current hostile conditions it is not easy. Cheers, Jędrek ________________________________________ From: Development on behalf of Jedrzej Nowacki Sent: Wednesday, November 1, 2017 11:19 AM To: development at qt-project.org Subject: Re: [Development] Continuous Integration issues - Coin temporarily down On Wednesday, November 1, 2017 10:16:53 AM CET Jedrzej Nowacki wrote: > On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote: > > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote: > > > Hi all, > > > > > > we've had a bunch of unfortunate small things piling up, so sadly Coin > > > is > > > down right now. I expect it to be up tomorrow (so in roughly 10 hours > > > from > > > now) assuming everything now goes smooth. > > > > Small update. Now everything is going back to a working state. Durring the > > process we droppped provisioned images and these are being re-created now. > > Self healing process can take 1-3h, everything is populated in parallel > > and > > heavily depends on network, so the ETA is hard to estimate. > > > > NOTE: > > Some integrations may break in provisioning step, in that case feel free > > to > > restage. > > RHEL 7.2 fails to provision as we have a subscription issue. That > effectively blocks 5.10 branch in all modules. We will probably just update > the RHEL to 7.4 as it is needed anyway. More details can give Liang and > Heikki. And now we are experiencing unexpected, extremely slow IO on the OpenNebula host. Our IT is working on it, but I'm afraid that nothing will pass until it is fixed, we run at ~5% of standard computation power. Cheers, Jędrek _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Nov 1 16:21:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Nov 2017 08:21:10 -0700 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> Message-ID: <7439044.tNS2a1raN0@tjmaciei-mobl1> On quarta-feira, 1 de novembro de 2017 05:23:04 PDT Иван Комиссаров wrote: > Sorry for digging the thread, but how is > * use qssize_t > and > ** Wrapping std::{unordered_}map may be acceptable > combines? > std::*map uses size_t in it's API (size, max_size, count, reserve, > begin(size_type), end(size_type)) Our wrapper API can still use qssize_t. "Won't that limit the actual maximum size?" No, not really, since it's already limited to half the full VM space. No object can be larger than that. Using unsigned is unnecessary. > And offtop - what about allocators? They would be accesibble for wrappers, > but not accesible for QVector/QString? They wouldn't be accessible for wrappers either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Nov 1 16:25:01 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 01 Nov 2017 18:25:01 +0300 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <7439044.tNS2a1raN0@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <7439044.tNS2a1raN0@tjmaciei-mobl1> Message-ID: <301551509549901@web8j.yandex.ru> 01.11.2017, 18:21, "Thiago Macieira" : > On quarta-feira, 1 de novembro de 2017 05:23:04 PDT Иван Комиссаров wrote: >>  Sorry for digging the thread, but how is >>  * use qssize_t >>  and >>  ** Wrapping std::{unordered_}map may be acceptable >>   combines? >>  std::*map uses size_t in it's API (size, max_size, count, reserve, >>  begin(size_type), end(size_type)) > > Our wrapper API can still use qssize_t. > > "Won't that limit the actual maximum size?" > > No, not really, since it's already limited to half the full VM space. No > object can be larger than that. Using unsigned is unnecessary. Using unsigned for size types is crucial in preventing signed overflow in pathological cases. > >>  And offtop - what about allocators? They would be accesibble for wrappers, >>  but not accesible for QVector/QString? > > They wouldn't be accessible for wrappers either. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Nov 1 16:25:03 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Nov 2017 08:25:03 -0700 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <7439044.tNS2a1raN0@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <7439044.tNS2a1raN0@tjmaciei-mobl1> Message-ID: <27957466.kkmyDjLDve@tjmaciei-mobl1> On quarta-feira, 1 de novembro de 2017 08:21:10 PDT Thiago Macieira wrote: > "Won't that limit the actual maximum size?" > > No, not really, since it's already limited to half the full VM space. No > object can be larger than that. Using unsigned is unnecessary. Huh... on second thought, this limit applies to std::vector, but not to other types, since they don't have a single memory block. That said, if you are using more than 2 GB in a container on a 32-bit system, you deserve the OOM conditions. Please upgrade to a 64-bit processor. They're only 10 years old now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Nov 1 16:46:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Nov 2017 08:46:01 -0700 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <301551509549901@web8j.yandex.ru> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <7439044.tNS2a1raN0@tjmaciei-mobl1> <301551509549901@web8j.yandex.ru> Message-ID: <2445478.ddg24U4jYp@tjmaciei-mobl1> On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote: > > No, not really, since it's already limited to half the full VM space. No > > object can be larger than that. Using unsigned is unnecessary. > > Using unsigned for size types is crucial in preventing signed overflow in > pathological cases. Using signed for size types is crucial because the API expects to be able to count backwards from the end and needs to report failure in other situations. So unsigned is simply ruled out. There are also no pathological cases since there is no overflow. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philwave at gmail.com Wed Nov 1 16:50:20 2017 From: philwave at gmail.com (Philippe) Date: Wed, 01 Nov 2017 16:50:20 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <301551509549901@web8j.yandex.ru> References: <7439044.tNS2a1raN0@tjmaciei-mobl1> <301551509549901@web8j.yandex.ru> Message-ID: <20171101165018.CAB6.6F0322A@gmail.com> > Using unsigned for size types is crucial in preventing signed overflow in > pathological cases. During this interactive conference of "C++ gurus" (Herb Sutter, Bjarne Stroustrup, Andrei Alexandrescu, Stephan T. Lavavej, Chandler Carruth, Sean Parent, Scott Meyers, Michael Wong), it is clearly stated that it's generally a mistake to use unsigned... Check these extracts! https://www.youtube.com/watch?v=Puio5dly9N8#t=12m12s https://www.youtube.com/watch?v=Puio5dly9N8#t=42m40s https://www.youtube.com/watch?v=Puio5dly9N8#t=1h2m50s Philippe On Wed, 01 Nov 2017 18:25:01 +0300 Konstantin Tokarev wrote: > > > 01.11.2017, 18:21, "Thiago Macieira" : > > On quarta-feira, 1 de novembro de 2017 05:23:04 PDT ???? ?????????? wrote: > >>  Sorry for digging the thread, but how is > >>  * use qssize_t > >>  and > >>  ** Wrapping std::{unordered_}map may be acceptable > >>   combines? > >>  std::*map uses size_t in it's API (size, max_size, count, reserve, > >>  begin(size_type), end(size_type)) > > > > Our wrapper API can still use qssize_t. > > > > "Won't that limit the actual maximum size?" > > > > No, not really, since it's already limited to half the full VM space. No > > object can be larger than that. Using unsigned is unnecessary. > > Using unsigned for size types is crucial in preventing signed overflow in > pathological cases. > > > > >>  And offtop - what about allocators? They would be accesibble for wrappers, > >>  but not accesible for QVector/QString? > > > > They wouldn't be accessible for wrappers either. > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > >   Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ville.voutilainen at gmail.com Wed Nov 1 16:58:15 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 1 Nov 2017 17:58:15 +0200 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2445478.ddg24U4jYp@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <7439044.tNS2a1raN0@tjmaciei-mobl1> <301551509549901@web8j.yandex.ru> <2445478.ddg24U4jYp@tjmaciei-mobl1> Message-ID: On 1 November 2017 at 17:46, Thiago Macieira wrote: > On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote: >> > No, not really, since it's already limited to half the full VM space. No >> > object can be larger than that. Using unsigned is unnecessary. >> >> Using unsigned for size types is crucial in preventing signed overflow in >> pathological cases. > > Using signed for size types is crucial because the API expects to be able to > count backwards from the end and needs to report failure in other situations. > So unsigned is simply ruled out. > > There are also no pathological cases since there is no overflow. If your signed size type would ever overflow, a sanitizer can catch that. It's *much* harder for a sanitizer to diagnose incorrect wrap-around of an unsigned size type if that sanitizer wishes to avoid false positives. Having said that, it's non-trivial for a sanitizer to diagnose signed overflow, since that happens to work correctly and in the way the programmer expected on many platforms. From annulen at yandex.ru Wed Nov 1 16:58:35 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 01 Nov 2017 18:58:35 +0300 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2445478.ddg24U4jYp@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <7439044.tNS2a1raN0@tjmaciei-mobl1> <301551509549901@web8j.yandex.ru> <2445478.ddg24U4jYp@tjmaciei-mobl1> Message-ID: <388561509551915@web37j.yandex.ru> 01.11.2017, 18:46, "Thiago Macieira" : > On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote: >>  > No, not really, since it's already limited to half the full VM space. No >>  > object can be larger than that. Using unsigned is unnecessary. >> >>  Using unsigned for size types is crucial in preventing signed overflow in >>  pathological cases. > > Using signed for size types is crucial because the API expects to be able to > count backwards from the end and needs to report failure in other situations. > So unsigned is simply ruled out. Indeed, it's crucial to keep backward compatibility in API (Yet counting backwards is nothing more than a sugar, and STL containers cope fine with size_t) > > There are also no pathological cases since there is no overflow. There is overflow, try e.g. QByteArray::fromBase64() with array of size larger than INT_MAX / 3 If size was unsigned such bugs wouldn't lead to crashes or potential security issues > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Nov 1 17:29:35 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Nov 2017 09:29:35 -0700 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <388561509551915@web37j.yandex.ru> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2445478.ddg24U4jYp@tjmaciei-mobl1> <388561509551915@web37j.yandex.ru> Message-ID: <21264159.RZIjdcASdo@tjmaciei-mobl1> On quarta-feira, 1 de novembro de 2017 08:58:35 PDT Konstantin Tokarev wrote: > > There are also no pathological cases since there is no overflow. > > There is overflow, try e.g. QByteArray::fromBase64() with array of size > larger than INT_MAX / 3 Everywhere where they may be overflow, you need to be careful and detect said overflow. Using signed or unsigned makes no difference: overflowing is bad. > If size was unsigned such bugs wouldn't lead to crashes or potential > security issues Or they would. In QUtf8::convertFromUnicode: QByteArray result(len * 3, Qt::Uninitialized); If size() were unsigned and larger than UINT_MAX / 3, then that multiplication would overflow. The result could potentially be a very small number. uchar *dst = reinterpret_cast(const_cast(result.constData())); const ushort *src = reinterpret_cast(uc); const ushort *const end = src + len; while (src != end) { ... } That loop never rechecks the size of the allocation. It simply assumes that the destination buffer is large enough to encode the worst case of the UTF-8 This means the use of unsigned would not prevent issues. The loop would still corrupt memory and could crash. What's more, the unsigned overflow is not wrong. So you can't flag down the issue by using a sanitiser. If we keep it as signed, then that multiplication can be flagged and fixed. qnumeric_p.h has add_overflow and mul_overflow for unsigned types. For a proper signed check, you really need help from the compiler. But we can add them on top of the unsigned ones for the ones that don't help (MSVC), by using the implementation-defined behaviour of how an unsigned number gets converted to signed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Nov 1 20:03:27 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 1 Nov 2017 20:03:27 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2445478.ddg24U4jYp@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <7439044.tNS2a1raN0@tjmaciei-mobl1> <301551509549901@web8j.yandex.ru> <2445478.ddg24U4jYp@tjmaciei-mobl1> Message-ID: <01b4bc32-7e67-a01f-9b69-72185024a9fd@familiesomers.nl> Op 01/11/2017 om 16:46 schreef Thiago Macieira: > On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote: >>> No, not really, since it's already limited to half the full VM space. No >>> object can be larger than that. Using unsigned is unnecessary. >> Using unsigned for size types is crucial in preventing signed overflow in >> pathological cases. > Using signed for size types is crucial because the API expects to be able to > count backwards from the end and needs to report failure in other situations. > So unsigned is simply ruled out. I think we're stuck with that API indeed, but _if_ we had the freedom to re-design it, it would not be my choice to do it this way. I'd sooner choose for an explicit flag for the first case, and something like std::optional as a return value to handle the error-reporting case. I'd find that more explicit that using negative indices. However, I guess we cannot possibly break API that badly in Qt 6, so doing something like that is out of the question. André From mwoehlke.floss at gmail.com Wed Nov 1 20:23:39 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 1 Nov 2017 15:23:39 -0400 Subject: [Development] Repository request: MaterialWidgets In-Reply-To: References: <3DEEA0C4-DD06-4D44-BBEC-8B65CC537287@qt.io> <20171030115625.GA12392@troll08> <697CEDD9-341C-40BD-9759-10C72F32724B@qt.io> Message-ID: On 2017-10-30 09:04, iman ahmadvand wrote: > But we've some new widgets beside the existing widgets, for example: > > Switch: https://material.io > /guidelines/components/selection-controls.html#selection-controls-switch Why not add this to Qt? Personally, I am not convinced that UI elements that would use this shouldn't just be using a check box, but I doubt I'd win that battle. Switches seem to be everywhere; adding a QSwitch probably makes sense. (GTK already has one...) > Discrete Slider: https://material.io > /guidelines/components/sliders.html#sliders-discrete-slider Why not improve QSlider? > Snack Bar: https://material.io/guidelines/components/snackbars-toasts.html# > snackbars-toasts-specs This doesn't look like something that is the job of a widget, but rather should be handled by existing notification frameworks. p.s. What jerk designed that site that scrolling the sidebar depends on Javascript? There's no excuse for that... -- Matthew From annulen at yandex.ru Wed Nov 1 20:23:56 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 01 Nov 2017 22:23:56 +0300 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <20171101165018.CAB6.6F0322A@gmail.com> References: <7439044.tNS2a1raN0@tjmaciei-mobl1> <301551509549901@web8j.yandex.ru> <20171101165018.CAB6.6F0322A@gmail.com> Message-ID: <1312901509564236@web31j.yandex.ru> 01.11.2017, 18:50, "Philippe" : >>  Using unsigned for size types is crucial in preventing signed overflow in >>  pathological cases. > > During this interactive conference of "C++ gurus" (Herb Sutter, Bjarne > Stroustrup, Andrei Alexandrescu, Stephan T. Lavavej, Chandler Carruth, > Sean Parent, Scott Meyers, Michael Wong), it is clearly stated that it's > generally a mistake to use unsigned... > Check these extracts! > https://www.youtube.com/watch?v=Puio5dly9N8#t=12m12s > https://www.youtube.com/watch?v=Puio5dly9N8#t=42m40s > https://www.youtube.com/watch?v=Puio5dly9N8#t=1h2m50s I've listened and I think I buy this. Their main argument is about mixing unsigned and signed, and Qt is a framework for a wide audience, and many people seem to pass negative numbers to APIs accepting unsigned without second thought (it's just a compiler warning, who looks at them after all), so using unsigned may increase number of bugs on user side. > > Philippe > > On Wed, 01 Nov 2017 18:25:01 +0300 > Konstantin Tokarev wrote: > >>  01.11.2017, 18:21, "Thiago Macieira" : >>  > On quarta-feira, 1 de novembro de 2017 05:23:04 PDT ???? ?????????? wrote: >>  >>  Sorry for digging the thread, but how is >>  >>  * use qssize_t >>  >>  and >>  >>  ** Wrapping std::{unordered_}map may be acceptable >>  >>   combines? >>  >>  std::*map uses size_t in it's API (size, max_size, count, reserve, >>  >>  begin(size_type), end(size_type)) >>  > >>  > Our wrapper API can still use qssize_t. >>  > >>  > "Won't that limit the actual maximum size?" >>  > >>  > No, not really, since it's already limited to half the full VM space. No >>  > object can be larger than that. Using unsigned is unnecessary. >> >>  Using unsigned for size types is crucial in preventing signed overflow in >>  pathological cases. >> >>  > >>  >>  And offtop - what about allocators? They would be accesibble for wrappers, >>  >>  but not accesible for QVector/QString? >>  > >>  > They wouldn't be accessible for wrappers either. >>  > >>  > -- >>  > Thiago Macieira - thiago.macieira (AT) intel.com >>  >   Software Architect - Intel Open Source Technology Center >>  > >>  > _______________________________________________ >>  > Development mailing list >>  > Development at qt-project.org >>  > http://lists.qt-project.org/mailman/listinfo/development >> >>  -- >>  Regards, >>  Konstantin >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From mwoehlke.floss at gmail.com Wed Nov 1 20:23:39 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 1 Nov 2017 15:23:39 -0400 Subject: [Development] Repository request: MaterialWidgets In-Reply-To: References: <3DEEA0C4-DD06-4D44-BBEC-8B65CC537287@qt.io> <20171030115625.GA12392@troll08> <697CEDD9-341C-40BD-9759-10C72F32724B@qt.io> Message-ID: On 2017-10-30 09:04, iman ahmadvand wrote: > But we've some new widgets beside the existing widgets, for example: > > Switch: https://material.io > /guidelines/components/selection-controls.html#selection-controls-switch Why not add this to Qt? Personally, I am not convinced that UI elements that would use this shouldn't just be using a check box, but I doubt I'd win that battle. Switches seem to be everywhere; adding a QSwitch probably makes sense. (GTK already has one...) > Discrete Slider: https://material.io > /guidelines/components/sliders.html#sliders-discrete-slider Why not improve QSlider? > Snack Bar: https://material.io/guidelines/components/snackbars-toasts.html# > snackbars-toasts-specs This doesn't look like something that is the job of a widget, but rather should be handled by existing notification frameworks. p.s. What jerk designed that site that scrolling the sidebar depends on Javascript? There's no excuse for that... -- Matthew From thiago.macieira at intel.com Wed Nov 1 21:00:59 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Nov 2017 13:00:59 -0700 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <01b4bc32-7e67-a01f-9b69-72185024a9fd@familiesomers.nl> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2445478.ddg24U4jYp@tjmaciei-mobl1> <01b4bc32-7e67-a01f-9b69-72185024a9fd@familiesomers.nl> Message-ID: <1795673.fhMTVDCqt2@tjmaciei-mobl1> On quarta-feira, 1 de novembro de 2017 12:03:27 PDT André Somers wrote: > Using signed for size types is crucial because the API expects to be able to > > count backwards from the end and needs to report failure in other > > situations. So unsigned is simply ruled out. > > I think we're stuck with that API indeed, but _if_ we had the freedom to > re-design it, it would not be my choice to do it this way. I'd sooner > choose for an explicit flag for the first case, and something like > std::optional as a return value to handle the error-reporting case. I'd > find that more explicit that using negative indices. However, I guess we > cannot possibly break API that badly in Qt 6, so doing something like > that is out of the question. That doesn't allow implementing indexOf() that searches from a position from the end. It's not just failure modes. So, no, even with a redesign we'd stick with signed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Nov 1 21:15:11 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 1 Nov 2017 21:15:11 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <1795673.fhMTVDCqt2@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2445478.ddg24U4jYp@tjmaciei-mobl1> <01b4bc32-7e67-a01f-9b69-72185024a9fd@familiesomers.nl> <1795673.fhMTVDCqt2@tjmaciei-mobl1> Message-ID: <0df74517-a896-3c88-ba65-f189ade44527@familiesomers.nl> Op 01/11/2017 om 21:00 schreef Thiago Macieira: > On quarta-feira, 1 de novembro de 2017 12:03:27 PDT André Somers wrote: >> Using signed for size types is crucial because the API expects to be able to >>> count backwards from the end and needs to report failure in other >>> situations. So unsigned is simply ruled out. >> I think we're stuck with that API indeed, but _if_ we had the freedom to >> re-design it, it would not be my choice to do it this way. I'd sooner >> choose for an explicit flag for the first case, and something like >> std::optional as a return value to handle the error-reporting case. I'd >> find that more explicit that using negative indices. However, I guess we >> cannot possibly break API that badly in Qt 6, so doing something like >> that is out of the question. > That doesn't allow implementing indexOf() that searches from a position from > the end. It's not just failure modes. > > So, no, even with a redesign we'd stick with signed. > That doesn't make sense. Of course it allows for that. You'd give indexOf a flag like Qt::searchTowardsBeginning (default being Qt::searchTowardsEnd) to determine the direction to search in. Or do you mean that you want the result also to be counted from the end? If all API's take the index counted from the begining there would not be much use for that. You either calculate it yourself by substracting the result from length(), or you add another flag and do something like std::optional indexOf(needle, startIndex, Qt::searchTowardsBeginning | Qt::asCountedFromEnd) . Personally, after many years of using the Qt APIs, I do not find the APIs taking negative numbers as an index intuitive. André From thiago.macieira at intel.com Wed Nov 1 22:27:07 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Nov 2017 14:27:07 -0700 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <0df74517-a896-3c88-ba65-f189ade44527@familiesomers.nl> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <1795673.fhMTVDCqt2@tjmaciei-mobl1> <0df74517-a896-3c88-ba65-f189ade44527@familiesomers.nl> Message-ID: <1802090.OEni2Hm0CT@tjmaciei-mobl1> On quarta-feira, 1 de novembro de 2017 13:15:11 PDT André Somers wrote: > That doesn't make sense. Of course it allows for that. > > You'd give indexOf a flag like Qt::searchTowardsBeginning (default being > Qt::searchTowardsEnd) to determine the direction to search in. Or do you > mean that you want the result also to be counted from the end? You're confusing lastIndexOf() which searchs backwards from the end with indexOf() searching forwards from a position near the end. > If all > API's take the index counted from the begining there would not be much > use for that. You either calculate it yourself by substracting the > result from length(), or you add another flag and do something like > std::optional indexOf(needle, startIndex, > Qt::searchTowardsBeginning | Qt::asCountedFromEnd) . Yeah, we won't do that. The QString, QByteArray and QVector can't be bigger than the maximum size representable in qssize_t anyway. So we don't *need* the extra bit. Since we don't need the extra bit, we will stick to signed because of its benefits: 1) overflow can be caught with sanitisers 2) doesn't cause sign conversion warnings when converted to other signed values 3) the instruction from the committee is to use signed unless you explicitly need modulo-2 overflow 4) the standard library, if ever rewritten, will use signed counters -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Thu Nov 2 05:55:18 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 2 Nov 2017 05:55:18 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <1802090.OEni2Hm0CT@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <1795673.fhMTVDCqt2@tjmaciei-mobl1> <0df74517-a896-3c88-ba65-f189ade44527@familiesomers.nl> <1802090.OEni2Hm0CT@tjmaciei-mobl1> Message-ID: Op 01/11/2017 om 22:27 schreef Thiago Macieira: > On quarta-feira, 1 de novembro de 2017 13:15:11 PDT André Somers wrote: >> That doesn't make sense. Of course it allows for that. >> >> You'd give indexOf a flag like Qt::searchTowardsBeginning (default being >> Qt::searchTowardsEnd) to determine the direction to search in. Or do you >> mean that you want the result also to be counted from the end? > You're confusing lastIndexOf() which searchs backwards from the end with > indexOf() searching forwards from a position near the end. Yes, those two are orthogonal. Fine. That doesn't disqualify the solution IMO. In fact, I already separated the two in the suggested mock-API. > >> If all >> API's take the index counted from the begining there would not be much >> use for that. You either calculate it yourself by substracting the >> result from length(), or you add another flag and do something like >> std::optional indexOf(needle, startIndex, >> Qt::searchTowardsBeginning | Qt::asCountedFromEnd) . > Yeah, we won't do that. The QString, QByteArray and QVector can't be bigger > than the maximum size representable in qssize_t anyway. So we don't *need* the > extra bit. Fine, but the argument was not about that. The comment I made was on if using negative indexes is good API to begin with. I think it is not. > > Since we don't need the extra bit, we will stick to signed because of its > benefits: > 1) overflow can be caught with sanitisers > 2) doesn't cause sign conversion warnings when converted to other signed > values > 3) the instruction from the committee is to use signed unless you explicitly > need modulo-2 overflow > 4) the standard library, if ever rewritten, will use signed counters > All that is really orthogonal to if you use negative indices as part of your API, which was what I was responding to in the first place. You used _that_ as an argument before, and I suggested that that is not such great API IMHO and nowadays I'd do that differently. However, the world we live in is one where Qt has had the current API for ages and changing that would break too much. André From jedrzej.nowacki at qt.io Thu Nov 2 09:32:10 2017 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Thu, 02 Nov 2017 09:32:10 +0100 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: References: <3496979.lGfoDNtG9L@43> Message-ID: <2902739.qlOhsxzXW6@43> On Wednesday, November 1, 2017 2:59:22 PM CET Jedrzej Nowacki wrote: > Hi, > > Yet another update. We narrowed down the IO issue. The network update from > 1G to 10G, mentioned before, brought compellent into the picture and that > one didn't want to cooperate nicely with our btrfs installation, for an > unknown reason. The link will be downgraded and we would go back to a SSD > storage as soon as possible (currently there are some disk operations that > can not be interrupted). > > Regarding 5.10 branch, it is still locked, but I guess it is not a > surprise. https://codereview.qt-project.org/#/c/209970/ needs to be get > integrated, but in the current hostile conditions it is not easy. > > Cheers, > Jędrek Everything should be functional today. Have fun. Cheers, Jędrek From jedrzej.nowacki at qt.io Thu Nov 2 11:28:22 2017 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Thu, 02 Nov 2017 11:28:22 +0100 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: <2902739.qlOhsxzXW6@43> References: <2902739.qlOhsxzXW6@43> Message-ID: <1599835.iEXUloHfEY@43> On Thursday, November 2, 2017 9:32:10 AM CET Jedrzej Nowacki wrote: > Everything should be functional today. Have fun. > > Cheers, > Jędrek Well, almost, 5.9 is blocked because of a bug in provisioning script (https:// codereview.qt-project.org/#/c/209874/). Let's hope that is the end of the series of failures that we had for the last days. Cheers, Jędrek From pasi.keranen at qt.io Thu Nov 2 12:48:58 2017 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Thu, 2 Nov 2017 11:48:58 +0000 Subject: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio Message-ID: <97DC361C-684B-49BA-BDA2-38184540B2DB@qt.io> Hi all, Those of you who have been following our blog posts or who went to QtCon this year know about the new 3D UI design tool and runtime combination we received as contribution from NVIDIA earlier this year. The tool is now known as Qt 3D Studio and the repositories were opened before Qt WS 2017. For more info check out: http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/ I’d like to name myself (Pasi Keränen) as the maintainer of Qt 3D Studio. I’ve been involved in the project since the early negotiations with NVIDIA and handling the receiving of the contribution from them. All the way to leading the Qt integration work that is still ongoing towards 1.0 release later this month. As Qt 3D Studio is a large piece of work I’d like to also suggest the following persons as maintainers of sub-areas of Qt 3D Studio: Soili Väinämö – Maintainer of UX, ensuring the user experience of the tool and runtime develop going onwards. Soili has been doing excellent work in both converting the look’n’feel of the application to leading UX studies on how to improve the usability of the product from end user point of view. Tomi Korpipää – Maintainer of Editor Application code. Tomi has done great work in handling the bug flow and converting the look’n’feel to more Qt like together with Soili. Antti Määttä – Maintainer of Runtime 1.0 and runtime integration. Antti has long history of working with 3D engine code and has done excellent work in for example prototyping OpenGL ES 2 support in the runtime component of Qt 3D Studio. Laszlo Agocs – Maintainer of Qt 3D based Runtime 2.0. Laszlo has been working on the prototype runtime for some time now and is already looking in to productizing it. Miikka Heikkinen – Maintainer of installer and viewer application. Miikka has been instrumental in getting the installer creation implemented and also has been adding new experimental features to the viewer like image sequence generation. Regards, Pasi Keränen Team lead of TQtC 3D Team, Oulu -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Thu Nov 2 13:11:13 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 2 Nov 2017 12:11:13 +0000 Subject: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio In-Reply-To: <97DC361C-684B-49BA-BDA2-38184540B2DB@qt.io> References: <97DC361C-684B-49BA-BDA2-38184540B2DB@qt.io> Message-ID: <03E7DB92-0907-4857-BFC9-14AF56F00D63@qt.io> Hi Pasi, I fully support this. Qt 3D Studio is a big piece that TQtC just open sourced earlier and it’s good to get a defined maintainer structure for that project. Cheers, Lars On 2 Nov 2017, at 12:48, Pasi Keränen > wrote: Hi all, Those of you who have been following our blog posts or who went to QtCon this year know about the new 3D UI design tool and runtime combination we received as contribution from NVIDIA earlier this year. The tool is now known as Qt 3D Studio and the repositories were opened before Qt WS 2017. For more info check out: http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/ I’d like to name myself (Pasi Keränen) as the maintainer of Qt 3D Studio. I’ve been involved in the project since the early negotiations with NVIDIA and handling the receiving of the contribution from them. All the way to leading the Qt integration work that is still ongoing towards 1.0 release later this month. As Qt 3D Studio is a large piece of work I’d like to also suggest the following persons as maintainers of sub-areas of Qt 3D Studio: Soili Väinämö – Maintainer of UX, ensuring the user experience of the tool and runtime develop going onwards. Soili has been doing excellent work in both converting the look’n’feel of the application to leading UX studies on how to improve the usability of the product from end user point of view. Tomi Korpipää – Maintainer of Editor Application code. Tomi has done great work in handling the bug flow and converting the look’n’feel to more Qt like together with Soili. Antti Määttä – Maintainer of Runtime 1.0 and runtime integration. Antti has long history of working with 3D engine code and has done excellent work in for example prototyping OpenGL ES 2 support in the runtime component of Qt 3D Studio. Laszlo Agocs – Maintainer of Qt 3D based Runtime 2.0. Laszlo has been working on the prototype runtime for some time now and is already looking in to productizing it. Miikka Heikkinen – Maintainer of installer and viewer application. Miikka has been instrumental in getting the installer creation implemented and also has been adding new experimental features to the viewer like image sequence generation. Regards, Pasi Keränen Team lead of TQtC 3D Team, Oulu _______________________________________________ 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 sergio.martins at kdab.com Thu Nov 2 13:46:24 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 02 Nov 2017 12:46:24 +0000 Subject: [Development] Nominating Christoph Schleifenbaum for Approver Message-ID: <020b54da456dd56e2e43426b9fb666cf@kdab.com> Hi, I'd like to nominate Christoph Schleifenbaum for Approver. He's been with KDAB for 12 years and has done dozens of fixes for cocoa, widgets and item views. He' also one of the developers who worked on the Qt3DStudio port to Qt very recently. https://codereview.qt-project.org/#/q/owner:%22Christoph+Schleifenbaum%22,n,z 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 adam.treat at qt.io Thu Nov 2 13:54:11 2017 From: adam.treat at qt.io (Adam Treat) Date: Thu, 2 Nov 2017 08:54:11 -0400 Subject: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio In-Reply-To: <03E7DB92-0907-4857-BFC9-14AF56F00D63@qt.io> References: <97DC361C-684B-49BA-BDA2-38184540B2DB@qt.io> <03E7DB92-0907-4857-BFC9-14AF56F00D63@qt.io> Message-ID: <316f48ed-f2d0-d134-1184-4e7edb2dac1c@qt.io> +1 On 11/02/2017 08:11 AM, Lars Knoll wrote: > Hi Pasi, > > I fully support this. Qt 3D Studio is a big piece that TQtC just open > sourced earlier and it’s good to get a defined maintainer structure > for that project. > > Cheers, > Lars > >> On 2 Nov 2017, at 12:48, Pasi Keränen > > wrote: >> >> Hi all, >> Those of you who have been following our blog posts or who went to >> QtCon this year know about the new 3D UI design tool and runtime >> combination we received as contribution from NVIDIA earlier this >> year. The tool is now known as Qt 3D Studio and the repositories were >> opened before Qt WS 2017. For more info check >> out:http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/ >> I’d like to name myself (Pasi Keränen) as the maintainer of Qt 3D >> Studio. I’ve been involved in the project since the early >> negotiations with NVIDIA and handling the receiving of the >> contribution from them. All the way to leading the Qt integration >> work that is still ongoing towards 1.0 release later this month. >> As Qt 3D Studio is a large piece of work I’d like to also suggest the >> following persons as maintainers of sub-areas of Qt 3D Studio: >> *Soili Väinämö*– Maintainer of UX, ensuring the user experience of >> the tool and runtime develop going onwards. Soili has been doing >> excellent work in both converting the look’n’feel of the application >> to leading UX studies on how to improve the usability of the product >> from end user point of view. >> *Tomi Korpipää*– Maintainer of Editor Application code. Tomi has done >> great work in handling the bug flow and converting the look’n’feel to >> more Qt like together with Soili. >> *Antti Määttä*– Maintainer of Runtime 1.0 and runtime integration. >> Antti has long history of working with 3D engine code and has done >> excellent work in for example prototyping OpenGL ES 2 support in the >> runtime component of Qt 3D Studio. >> *Laszlo Agocs*– Maintainer of Qt 3D based Runtime 2.0. Laszlo has >> been working on the prototype runtime for some time now and is >> already looking in to productizing it. >> *Miikka Heikkinen*– Maintainer of installer and viewer application. >> Miikka has been instrumental in getting the installer creation >> implemented and also has been adding new experimental features to the >> viewer like image sequence generation. >> Regards, >> Pasi Keränen >> Team lead of TQtC 3D Team, Oulu >> _______________________________________________ >> 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 andras.mantia at kdab.com Thu Nov 2 14:53:50 2017 From: andras.mantia at kdab.com (Andras Mantia) Date: Thu, 02 Nov 2017 15:53:50 +0200 Subject: [Development] Nominating Christoph Schleifenbaum for Approver In-Reply-To: <020b54da456dd56e2e43426b9fb666cf@kdab.com> References: <020b54da456dd56e2e43426b9fb666cf@kdab.com> Message-ID: <3278337.goCKjlrpDL@stein.andtib> On Thursday, November 2, 2017 2:46:24 PM EET Sergio Martins wrote: > Hi, > > > I'd like to nominate Christoph Schleifenbaum for Approver. > > He's been with KDAB for 12 years and has done dozens of fixes for cocoa, > widgets and item views. > > He' also one of the developers who worked on the Qt3DStudio port to Qt > very recently. > > > https://codereview.qt-project.org/#/q/owner:%22Christoph+Schleifenbaum%22,n, > z Although I'm a new approver myself, I worked with Christoph on this and other projects and I support him. Andras -- András Mantia | andras.mantia at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From rafael.roquetto at kdab.com Thu Nov 2 14:56:45 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Thu, 2 Nov 2017 14:56:45 +0100 Subject: [Development] Nominating Christoph Schleifenbaum for Approver In-Reply-To: <020b54da456dd56e2e43426b9fb666cf@kdab.com> References: <020b54da456dd56e2e43426b9fb666cf@kdab.com> Message-ID: <20171102135644.GA18817@polaris.localdomain> +1 from me Disclaimer: KDABian here On Thu, Nov 02, 2017 at 12:46:24PM +0000, Sergio Martins wrote: > Hi, > > > I'd like to nominate Christoph Schleifenbaum for Approver. > > He's been with KDAB for 12 years and has done dozens of fixes for cocoa, > widgets and item views. > > He' also one of the developers who worked on the Qt3DStudio port to Qt very > recently. > > > https://codereview.qt-project.org/#/q/owner:%22Christoph+Schleifenbaum%22,n,z > > > > > 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 Jake.Petroules at qt.io Thu Nov 2 16:10:15 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 2 Nov 2017 15:10:15 +0000 Subject: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio In-Reply-To: <316f48ed-f2d0-d134-1184-4e7edb2dac1c@qt.io> References: <97DC361C-684B-49BA-BDA2-38184540B2DB@qt.io> <03E7DB92-0907-4857-BFC9-14AF56F00D63@qt.io> <316f48ed-f2d0-d134-1184-4e7edb2dac1c@qt.io> Message-ID: <9C7C5E6D-3AC9-43A2-AA3F-3A4012D3CF0E@qt.io> +1, no brainer! > On Nov 2, 2017, at 5:54 AM, Adam Treat wrote: > > +1 > > On 11/02/2017 08:11 AM, Lars Knoll wrote: >> Hi Pasi, >> >> I fully support this. Qt 3D Studio is a big piece that TQtC just open sourced earlier and it’s good to get a defined maintainer structure for that project. >> >> Cheers, >> Lars >> >>> On 2 Nov 2017, at 12:48, Pasi Keränen wrote: >>> >>> Hi all, >>> >>> Those of you who have been following our blog posts or who went to QtCon this year know about the new 3D UI design tool and runtime combination we received as contribution from NVIDIA earlier this year. The tool is now known as Qt 3D Studio and the repositories were opened before Qt WS 2017. For more info check out: http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/ >>> >>> I’d like to name myself (Pasi Keränen) as the maintainer of Qt 3D Studio. I’ve been involved in the project since the early negotiations with NVIDIA and handling the receiving of the contribution from them. All the way to leading the Qt integration work that is still ongoing towards 1.0 release later this month. >>> >>> As Qt 3D Studio is a large piece of work I’d like to also suggest the following persons as maintainers of sub-areas of Qt 3D Studio: >>> Soili Väinämö – Maintainer of UX, ensuring the user experience of the tool and runtime develop going onwards. Soili has been doing excellent work in both converting the look’n’feel of the application to leading UX studies on how to improve the usability of the product from end user point of view. >>> Tomi Korpipää – Maintainer of Editor Application code. Tomi has done great work in handling the bug flow and converting the look’n’feel to more Qt like together with Soili. >>> Antti Määttä – Maintainer of Runtime 1.0 and runtime integration. Antti has long history of working with 3D engine code and has done excellent work in for example prototyping OpenGL ES 2 support in the runtime component of Qt 3D Studio. >>> Laszlo Agocs – Maintainer of Qt 3D based Runtime 2.0. Laszlo has been working on the prototype runtime for some time now and is already looking in to productizing it. >>> Miikka Heikkinen – Maintainer of installer and viewer application. Miikka has been instrumental in getting the installer creation implemented and also has been adding new experimental features to the viewer like image sequence generation. >>> >>> Regards, >>> Pasi Keränen >>> Team lead of TQtC 3D Team, Oulu >>> _______________________________________________ >>> 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 -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From xbenlau at gmail.com Thu Nov 2 17:12:34 2017 From: xbenlau at gmail.com (Ben Lau) Date: Fri, 3 Nov 2017 00:12:34 +0800 Subject: [Development] List all components within a QML package Message-ID: Hi, Is there any API available (include private) to list all the components within a QML package? I am developing a testing tool and need the information (only the name is needed). Thanks for any advise. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Thu Nov 2 17:14:56 2017 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 2 Nov 2017 17:14:56 +0100 Subject: [Development] List all components within a QML package In-Reply-To: References: Message-ID: On Thu, Nov 2, 2017 at 5:12 PM, Ben Lau wrote: > Hi, > > Is there any API available (include private) to list all the components > within a QML package? I am developing a testing tool and need the > information (only the name is needed). There's the qmlplugindump application, it should give you everything you need. Aleix From xbenlau at gmail.com Thu Nov 2 17:20:59 2017 From: xbenlau at gmail.com (Ben Lau) Date: Fri, 3 Nov 2017 00:20:59 +0800 Subject: [Development] List all components within a QML package In-Reply-To: References: Message-ID: On 3 November 2017 at 00:14, Aleix Pol wrote: > On Thu, Nov 2, 2017 at 5:12 PM, Ben Lau wrote: > > Hi, > > > > Is there any API available (include private) to list all the components > > within a QML package? I am developing a testing tool and need the > > information (only the name is needed). > > There's the qmlplugindump application, it should give you everything you > need. > > Aleix > Hi Aleix, Excellent && thx. I will digest the source code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Nov 2 19:01:52 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 2 Nov 2017 11:01:52 -0700 Subject: [Development] List all components within a QML package In-Reply-To: References: Message-ID: <2485808.KPVgv5WvaG@tjmaciei-mobl1> On quinta-feira, 2 de novembro de 2017 09:20:59 PDT Ben Lau wrote: > On 3 November 2017 at 00:14, Aleix Pol wrote: > > On Thu, Nov 2, 2017 at 5:12 PM, Ben Lau wrote: > > > Hi, > > > > > > Is there any API available (include private) to list all the components > > > within a QML package? I am developing a testing tool and need the > > > information (only the name is needed). > > > > There's the qmlplugindump application, it should give you everything you > > need. > > > > Aleix > > Hi Aleix, > > Excellent && thx. I will digest the source code. Related: there's the qplugininfo tool too, for regular plugins. Looks like KDE uses the JSON feature as it was intended: $ qtplugininfo /usr/lib64/qt5/plugins/kmail/kmail_antispamplugin.so IID "org.kde.KPluginFactory" Qt 5.9.2 (release) User Data: { "KPlugin": { "Description": "This plugin allows you to configure Anti Spam in KMail.", "Description[ca at valencia]": "Este connector permet comprovar el correu brossa en el KMail.", "Description[ca]": "Aquest connector permet comprovar el correu brossa en el KMail.", "Description[de]": "Mit diesem Modul können Sie die Anti-Spam-Funktion in KMail einrichten.", "Description[es]": "Este complemento le permite configurar un filtro anti correo basura en KMail.", "Description[et]": "See plugin võimaldab seadistada KMaili rämpspostivastast filtrit.", "Description[fi]": "Tällä liitännäisellä voit muuttaa KMailin roskapostiasetuksia.", "Description[fr]": "Ce module permet de configurer l'anti pourriel dans KMail.", "Description[it]": "Questa estensione permette di configurare il servizio anti-spam in KMail.", "Description[nl]": "Deze plugin stelt u in staat om Anti-spam in KMail in te stellen.", "Description[pl]": "Ta wtyczka umożliwia ustawienie programu antyspamowego w KMail.", "Description[pt]": "Este 'plugin' permite configurar o módulo Anti-Lixo Electrónico no KMail.", "Description[ru]": "Этот модуль позволяет настроить антиспам в KMail.", "Description[sk]": "Tento plugin vám umožní nastaviť antispam v KMail.", "Description[sl]": "Ta vstavek omogoča nastavitev programa proti neželeni pošti v KMail-u.", "Description[sr at ijekavian]": "Овај прикључак омогућава подешавање заштите од спама у К‑пошти", "Description[sr at ijekavianlatin]": "Ovaj priključak omogućava podešavanje zaštite od spama u K‑pošti", "Description[sr at latin]": "Ovaj priključak omogućava podešavanje zaštite od spama u K‑pošti", "Description[sr]": "Овај прикључак омогућава подешавање заштите од спама у К‑пошти", "Description[sv]": "Insticksprogrammet gör det möjligt att anpassa skräpposthantering i Kmail.", "Description[tr]": "Bu eklenti, KMail içinde Anti Spam yapılandırmanıza imkan verir.", "Description[uk]": "За допомогою цього додатка можна налаштувати засіб боротьби зі спамом у KMail.", "Description[x-test]": "xxThis plugin allows you to configure Anti Spam in KMail.xx", "Description[zh_CN]": "此插件允许您配置 KMail 反垃圾邮件机制。", "EnabledByDefault": "true", "Id": "kmailantispam", "Name": "Antispam", "Name[ca at valencia]": "Contra el correu brossa", "Name[ca]": "Contra el correu brossa", "Name[de]": "Anti-Spam", "Name[es]": "Anti correo basura", "Name[et]": "Võitlus rämpspostiga", "Name[fi]": "Roskapostin suodatus", "Name[fr]": "Anti pourriel", "Name[gl]": "Anti correo lixo", "Name[pl]": "Antyspam", "Name[pt]": "Anti-Lixo Electrónico", "Name[ru]": "Антиспам", "Name[sl]": "Proti neželeni pošti", "Name[sr at ijekavian]": "Противспам", "Name[sr at ijekavianlatin]": "Protivspam", "Name[sr at latin]": "Protivspam", "Name[sr]": "Противспам", "Name[sv]": "Antiskräppost", "Name[uk]": "Антиспам", "Name[x-test]": "xxAntispamxx", "Name[zh_CN]": "垃圾防御", "ServiceTypes": [ "KMail/MainViewPlugin" ], "Version": "1.0" } } But sometimes drops non-plugins to the plugin dir (at least, not QPlugin): $ qtplugininfo /usr/lib64/qt5/plugins/*thumbnail.so qtplugininfo: /usr/lib64/qt5/plugins/audiothumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ audiothumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/comicbookthumbnail.so: No plug-in meta- data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ comicbookthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/djvuthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ djvuthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/exrthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ exrthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/fontthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ fontthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/gsthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ gsthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/htmlthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ htmlthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/imagethumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ imagethumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/jpegthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ jpegthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/kritathumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ kritathumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/mobithumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ mobithumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/rawthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ rawthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/svgthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ svgthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/textthumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ textthumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/webarchivethumbnail.so: No plug-in meta- data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ webarchivethumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/windowsexethumbnail.so: No plug-in meta- data found: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ windowsexethumbnail.so' qtplugininfo: /usr/lib64/qt5/plugins/windowsimagethumbnail.so: No plug-in meta-data found: Failed to extract plugin meta data from '/usr/lib64/qt5/ plugins/windowsimagethumbnail.so' -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at qt.io Fri Nov 3 08:55:48 2017 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Fri, 03 Nov 2017 08:55:48 +0100 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: <1599835.iEXUloHfEY@43> References: <2902739.qlOhsxzXW6@43> <1599835.iEXUloHfEY@43> Message-ID: <2477586.Q0RTkcUXdS@43> On Thursday, November 2, 2017 11:28:22 AM CET Jedrzej Nowacki wrote: > Well, almost, 5.9 is blocked because of a bug in provisioning script > (https:// codereview.qt-project.org/#/c/209874/). Let's hope that is the > end of the series of failures that we had for the last days. > > Cheers, > Jędrek Gerrit joined the party, some patches are in a wrong state. If you see something that is hanging in integrating or stating state, or if a patch set is merged, but it is not marked as such in gerrit, then please contact out gerrit admins. There is also a good news, https://codereview.qt-project.org/#/c/209874/ was merged so 5.9 should work now. Thanks, Jędrek From eirik.aavitsland at qt.io Fri Nov 3 09:28:41 2017 From: eirik.aavitsland at qt.io (Eirik Aavitsland) Date: Fri, 3 Nov 2017 09:28:41 +0100 Subject: [Development] Continuous Integration issues - Coin temporarily down In-Reply-To: <2477586.Q0RTkcUXdS@43> References: <2902739.qlOhsxzXW6@43> <1599835.iEXUloHfEY@43> <2477586.Q0RTkcUXdS@43> Message-ID: On 03. nov. 2017 08:55, Jedrzej Nowacki wrote: > On Thursday, November 2, 2017 11:28:22 AM CET Jedrzej Nowacki wrote: >> Well, almost, 5.9 is blocked because of a bug in provisioning script >> (https:// codereview.qt-project.org/#/c/209874/). Let's hope that is the >> end of the series of failures that we had for the last days. >> >> Cheers, >> Jędrek > > Gerrit joined the party, some patches are in a wrong state. If you see > something that is hanging in integrating or stating state, or if a patch set > is merged, but it is not marked as such in gerrit, then please contact out > gerrit admins. > Well https://codereview.qt-project.org/#/q/status:integrating,n,z shows 4 patches integrating since Oct 31; presumably they are all hanging. Cheers, - Eirik Aa. From mike.krus at kdab.com Fri Nov 3 23:04:14 2017 From: mike.krus at kdab.com (Mike Krus) Date: Fri, 3 Nov 2017 22:04:14 +0000 Subject: [Development] Nominating Christoph Schleifenbaum for Approver In-Reply-To: <020b54da456dd56e2e43426b9fb666cf@kdab.com> References: <020b54da456dd56e2e43426b9fb666cf@kdab.com> Message-ID: +1 from me (with the disclaimer that we both work for KDAB). > On 2 Nov 2017, at 12:46, Sergio Martins wrote: > > Hi, > > > I'd like to nominate Christoph Schleifenbaum for Approver. > > He's been with KDAB for 12 years and has done dozens of fixes for cocoa, widgets and item views. > > He' also one of the developers who worked on the Qt3DStudio port to Qt very recently. > > > https://codereview.qt-project.org/#/q/owner:%22Christoph+Schleifenbaum%22,n,z > > > > > 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 -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts From pasi.keranen at qt.io Sat Nov 4 12:00:06 2017 From: pasi.keranen at qt.io (=?iso-8859-1?Q?Pasi_Ker=E4nen?=) Date: Sat, 4 Nov 2017 11:00:06 +0000 Subject: [Development] Nominating Christoph Schleifenbaum for Approver In-Reply-To: References: <020b54da456dd56e2e43426b9fb666cf@kdab.com>, Message-ID: +1 from me as well. Christoph has done good work on Qt 3D Studio. Regards, Pasi ________________________________ From: Development on behalf of Mike Krus Sent: Saturday, November 4, 2017 12:04:14 AM To: Sergio Martins Cc: development at qt-project.org Subject: Re: [Development] Nominating Christoph Schleifenbaum for Approver +1 from me (with the disclaimer that we both work for KDAB). > On 2 Nov 2017, at 12:46, Sergio Martins wrote: > > Hi, > > > I'd like to nominate Christoph Schleifenbaum for Approver. > > He's been with KDAB for 12 years and has done dozens of fixes for cocoa, widgets and item views. > > He' also one of the developers who worked on the Qt3DStudio port to Qt very recently. > > > https://codereview.qt-project.org/#/q/owner:%22Christoph+Schleifenbaum%22,n,z > > > > > 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 -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, 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 aha_1980 at gmx.de Sun Nov 5 18:00:40 2017 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Sun, 5 Nov 2017 18:00:40 +0100 Subject: [Development] Nominating Lorenz Haas for approver Message-ID: Hello all, I'd like to nominate Lorenz Haas for approver status. Lorenz has been contributing to Qt and Qt Creator since spring 2013. He has provided some high quality patches to Creators C++ Editor and is the author of Creators Beautifier plugin. He is actively reviewing patches in these areas, and recently started contributing to and reviewing others patches for Qt OPC UA and MQTT also. These are his own contributions: https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z and these are his reviews: https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z Best regards, André From orgads at gmail.com Sun Nov 5 18:30:52 2017 From: orgads at gmail.com (Orgad Shaneh) Date: Sun, 5 Nov 2017 19:30:52 +0200 Subject: [Development] [Qt-creator] Nominating Lorenz Haas for approver In-Reply-To: References: Message-ID: On Sun, Nov 5, 2017 at 7:00 PM, André Hartmann wrote: > Hello all, > > I'd like to nominate Lorenz Haas for approver status. > > Lorenz has been contributing to Qt and Qt Creator since spring 2013. He > has provided some high quality patches to Creators C++ Editor and is the > author of Creators Beautifier plugin. > > He is actively reviewing patches in these areas, and recently started > contributing to and reviewing others patches for Qt OPC UA and MQTT also. > > These are his own contributions: > https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z > > and these are his reviews: > https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z +1. You said it all :) - Orgad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Maurice.Kalinowski at qt.io Mon Nov 6 08:46:23 2017 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Mon, 6 Nov 2017 07:46:23 +0000 Subject: [Development] Nominating Lorenz Haas for approver In-Reply-To: References: Message-ID: +1 Maurice > -----Original Message----- > From: Development [mailto:development- > bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of André > Hartmann > Sent: Sunday, November 5, 2017 6:01 PM > To: qt-creator at qt-project.org; development at qt-project.org > Cc: Lorenz Haas > Subject: [Development] Nominating Lorenz Haas for approver > > Hello all, > > I'd like to nominate Lorenz Haas for approver status. > > Lorenz has been contributing to Qt and Qt Creator since spring 2013. He has > provided some high quality patches to Creators C++ Editor and is the author > of Creators Beautifier plugin. > > He is actively reviewing patches in these areas, and recently started > contributing to and reviewing others patches for Qt OPC UA and MQTT also. > > These are his own contributions: > https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z > > and these are his reviews: > https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z > > Best regards, > André > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From nikolai.kosjar at qt.io Mon Nov 6 09:11:43 2017 From: nikolai.kosjar at qt.io (Nikolai Kosjar) Date: Mon, 6 Nov 2017 09:11:43 +0100 Subject: [Development] Nominating Lorenz Haas for approver In-Reply-To: References: Message-ID: <231bf772-c269-6533-c747-c07801c63415@qt.io> On 11/05/2017 06:00 PM, André Hartmann wrote: > Hello all, > > I'd like to nominate Lorenz Haas for approver status. > > Lorenz has been contributing to Qt and Qt Creator since spring 2013. He > has provided some high quality patches to Creators C++ Editor and is the > author of Creators Beautifier plugin. > > He is actively reviewing patches in these areas, and recently started > contributing to and reviewing others patches for Qt OPC UA and MQTT also. > > These are his own contributions: > https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z > > and these are his reviews: > https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z > > Best regards, > André > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development +1! Nikolai From Eike.Ziller at qt.io Mon Nov 6 09:28:10 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 6 Nov 2017 08:28:10 +0000 Subject: [Development] Nominating Lorenz Haas for approver In-Reply-To: <231bf772-c269-6533-c747-c07801c63415@qt.io> References: <231bf772-c269-6533-c747-c07801c63415@qt.io> Message-ID: +1 from me too :) Br, Eike > On 6. Nov 2017, at 09:11, Nikolai Kosjar wrote: > > On 11/05/2017 06:00 PM, André Hartmann wrote: >> Hello all, >> I'd like to nominate Lorenz Haas for approver status. >> Lorenz has been contributing to Qt and Qt Creator since spring 2013. He has provided some high quality patches to Creators C++ Editor and is the author of Creators Beautifier plugin. >> He is actively reviewing patches in these areas, and recently started contributing to and reviewing others patches for Qt OPC UA and MQTT also. >> These are his own contributions: >> https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z >> and these are his reviews: >> https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z >> Best regards, >> André >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > +1! > > Nikolai > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From frank.meerkoetter at basyskom.com Mon Nov 6 23:44:55 2017 From: frank.meerkoetter at basyskom.com (=?UTF-8?Q?Frank_Meerk=c3=b6tter?=) Date: Mon, 6 Nov 2017 23:44:55 +0100 Subject: [Development] Nominating Lorenz Haas for approver In-Reply-To: References: Message-ID: <23d45e8c-aacf-0156-928c-66d2c934d8f0@basyskom.com> +1 Kind Regards, Frank Am 05.11.2017 um 18:00 schrieb André Hartmann: > Hello all, > > I'd like to nominate Lorenz Haas for approver status. > > Lorenz has been contributing to Qt and Qt Creator since spring 2013. > He has provided some high quality patches to Creators C++ Editor and > is the author of Creators Beautifier plugin. > > He is actively reviewing patches in these areas, and recently started > contributing to and reviewing others patches for Qt OPC UA and MQTT also. > > These are his own contributions: > https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z > > and these are his reviews: > https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z > > Best regards, > André > _______________________________________________ > 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 david.schulz at qt.io Tue Nov 7 07:12:04 2017 From: david.schulz at qt.io (David Schulz) Date: Tue, 7 Nov 2017 07:12:04 +0100 Subject: [Development] Nominating Lorenz Haas for approver In-Reply-To: References: Message-ID: <704995e0-899a-0e3c-9ec2-438a4ba8a264@qt.io> +1 David On 05-Nov-17 18:00, André Hartmann wrote: > Hello all, > > I'd like to nominate Lorenz Haas for approver status. > > Lorenz has been contributing to Qt and Qt Creator since spring 2013. > He has provided some high quality patches to Creators C++ Editor and > is the author of Creators Beautifier plugin. > > He is actively reviewing patches in these areas, and recently started > contributing to and reviewing others patches for Qt OPC UA and MQTT also. > > These are his own contributions: > https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z > > and these are his reviews: > https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z > > Best regards, > André > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Nov 7 18:41:08 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 7 Nov 2017 17:41:08 +0000 Subject: [Development] HEADS-UP: Branching '5.10.0' from '5.10' started Message-ID: Hi all, We have soft branched '5.10.0' from '5.10'. Please start using '5.10.0' for new changes targeted to Qt 5.10.0 release. Final downmerge from '5.10' to '5.10.0' will happen Monday 13th November so there should be enough time to finalize ongoing changes in '5.10' and start using '5.10.0' for new ones. We are targeting to release Qt 5.10.0 rc immediately after branching is finalized (rc target 16th November) so please make sure all blockers are fixed immediately. Qt 5.10.0 blocker list here: https://bugreports.qt.io/issues/?filter=18957 We (release team) will start creating initial change files for Qt 5.10.0 now. So Maintainers: Please finalize those initial ones immediately when available. br, Jani Heikkinen Release Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Wed Nov 8 07:53:59 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 8 Nov 2017 06:53:59 +0000 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: References: <2827905.1UXfmysL1p@tjmaciei-mobl1> Message-ID: <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io> > On 18 Oct 2017, at 07:34, Jani Heikkinen wrote: > > Hi, > > We discussed about this last spring and then the decision was that 5.10 is too early but 5.11 might be possible. So can we get that done soon on dev branch? > > br, > Jani > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Thiago Macieira >> Sent: keskiviikko 18. lokakuuta 2017 7.51 >> To: development at qt-project.org >> Subject: [Development] Dropping of MSVC 2013 >> >> This came up again in QtCS and we decided that dropping it soon is probably a >> good idea, especially after Qt 5.9 became LTS. >> >> Did we decide on 5.10 or 5.11? >> >> Because one of my changes for 5.10 is currently failing on MSVC 2013 as >> designed. I need to refactor it for it to compile there. >> >> Do I need to implement it? Or shall we drop that compiler? >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From roland.m.winklmeier at gmail.com Wed Nov 8 10:06:51 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Wed, 8 Nov 2017 10:06:51 +0100 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: References: Message-ID: 2017-11-01 11:59 GMT+01:00 Jani Heikkinen : > > Qt 5.10 beta3 is out. Instructions how to get the release are here: > https://wiki.qt.io/How_to_get_snapshot_via_online_installer. > Hi Jani, first of all thanks a lot for this new way of shipping beta versions. It is so much nicer now to just run the maintenance tool via the online installer and install the new beta instead of having several single offline installer versions in parallel. One question: How likely are the chances that the prebuilt MSVC 32 bit packages will be built with MSVC 2017 instead of 2015? As far as I know, the v140 toolset in VS 2015 and the v141 toolset in VS 2017 are binary compatible. So if I'm not wrong, MSVC 2015 could also use the MSVC2017 binaries, no? Cheers R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Wed Nov 8 11:29:21 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 8 Nov 2017 10:29:21 +0000 Subject: [Development] MAINTAINERS, your action needed: Qt 5.9.3 change files Message-ID: Hi all, There is still quite many changes files under construction, see https://codereview.qt-project.org/#/q/message:%22file+for+Qt+5.9.3%22,n,z Please finalize ongoing ones now; we are targeting to get Qt 5.9.3 out during next week so we need to get final content in as soon as possible. +2 still missing: - qt/qtlocation - qt/qtscxml - qt/qtx11extras - qt/qt3d - qt/qtdoc - qt/qtwebsockets - qt/qtbase - qt/qtgraphicaleffects - qt/qtwebchannel - qt/qtwebview - qt/qtwebengine - qt/qtwayland - qt/qtpurchasing - qt/qtdeclarative br, Jani From edward.welbourne at qt.io Wed Nov 8 11:55:22 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Nov 2017 10:55:22 +0000 Subject: [Development] MAINTAINERS, your action needed: Qt 5.10 reviews (was: Qt 5.9.3 change files) In-Reply-To: References: Message-ID: Jani Heikkinen (8 November 2017 11:29) poked all about 5.9.3's change files. I note that many 5.10 API reviews [0] also remain unresolved - indeed, six appear to be untouched by anyone but me: * qt3d, qtx11extras, qtandroidextras, qtscxml, qtnetworkauth, qtremoteobjects Four have had a +1 before my last update, but no comment on changes since: * qtmultimedia, qtwayland, qtserialbus, qtwebengine Three haven't even had that, though they have been reviewed: * qtbase, qtdeclarative, qtlocation [0] https://codereview.qt-project.org/#/q/status:open+branch:5.10+topic:api-review,n,z There's random-number work ongoing on qtbase (in response to a -1), which I'll look into expediting; others could do with review ! I'll do updates on maintainer request, if you've got changes that make one relevant since October 10th, Eddy. From thiago.macieira at intel.com Wed Nov 8 16:24:18 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Nov 2017 07:24:18 -0800 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: References: Message-ID: <1740440.8pAugOfNqB@tjmaciei-mobl1> On Wednesday, 8 November 2017 01:06:51 PST Roland Winklmeier wrote: > One question: How likely are the chances that the prebuilt MSVC 32 bit > packages will be built with MSVC 2017 instead of 2015? As far as I know, > the v140 toolset in VS 2015 and the v141 toolset in VS 2017 are binary > compatible. So if I'm not wrong, MSVC 2015 could also use the MSVC2017 > binaries, no? In theory yes. In practice, we've found problems, so it didn't work. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oktal3700 at gmail.com Wed Nov 8 19:21:05 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Wed, 8 Nov 2017 18:21:05 +0000 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: <1740440.8pAugOfNqB@tjmaciei-mobl1> References: <1740440.8pAugOfNqB@tjmaciei-mobl1> Message-ID: On 8 November 2017 at 15:24, Thiago Macieira wrote: > On Wednesday, 8 November 2017 01:06:51 PST Roland Winklmeier wrote: > > One question: How likely are the chances that the prebuilt MSVC 32 bit > > packages will be built with MSVC 2017 instead of 2015? As far as I know, > > the v140 toolset in VS 2015 and the v141 toolset in VS 2017 are binary > > compatible. So if I'm not wrong, MSVC 2015 could also use the MSVC2017 > > binaries, no? > > In theory yes. In practice, we've found problems, so it didn't work. > Thiago, Could you please elaborate on the problems that were found? And why, in that case, the online installer offers builds of 5.9 and 5.10 for MSVC2015 x86 and x64, and for MSVC2017 x64 but _not_ x86? And is it possible to say which combinations do work together and which don't? Many thanks, Mat -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Wed Nov 8 19:57:32 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 8 Nov 2017 18:57:32 +0000 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io> References: <2827905.1UXfmysL1p@tjmaciei-mobl1> , <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io> Message-ID: >From: Shawn Rutledge >> On 18 Oct 2017, at 07:34, Jani Heikkinen wrote: >> We discussed about this last spring and then the decision was that 5.10 is too early but 5.11 might be possible. > So can we get that done soon on dev branch? Sorry, no. As mentioned during the contributor summit, this decision is tabled until we have the 5.10 download figures. -- Alex From thiago.macieira at intel.com Wed Nov 8 20:31:31 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 8 Nov 2017 11:31:31 -0800 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: References: <1740440.8pAugOfNqB@tjmaciei-mobl1> Message-ID: <9871777.a5QvBvqWlx@tjmaciei-mobl1> On Wednesday, 8 November 2017 10:21:05 PST Mat Sutcliffe wrote: > On 8 November 2017 at 15:24, Thiago Macieira > > wrote: > > On Wednesday, 8 November 2017 01:06:51 PST Roland Winklmeier wrote: > > > One question: How likely are the chances that the prebuilt MSVC 32 bit > > > packages will be built with MSVC 2017 instead of 2015? As far as I know, > > > the v140 toolset in VS 2015 and the v141 toolset in VS 2017 are binary > > > compatible. So if I'm not wrong, MSVC 2015 could also use the MSVC2017 > > > binaries, no? > > > > In theory yes. In practice, we've found problems, so it didn't work. > > Thiago, > > Could you please elaborate on the problems that were found? Sorry, I don't remember. Probably something related to the fact that constexpr is broken in MSVC 2015, so it's disabled, causing symbols to be missing. > And why, in > that case, the online installer offers builds of 5.9 and 5.10 for MSVC2015 > x86 and x64, and for MSVC2017 x64 but _not_ x86? And is it possible to say > which combinations do work together and which don't? They work together, but we didn't feel like we should spend CPU cycles to build 32-bit for the latest compiler. We should keep that only for the oldest supported compiler, in case people still need it. For new compilers, just use 64-bit or build from sources. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oktal3700 at gmail.com Wed Nov 8 21:54:16 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Wed, 8 Nov 2017 20:54:16 +0000 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: <9871777.a5QvBvqWlx@tjmaciei-mobl1> References: <1740440.8pAugOfNqB@tjmaciei-mobl1> <9871777.a5QvBvqWlx@tjmaciei-mobl1> Message-ID: On 8 November 2017 at 19:31, Thiago Macieira wrote: > On Wednesday, 8 November 2017 10:21:05 PST Mat Sutcliffe wrote: > > Could you please elaborate on the problems that were found? > > Sorry, I don't remember. Probably something related to the fact that > constexpr > is broken in MSVC 2015, so it's disabled, causing symbols to be missing. > OK, thanks anyway. I remember this discussion: http://lists.qt-project.org/pipermail/development/2017-April/029762.html That seemed to conclude that there should be no problem mixing 2015 with 2017. Was just wondering if there was anything else found in addition to that, like actual linker errors when it was tried. No worries if you don't remember. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Nov 8 22:20:12 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 8 Nov 2017 13:20:12 -0800 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: References: <9871777.a5QvBvqWlx@tjmaciei-mobl1> Message-ID: <2311084.FmDIrkUH7X@tjmaciei-mobl1> On Wednesday, 8 November 2017 12:54:16 PST Mat Sutcliffe wrote: > OK, thanks anyway. I remember this discussion: > http://lists.qt-project.org/pipermail/development/2017-April/029762.html > > That seemed to conclude that there should be no problem mixing 2015 with > 2017. Was just wondering if there was anything else found in addition to > that, like actual linker errors when it was tried. No worries if you don't > remember. There was another thread since then that discussed that. I remember the conclusion, but not the details. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Nov 8 22:27:06 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 09 Nov 2017 00:27:06 +0300 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: <2311084.FmDIrkUH7X@tjmaciei-mobl1> References: <9871777.a5QvBvqWlx@tjmaciei-mobl1> <2311084.FmDIrkUH7X@tjmaciei-mobl1> Message-ID: <409841510176426@web26o.yandex.ru> 09.11.2017, 00:20, "Thiago Macieira" : > On Wednesday, 8 November 2017 12:54:16 PST Mat Sutcliffe wrote: >>  OK, thanks anyway. I remember this discussion: >>  http://lists.qt-project.org/pipermail/development/2017-April/029762.html >> >>  That seemed to conclude that there should be no problem mixing 2015 with >>  2017. Was just wondering if there was anything else found in addition to >>  that, like actual linker errors when it was tried. No worries if you don't >>  remember. > > There was another thread since then that discussed that. I remember the > conclusion, but not the details. Here it is: http://lists.qt-project.org/pipermail/development/2017-June/030178.html > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oktal3700 at gmail.com Wed Nov 8 23:14:57 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Wed, 8 Nov 2017 22:14:57 +0000 Subject: [Development] Qt 5.10 beta 3 released In-Reply-To: <409841510176426@web26o.yandex.ru> References: <9871777.a5QvBvqWlx@tjmaciei-mobl1> <2311084.FmDIrkUH7X@tjmaciei-mobl1> <409841510176426@web26o.yandex.ru> Message-ID: On 8 November 2017 at 21:27, Konstantin Tokarev wrote: > 09.11.2017, 00:20, "Thiago Macieira" : > > There was another thread since then that discussed that. I remember the > > conclusion, but not the details. > > Here it is: > > http://lists.qt-project.org/pipermail/development/2017-June/030178.html That thread seems to be all about MSVC2013. Nothing there about binary compatibility between 2015 and 2017. I also found this that might refresh Thiago's memory, but it's still inconclusive by itself: http://lists.qt-project.org/pipermail/development/2017-June/030136.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Thu Nov 9 08:32:09 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 9 Nov 2017 07:32:09 +0000 Subject: [Development] HEADS-UP: Branching '5.9.3' completed In-Reply-To: References: Message-ID: Hi, Branching from '5.9' to '5.9.3' is now completed. From now on '5.9' is for changes targeting to '5.9.4' release. Plan is to get remaining Qt 5.9.3 changes files in '5.9.3' as well as possible fixes for open blockers & then get the Qt 5.9.3 release out. Target for the release is week 46 so please finalize ongoing changes files now. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Wednesday, November 1, 2017 3:09 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching '5.9.3' started Hi all, We have soft branched '5.9.3' from '5.9'. So please start using '5.9.3' for new changes targeted to Qt 5.9.3 release. Final downmerge from '5.9' to '5.9.3' will happen Wed 8th November so there should be enough time to finalize ongoing changes in '5.9' and start using '5.9.3' for new ones. We are targeting to release Qt 5.9.3 as soon as possible so please make sure all blockers are fixed immediately. Qt 5.9.3 blocker list here: https://bugreports.qt.io/issues/?filter=18995 We (release team) will start creating initial change files for Qt 5.9.3 now. So Maintainers: Please finalize those initial ones immediately when available. We need those now really soon to be able to proceed with final release. br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Jedrzej.Nowacki at qt.io Thu Nov 9 08:51:14 2017 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Thu, 9 Nov 2017 07:51:14 +0000 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: References: <2827905.1UXfmysL1p@tjmaciei-mobl1> , <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io>, Message-ID: Hi, We really should think about some more or less automatic policy about supported platforms. Discussing that on each release is not great nor for us, nor for our users. It takes time, to discuss it. I guess that from outside it is looking as a complete chaos, especially in context of LTS, some would expect that after LTS we drop support for old compilers/platforms, some would expect a deprecation warning first :-) Cheers, Jędrek ________________________________________ From: Development on behalf of Alex Blasche Sent: Wednesday, November 8, 2017 7:57:32 PM To: Shawn Rutledge; Jani Heikkinen Cc: Thiago Macieira; development at qt-project.org Subject: Re: [Development] Dropping of MSVC 2013 >From: Shawn Rutledge >> On 18 Oct 2017, at 07:34, Jani Heikkinen wrote: >> We discussed about this last spring and then the decision was that 5.10 is too early but 5.11 might be possible. > So can we get that done soon on dev branch? Sorry, no. As mentioned during the contributor summit, this decision is tabled until we have the 5.10 download figures. -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Thu Nov 9 20:10:23 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 9 Nov 2017 19:10:23 +0000 Subject: [Development] Why is year 7999 the end of time ? Message-ID: Investigating bug QTBUG-64401, I discover qdatetimeparser_p.h defining #define QDATETIMEEDIT_DATE_MAX QDate(7999, 12, 31) which dates back to the original import of qtbase by Nokia (albeit John Layt moved it from qdatetime_p.h in 2013). If anyone knows any cause or just impediment against changing that to year 9999, please speak up soon on http://bugreports.qt.io/browse/QTBUG-64401 or forever hold your peace, Eddy. From jani.heikkinen at qt.io Fri Nov 10 06:57:08 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 10 Nov 2017 05:57:08 +0000 Subject: [Development] MAINTAINERS, your action needed: Qt change files Message-ID: Hi all, We have still missing quite many +2 from 5.9.3 change files, see https://codereview.qt-project.org/#/q/message:%22file+for+Qt+5.9.3%22,n,z - qt/qtx11extras - qt/qt3d - qt/qtgraphicaleffects - qt/qtwebchannel - qt/qtwebview - qt/qtpurchasing - qt/qtscxml - qt/qtwebengine - qt/qtlocation - qt/qtdeclarative - qt/qtbase We really need these in now to be able to get Qt 5.9.3 out during next week! And there is already initial change files for Qt 5.10.0, see https://codereview.qt-project.org/#/q/message:%22changes+file+for+Qt+5.10.0%22,n,z Please finalize those now & get +2 as soon as possible; We should get all those in already for rc, which should be out next Thu! br. jani From rjvbertin at gmail.com Fri Nov 10 12:40:22 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 10 Nov 2017 12:40:22 +0100 Subject: [Development] Short/medium term evolution of the Assistant? In-Reply-To: References: Message-ID: <2663846.QvtqfQrgTb@bola> Andy Shaw wrote on 20171109::22:42:00 re: "[Qt bugreports] (QTBUG-59664) QSqlDatabasePrivate exploses open file limit and causes crash" Hi, I've been tinkering a bit with building the Assistant from the 5.9 branch head against my installed Qt 5.8.0, using a static lib build of the QtHelp library. That requires only a few trivial patches and the first impression is that the result is faster and more reliable in displaying the requested documentation when under remote control. I guess that'd be thanks to getting rid of CLucene. Is the Assistant likely to see significant evolution in the other branches in the near future that won't be backported to the 5.9 series? Context: using the Assistant as an external documentation browser, for instance for KDevelop (and providing instructions/packaging for an up-to-date version that's less closely tied to the installed Qt version). Thanks, René > Andy Shaw commented on QTBUG-59664 > >Re: QSqlDatabasePrivate exploses open file limit and causes crash >We don't use CLucene anymore in Qt 5.9 for Qt Assistant so things has changed in that regard anyway. I will have a further look to see if something can be done about the loading though, it might be more of a Qt Assistant problem as opposed to Qt SQL however because it is Qt Assistant which is keeping the databases in memory, and since they all operate on databases as a file then it will have a file descriptor for each of them. > Add Comment > >This message was sent by Atlassian JIRA (v7.3.4#73015-sha1:a262b34) > > From jani.heikkinen at qt.io Fri Nov 10 14:01:17 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 10 Nov 2017 13:01:17 +0000 Subject: [Development] Qt 5.10 beta 4 released In-Reply-To: References: Message-ID: Hi all, Qt 5.10 beta4 is out. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Current plan is to release Qt 5.10 rc next Thu as planned so please make sure all blockers from blocker list (https://bugreports.qt.io/issues/?filter=18957) is fixed immediately. Also make sure all open release blockers are really visible in the list... Diff to beta3 can be found as an attachment. br, Jani Heikkinen Release Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.10-beta3-delta-beta4-commits Type: application/octet-stream Size: 26965 bytes Desc: qt5.10-beta3-delta-beta4-commits URL: From announce at qt-project.org Fri Nov 10 14:02:11 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 10 Nov 2017 13:02:11 +0000 Subject: [Development] [Announce] Qt 5.10 beta 4 released In-Reply-To: References: Message-ID: Hi all, Qt 5.10 beta4 is out. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Current plan is to release Qt 5.10 rc next Thu as planned so please make sure all blockers from blocker list (https://bugreports.qt.io/issues/?filter=18957) is fixed immediately. Also make sure all open release blockers are really visible in the list... br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From me at the-compiler.org Fri Nov 10 14:27:05 2017 From: me at the-compiler.org (Florian Bruhin) Date: Fri, 10 Nov 2017 14:27:05 +0100 Subject: [Development] [Releasing] Qt 5.10 beta 4 released In-Reply-To: References: Message-ID: <20171110132705.nsfsixj3uqdeqcwv@hooch.localdomain> Hi, (not sure which ML this fits on, so I removed releasing@ - please Cc me on replies as I only get development@ as digest) On Fri, Nov 10, 2017 at 01:01:17PM +0000, Jani Heikkinen wrote: > Current plan is to release Qt 5.10 rc next Thu as planned so please make sure > all blockers from blocker list > (https://bugreports.qt.io/issues/?filter=18957) is fixed immediately. Also > make sure all open release blockers are really visible in the list... Would it be possible to add https://bugreports.qt.io/browse/QTBUG-63388 there? It's a regression from 5.9 and makes dozens of tests in my projects' testsuite fail, to the point that it's hard to check whether there are other unrelated failures. There's a fix at https://codereview.qt-project.org/#/c/208595/ which didn't make it through CI so far - I just want to make sure it doesn't miss the release ;) 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 jani.heikkinen at qt.io Sun Nov 12 18:09:50 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Sun, 12 Nov 2017 17:09:50 +0000 Subject: [Development] MAINTAINERS, your action needed: Qt change files In-Reply-To: References: Message-ID: Hi all, We are still missing +2 from 3 Qt 5.9.3 changes files: - https://codereview.qt-project.org/#/c/210114/ (qt/qtx11extras) - https://codereview.qt-project.org/#/c/210097/ (qt/qtwebchannel) - https://codereview.qt-project.org/#/c/210104/ (qt/qtbase) And in 5.10.0 situation is much worse, see https://codereview.qt-project.org/#/q/message:%22changes+file+for+Qt+5.10.0%22,n,z Missing: -qt/qtbase -qt/qtx11extras -qt/qtlocation -qt/qt3d -qt/qtvirtualkeyboard -qt/qtdoc -qt/qtwebsockets -qt/qtscxml -qt/qttools -qt/qtwebengine -qt/qtwebchannel -qt/qtsensors -qt/qtconnectivity -qt/qtwinextras -qt/qtpurchasing -qt/qtdeclarative br, Jani > -----Original Message----- > From: Jani Heikkinen > Sent: perjantai 10. marraskuuta 2017 7.57 > To: development at qt-project.org > Subject: MAINTAINERS, your action needed: Qt change files > > Hi all, > > We have still missing quite many +2 from 5.9.3 change files, see > https://codereview.qt-project.org/#/q/message:%22file+for+Qt+5.9.3%22,n,z > - qt/qtx11extras > - qt/qt3d > - qt/qtgraphicaleffects > - qt/qtwebchannel > - qt/qtwebview > - qt/qtpurchasing > - qt/qtscxml > - qt/qtwebengine > - qt/qtlocation > - qt/qtdeclarative > - qt/qtbase > > We really need these in now to be able to get Qt 5.9.3 out during next week! > > And there is already initial change files for Qt 5.10.0, see https://codereview.qt- > project.org/#/q/message:%22changes+file+for+Qt+5.10.0%22,n,z > Please finalize those now & get +2 as soon as possible; We should get all those > in already for rc, which should be out next Thu! > > br. > jani > From elderorb at gmail.com Mon Nov 13 15:55:58 2017 From: elderorb at gmail.com (Alexander Ivash) Date: Mon, 13 Nov 2017 17:55:58 +0300 Subject: [Development] QTBUG-64262 Message-ID: Is it possible to review patch inside QTBUG-64262 to hopefully make it part of Qt 5.10 ? Or it is too late? The change is pretty small and shouldn't take a lot of time for review. Regards, Alexander From thiago.macieira at intel.com Mon Nov 13 18:04:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 13 Nov 2017 09:04:16 -0800 Subject: [Development] QTBUG-64262 In-Reply-To: References: Message-ID: <2852631.6OQZq7iR7L@tjmaciei-mobl1> On segunda-feira, 13 de novembro de 2017 06:55:58 PST Alexander Ivash wrote: > Is it possible to review patch inside QTBUG-64262 to hopefully make it > part of Qt 5.10 ? Or it is too late? The change is pretty small and > shouldn't take a lot of time for review. Hello Alexander There's no patch in that bug report. I removed them last week because they were too big to be accepted through the bug reporting mechanism. Please submit the patches via the patch review system. Instructions can be found at http://wiki.qt.io/Qt_Contribution_Guidelines It's not too late for 5.10, but may miss the 5.10.0 release if the patches are not critical. If that happens, they'd come in for 5.10.1 instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 14 09:17:59 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Nov 2017 00:17:59 -0800 Subject: [Development] Any supported platforms not tested in CI? In-Reply-To: <8082621.B2sQFEfeRL@tjmaciei-mobl1> References: <8082621.B2sQFEfeRL@tjmaciei-mobl1> Message-ID: <2088986.jT7Hf5ITCM@tjmaciei-mobl1> On quarta-feira, 11 de outubro de 2017 04:23:58 PST Thiago Macieira wrote: > Are there any supported platforms that we do not test in the CI? Probably > INTEGRITY? By the way, the answer to this question was YES. Using did work on all compilers, but a full out-of-cycle build of qt5.git turned up at least two compilers that weren't tested in the main cycle and balked at an implementation detail. The fix has just gone in to QBasicMutex. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Tue Nov 14 09:28:27 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 14 Nov 2017 08:28:27 +0000 Subject: [Development] Any supported platforms not tested in CI? In-Reply-To: <2088986.jT7Hf5ITCM@tjmaciei-mobl1> References: <8082621.B2sQFEfeRL@tjmaciei-mobl1> <2088986.jT7Hf5ITCM@tjmaciei-mobl1> Message-ID: For some platforms we test compilation only. Also some tests/combinations are only run with full qt5.git integration. More information in wiki: https://wiki.qt.io/Qt_5.9_Tools_and_Versions Yours, Tuukka On 14/11/2017, 10.17, "Development on behalf of Thiago Macieira" wrote: On quarta-feira, 11 de outubro de 2017 04:23:58 PST Thiago Macieira wrote: > Are there any supported platforms that we do not test in the CI? Probably > INTEGRITY? By the way, the answer to this question was YES. Using did work on all compilers, but a full out-of-cycle build of qt5.git turned up at least two compilers that weren't tested in the main cycle and balked at an implementation detail. The fix has just gone in to QBasicMutex. -- 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 annulen at yandex.ru Tue Nov 14 09:58:24 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Nov 2017 11:58:24 +0300 Subject: [Development] Any supported platforms not tested in CI? In-Reply-To: References: <8082621.B2sQFEfeRL@tjmaciei-mobl1> <2088986.jT7Hf5ITCM@tjmaciei-mobl1> Message-ID: <468931510649904@web22o.yandex.ru> 14.11.2017, 11:28, "Tuukka Turunen" : > For some platforms we test compilation only. Also some tests/combinations are only run with full qt5.git integration. > > More information in wiki: https://wiki.qt.io/Qt_5.9_Tools_and_Versions See also coin/platform_configs directory in qt5.git > > Yours, > >         Tuukka > > On 14/11/2017, 10.17, "Development on behalf of Thiago Macieira" wrote: > >     On quarta-feira, 11 de outubro de 2017 04:23:58 PST Thiago Macieira wrote: >     > Are there any supported platforms that we do not test in the CI? Probably >     > INTEGRITY? > >     By the way, the answer to this question was YES. > >     Using did work on all compilers, but a full out-of-cycle build of >     qt5.git turned up at least two compilers that weren't tested in the main cycle >     and balked at an implementation detail. > >     The fix has just gone in to QBasicMutex. > >     -- >     Thiago Macieira - thiago.macieira (AT) intel.com >       Software Architect - Intel Open Source Technology Center > >     _______________________________________________ >     Development mailing list >     Development at qt-project.org >     http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Tue Nov 14 10:00:22 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Nov 2017 12:00:22 +0300 Subject: [Development] Any supported platforms not tested in CI? In-Reply-To: References: <8082621.B2sQFEfeRL@tjmaciei-mobl1> <2088986.jT7Hf5ITCM@tjmaciei-mobl1> Message-ID: <483071510650022@web22o.yandex.ru> 14.11.2017, 11:28, "Tuukka Turunen" : > For some platforms we test compilation only. Also some tests/combinations are only run with full qt5.git integration. > > More information in wiki: https://wiki.qt.io/Qt_5.9_Tools_and_Versions See also coin/platform_configs directory in qt5.git > > Yours, > >         Tuukka > > On 14/11/2017, 10.17, "Development on behalf of Thiago Macieira" wrote: > >     On quarta-feira, 11 de outubro de 2017 04:23:58 PST Thiago Macieira wrote: >     > Are there any supported platforms that we do not test in the CI? Probably >     > INTEGRITY? > >     By the way, the answer to this question was YES. > >     Using did work on all compilers, but a full out-of-cycle build of >     qt5.git turned up at least two compilers that weren't tested in the main cycle >     and balked at an implementation detail. > >     The fix has just gone in to QBasicMutex. > >     -- >     Thiago Macieira - thiago.macieira (AT) intel.com >       Software Architect - Intel Open Source Technology Center > >     _______________________________________________ >     Development mailing list >     Development at qt-project.org >     http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From kfunk at kde.org Wed Nov 15 17:39:18 2017 From: kfunk at kde.org (Kevin Funk) Date: Wed, 15 Nov 2017 17:39:18 +0100 Subject: [Development] Qt Coding style and C++11 In-Reply-To: <9305521.5Q9SZpxIgE@kerberos> References: <9305521.5Q9SZpxIgE@kerberos> Message-ID: <1584471.Zmk59aljtW@kerberos> On Monday, 18 September 2017 10:03:40 CET Kevin Funk wrote: > On Monday, 18 September 2017 09:38:53 CEST Ville Voutilainen wrote: > > On 18 September 2017 at 10:36, Lars Knoll wrote: > > >>> But for new plugins that target a known platform that supports c++11, > > >>> they can most likely use new conventions. Unless someone can come up > > >>> with technical reasons the new c++11 member initialization is better > > >>> than what is there now, I’d rather keep it the same as it is now.>> > > >> > > >> If you have more than one constructor that set a member to the same > > >> value, it's arguably simpler and less error-prone > > >> to use a member initializer. > > > > > > I also think that we should be using member initialisers when writing > > > new > > > code (or when refactoring existing code). But doing a global > > > search/replace of existing code might lead to subtle errors as it's easy > > > to miss the rare case when different constructors initialise members > > > differently. > > > > Note that if you have both a member initializer and a ctor-initializer > > (the colon-list after the constructor signature, X() : foo(a), > > bar(b)), the ctor-initializer > > is used. It is non-trivial to remove ctor-initializers and replace > > them with member-initializers, I don't know whether the clang-tools > > can do that. > > I have to take back my claim that clang-tidy can automatically transform > initialization via initializer list to initialization via in-class field > initializers. > > I just remembered that this cppcoreguidelines-pro-type-member-init checker > just *adds* in-class field initializers for fields which haven't been > initialized altogether *before*. It does nothing if the initializer list > initializes all fields already. So in order to actually port all uses of > initializer lists to something more modern, clang-tidy would need to be > extended. > > So I guess the discussion whether to a global search/replace for this > particular C++11 feature is moot for now, since doing this port on all of Qt > is infeasible without proper tooling. Heya, And I have to revive this thread again. Actually the clang-tidy check to do this kind of transformation indeed exists already (since Clang 5.0 release): https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-default-member-init.html Just for your information. Regards, Kevin > Regards, > Kevin > > _______________________________________________ > > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: This is a digitally signed message part. URL: From andre.hartmann at iseg-hv.de Thu Nov 16 08:29:11 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 16 Nov 2017 08:29:11 +0100 Subject: [Development] Qt Coding style and C++11 In-Reply-To: <1584471.Zmk59aljtW@kerberos> References: <9305521.5Q9SZpxIgE@kerberos> <1584471.Zmk59aljtW@kerberos> Message-ID: <4cf8b0be-ea91-f4db-1cee-ad31a07105c9@iseg-hv.de> Hi Kevin, Am 15.11.2017 um 17:39 schrieb Kevin Funk: > On Monday, 18 September 2017 10:03:40 CET Kevin Funk wrote: >> On Monday, 18 September 2017 09:38:53 CEST Ville Voutilainen wrote: >>> On 18 September 2017 at 10:36, Lars Knoll wrote: >>>>>> But for new plugins that target a known platform that supports c++11, >>>>>> they can most likely use new conventions. Unless someone can come up >>>>>> with technical reasons the new c++11 member initialization is better >>>>>> than what is there now, I’d rather keep it the same as it is now.>> >>>>> >>>>> If you have more than one constructor that set a member to the same >>>>> value, it's arguably simpler and less error-prone >>>>> to use a member initializer. >>>> >>>> I also think that we should be using member initialisers when writing >>>> new >>>> code (or when refactoring existing code). But doing a global >>>> search/replace of existing code might lead to subtle errors as it's easy >>>> to miss the rare case when different constructors initialise members >>>> differently. >>> >>> Note that if you have both a member initializer and a ctor-initializer >>> (the colon-list after the constructor signature, X() : foo(a), >>> bar(b)), the ctor-initializer >>> is used. It is non-trivial to remove ctor-initializers and replace >>> them with member-initializers, I don't know whether the clang-tools >>> can do that. >> >> I have to take back my claim that clang-tidy can automatically transform >> initialization via initializer list to initialization via in-class field >> initializers. >> >> I just remembered that this cppcoreguidelines-pro-type-member-init checker >> just *adds* in-class field initializers for fields which haven't been >> initialized altogether *before*. It does nothing if the initializer list >> initializes all fields already. So in order to actually port all uses of >> initializer lists to something more modern, clang-tidy would need to be >> extended. >> >> So I guess the discussion whether to a global search/replace for this >> particular C++11 feature is moot for now, since doing this port on all of Qt >> is infeasible without proper tooling. > > Heya, > > And I have to revive this thread again. > > Actually the clang-tidy check to do this kind of transformation indeed exists > already (since Clang 5.0 release): > https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-default-member-init.html Thanks for the hint. That reminds me, that the wiki page [1] for C++11 stil states: "Note: This section is not an accepted convention yet. This section serves as baseline for further discussions." Regards, André [1] https://wiki.qt.io/Coding_Conventions > > Just for your information. > > Regards, > Kevin > >> Regards, >> Kevin >> >> _______________________________________________ >> >>> 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 > -- Best regards / Mit freundlichen Grüßen André Hartmann, Dipl.-Ing. (FH) Software Project Manager iseg Spezialelektronik GmbH | phone: ++49 (0)351 26996-43 Bautzner Landstr. 23 | fax: ++49 (0)351 26996-21 D-01454 Radeberg / Rossendorf | web: www.iseg-hv.com Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID: DE812508942 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From jani.heikkinen at qt.io Fri Nov 17 12:02:44 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 17 Nov 2017 11:02:44 +0000 Subject: [Development] MAINTAINERS, your action needed: Qt change files In-Reply-To: References: , Message-ID: Hi, Quite many 5.10 changes file still under construction, see https://codereview.qt-project.org/#/q/message:%22changes+file+for+Qt+5.10.0%22,n,z Please finalize those as soon as possible; we need those before we can create RC packages. br, Jani And I know, branching is still ongoing so I understand that we might need to wait that until finalize change files in some modules. But most of modules that shouldn't needed & we can finalize those already now. We are targeting to finalize branching immediately after qt5.git merge from 5.9 -> 5.10 is finalized (https://codereview.qt-project.org/#/c/211681/) ________________________________________ From: Jani Heikkinen Sent: Sunday, November 12, 2017 7:09 PM To: development at qt-project.org Subject: RE: MAINTAINERS, your action needed: Qt change files Hi all, We are still missing +2 from 3 Qt 5.9.3 changes files: - https://codereview.qt-project.org/#/c/210114/ (qt/qtx11extras) - https://codereview.qt-project.org/#/c/210097/ (qt/qtwebchannel) - https://codereview.qt-project.org/#/c/210104/ (qt/qtbase) And in 5.10.0 situation is much worse, see https://codereview.qt-project.org/#/q/message:%22changes+file+for+Qt+5.10.0%22,n,z Missing: -qt/qtbase -qt/qtx11extras -qt/qtlocation -qt/qt3d -qt/qtvirtualkeyboard -qt/qtdoc -qt/qtwebsockets -qt/qtscxml -qt/qttools -qt/qtwebengine -qt/qtwebchannel -qt/qtsensors -qt/qtconnectivity -qt/qtwinextras -qt/qtpurchasing -qt/qtdeclarative br, Jani > -----Original Message----- > From: Jani Heikkinen > Sent: perjantai 10. marraskuuta 2017 7.57 > To: development at qt-project.org > Subject: MAINTAINERS, your action needed: Qt change files > > Hi all, > > We have still missing quite many +2 from 5.9.3 change files, see > https://codereview.qt-project.org/#/q/message:%22file+for+Qt+5.9.3%22,n,z > - qt/qtx11extras > - qt/qt3d > - qt/qtgraphicaleffects > - qt/qtwebchannel > - qt/qtwebview > - qt/qtpurchasing > - qt/qtscxml > - qt/qtwebengine > - qt/qtlocation > - qt/qtdeclarative > - qt/qtbase > > We really need these in now to be able to get Qt 5.9.3 out during next week! > > And there is already initial change files for Qt 5.10.0, see https://codereview.qt- > project.org/#/q/message:%22changes+file+for+Qt+5.10.0%22,n,z > Please finalize those now & get +2 as soon as possible; We should get all those > in already for rc, which should be out next Thu! > > br. > jani > From thiago.macieira at intel.com Fri Nov 17 17:03:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Nov 2017 08:03:42 -0800 Subject: [Development] MAINTAINERS, your action needed: Qt change files In-Reply-To: References: Message-ID: <2284835.XRHNYkSjLC@tjmaciei-mobl1> On sexta-feira, 17 de novembro de 2017 03:02:44 PST Jani Heikkinen wrote: > Hi, > > Quite many 5.10 changes file still under construction, see > https://codereview.qt-project.org/#/q/message:%22changes+file+for+Qt+5.10.0 > %22,n,z > > Please finalize those as soon as possible; we need those before we can > create RC packages. I'll edit the qtbase one today. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Nov 20 14:03:00 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 20 Nov 2017 13:03:00 +0000 Subject: [Development] HEADS-UP: Branching '5.10.0' from '5.10' completed In-Reply-To: References: Message-ID: Hi all, We have finally completed branching from '5.10' -> '5.10.0'. So from now on all changes targeted to Qt 5.10.0 release must be done in '5.10.0' and '5.10' is for Qt 5.10.1. And please remember, no any nice-to-haves in '5.10.0' anymore. Plan is to create Qt 5.10 RC as soon as possible, after a) merge from 5.9.3 is completed b) all changes files are in and c) every blocker from blocker list (https://bugreports.qt.io/issues/?filter=18957) have a fix in '5.10.0'. br, Jani ________________________________________ From: Jani Heikkinen Sent: Tuesday, November 7, 2017 7:41 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: HEADS-UP: Branching '5.10.0' from '5.10' started Hi all, We have soft branched '5.10.0' from '5.10'. Please start using '5.10.0' for new changes targeted to Qt 5.10.0 release. Final downmerge from '5.10' to '5.10.0' will happen Monday 13th November so there should be enough time to finalize ongoing changes in '5.10' and start using '5.10.0' for new ones. We are targeting to release Qt 5.10.0 rc immediately after branching is finalized (rc target 16th November) so please make sure all blockers are fixed immediately. Qt 5.10.0 blocker list here: https://bugreports.qt.io/issues/?filter=18957 We (release team) will start creating initial change files for Qt 5.10.0 now. So Maintainers: Please finalize those initial ones immediately when available. br, Jani Heikkinen Release Manager From jcldc13 at gmail.com Mon Nov 20 23:01:25 2017 From: jcldc13 at gmail.com (GMAIL) Date: Mon, 20 Nov 2017 23:01:25 +0100 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) Message-ID: Hi, since *Qt 5.6 until latest QT 5.9* and maybe above, the *advanced printing dialog box*, which give control to remote printers connected by *CUPS*, is *missing* to any QT5 applications (and in the same time to KDE/Kf5 apps). This bug has been reported on QT ( see https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a year and half now, the bug status is still *reported* and the resolution *unknown*. I am sorry to post this information here, but we are many users affected by this bug and we are desperate because we don't have any feed back from QT. Is there anybody working on it ? Is anyone here, from QT, who could give any information ? Thanks a lot in advance for your help. Jean-Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.yadrov at qt.io Mon Nov 20 23:07:44 2017 From: oleg.yadrov at qt.io (Oleg Yadrov) Date: Mon, 20 Nov 2017 22:07:44 +0000 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: References: Message-ID: <6FF74E1C-33CD-48F1-97E0-1633D42FDA95@qt.io> I have nothing to say in regards to the issue, but the framework you're talking about is Qt, not QT. Thank you, Oleg On Nov 20, 2017, at 5:01 PM, GMAIL > wrote: Hi, since Qt 5.6 until latest QT 5.9 and maybe above, the advanced printing dialog box, which give control to remote printers connected by CUPS, is missing to any QT5 applications (and in the same time to KDE/Kf5 apps). This bug has been reported on QT ( see https://bugreports.qt.io/browse/QTBUG-54464) on June 2016. Almost a year and half now, the bug status is still reported and the resolution unknown. I am sorry to post this information here, but we are many users affected by this bug and we are desperate because we don't have any feed back from QT. Is there anybody working on it ? Is anyone here, from QT, who could give any information ? Thanks a lot in advance for your help. Jean-Charles _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Nov 20 23:45:18 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Nov 2017 14:45:18 -0800 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: References: Message-ID: <2061336.GRC7mtx1fp@tjmaciei-mobl1> On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: > This bug has been reported on QT ( see > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a > year and half now, the bug status is still *reported* and the resolution > *unknown*. > > I am sorry to post this information here, but we are many users affected > by this bug and we are desperate because we don't have any feed back > from QT. Is there anybody working on it ? No, there is not. The module is currently orphan, with no maintainer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andy.shaw at qt.io Tue Nov 21 06:19:04 2017 From: andy.shaw at qt.io (Andy Shaw) Date: Tue, 21 Nov 2017 05:19:04 +0000 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: <2061336.GRC7mtx1fp@tjmaciei-mobl1> References: <2061336.GRC7mtx1fp@tjmaciei-mobl1> Message-ID: I have been doing some work on the printing side of things lately, since this is quite a well voted for feature I’ll try and find time to investigate this further (assuming no one else beats me to it) over the next week or so. Andy Development på vegne av Thiago Macieira skrev følgende den 20.11.2017, 23.45: On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: > This bug has been reported on QT ( see > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a > year and half now, the bug status is still *reported* and the resolution > *unknown*. > > I am sorry to post this information here, but we are many users affected > by this bug and we are desperate because we don't have any feed back > from QT. Is there anybody working on it ? No, there is not. The module is currently orphan, with no maintainer. -- 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 jcldc13 at gmail.com Tue Nov 21 10:27:45 2017 From: jcldc13 at gmail.com (dark charlot) Date: Tue, 21 Nov 2017 10:27:45 +0100 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: References: <2061336.GRC7mtx1fp@tjmaciei-mobl1> Message-ID: <989d37db-10ed-0fe0-331e-ad10209e99b5@gmail.com> On 11/21/2017 06:19 AM, Andy Shaw wrote: > I have been doing some work on the printing side of things lately, since this is quite a well voted for feature I’ll try and find time to investigate this further (assuming no one else beats me to it) over the next week or so. > > Andy >   Thank you so much Andy to take care of this issue ! Let me know if I can help for testing stuffs.   Jean-Charles From mariofutire at googlemail.com Tue Nov 21 21:54:47 2017 From: mariofutire at googlemail.com (andrea) Date: Tue, 21 Nov 2017 20:54:47 +0000 Subject: [Development] qt_message_fatal() in Linux Message-ID: I've had a crash today because of a mismatch between .so versions. Solution was easy https://bugzilla.redhat.com/show_bug.cgi?id=1515922 but in doing so I realised that in Linux the function static void qt_message_fatal(QtMsgType, const QMessageLogContext &context, const QString &message) in qlogging.cpp:1686 is just a call to std::abort(). In VisualStudio in Debug it prints the error message. Since we are about to call abort, why not just print the message to stderr in all cases? It makes a big difference if the crash says something about the reason behind it. Especially for people without a debugger. Andrea From thiago.macieira at intel.com Tue Nov 21 22:42:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Nov 2017 13:42:50 -0800 Subject: [Development] qt_message_fatal() in Linux In-Reply-To: <2892150.r78LEJu5gM@tjmaciei-mobl1> References: <2892150.r78LEJu5gM@tjmaciei-mobl1> Message-ID: <3715744.a39r8Be1iB@tjmaciei-mobl1> On terça-feira, 21 de novembro de 2017 13:42:25 PST Thiago Macieira wrote: > On terça-feira, 21 de novembro de 2017 12:54:47 PST andrea via Development > > wrote: > > but in doing so I realised that in Linux the function > > > > static void qt_message_fatal(QtMsgType, const QMessageLogContext &context, > > const QString &message) > > > > in qlogging.cpp:1686 is just a call to > > > > std::abort(). > > > > In VisualStudio in Debug it prints the error message. > > > > Since we are about to call abort, why not just print the message to stderr > > in all cases? > > What message? > > > It makes a big difference if the crash says something about the reason > > behind it. Especially for people without a debugger. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mariofutire at googlemail.com Tue Nov 21 22:52:00 2017 From: mariofutire at googlemail.com (andrea) Date: Tue, 21 Nov 2017 21:52:00 +0000 Subject: [Development] qt_message_fatal() in Linux In-Reply-To: <3715744.a39r8Be1iB@tjmaciei-mobl1> References: <2892150.r78LEJu5gM@tjmaciei-mobl1> <3715744.a39r8Be1iB@tjmaciei-mobl1> Message-ID: On 21/11/17 21:42, Thiago Macieira wrote: > On terça-feira, 21 de novembro de 2017 13:42:25 PST Thiago Macieira wrote: >> On terça-feira, 21 de novembro de 2017 12:54:47 PST andrea via Development >> >> wrote: >>> but in doing so I realised that in Linux the function >>> >>> static void qt_message_fatal(QtMsgType, const QMessageLogContext &context, >>> const QString &message) >>> >>> in qlogging.cpp:1686 is just a call to >>> >>> std::abort(). >>> >>> In VisualStudio in Debug it prints the error message. >>> >>> Since we are about to call abort, why not just print the message to stderr >>> in all cases? >> >> What message? static void qt_message_fatal(QtMsgType, const QMessageLogContext &context, const QString &message) the last argument is a QString, the message. for an example see here qobject.cpp:214 if (Q_UNLIKELY(version != QObjectPrivateVersion)) qFatal("Cannot mix incompatible Qt library (version 0x%x) with this library (version 0x%x)", version, QObjectPrivateVersion); This eventually calls qt_message_fatal() with a message like the string above, but it is discarded. Andrea From thiago.macieira at intel.com Tue Nov 21 22:55:56 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Nov 2017 13:55:56 -0800 Subject: [Development] qt_message_fatal() in Linux In-Reply-To: References: <3715744.a39r8Be1iB@tjmaciei-mobl1> Message-ID: <12190389.QeLzz60EeJ@tjmaciei-mobl1> On terça-feira, 21 de novembro de 2017 13:52:00 PST andrea via Development wrote: > if (Q_UNLIKELY(version != QObjectPrivateVersion)) > qFatal("Cannot mix incompatible Qt library (version 0x%x) with this > library (version 0x%x)", version, QObjectPrivateVersion); > > This eventually calls qt_message_fatal() with a message like the string > above, but it is discarded. No, it isn't. $ cat main.cpp int main() { qFatal("Goodbye World"); } $ make $ ./a.out $ ./qtbug64640 [ 21117.597] (26976 26976)(main): Goodbye World [1] 26976 abort (core dumped) ./a.out $ coredumpctl gdb 26976 [...] (gdb) bt #0 0x00007f2e92d190d0 in raise () from /lib64/libc.so.6 #1 0x00007f2e92d1a6b1 in abort () from /lib64/libc.so.6 #2 0x00007f2e93158e7b in qt_message_fatal (context=..., message=...) at /home/tjmaciei/src/qt/qt5/qtbase/src/corelib/global/qlogging.cpp:1709 #3 0x00007f2e9315506e in QMessageLogger::fatal (this=0x7ffe89097790, msg=0x40085b "Goodbye World") at /home/tjmaciei/src/qt/qt5/qtbase/src/corelib/global/qlogging.cpp:817 #4 0x000000000040071d in main (argc=1, argv=0x7ffe89097898) at main.cpp:26 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Nov 22 12:57:01 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 22 Nov 2017 11:57:01 +0000 Subject: [Development] Qt 5.9.3 released Message-ID: Hi all, We have released Qt 5.9.3 today, see http://blog.qt.io/blog/2017/11/22/qt-5-9-3-released/ Big thanks for everyone involved! br, Jani Heikkinen Release Manager From announce at qt-project.org Wed Nov 22 13:24:03 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 22 Nov 2017 12:24:03 +0000 Subject: [Development] [Announce] Qt Creator 4.5 RC released Message-ID: We are happy to announce the release of Qt Creator 4.5 RC! https://blog.qt.io/blog/2017/11/22/qt-creator-4-5-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 ari.salmi at snowgrains.com Wed Nov 22 14:23:07 2017 From: ari.salmi at snowgrains.com (Ari Salmi) Date: Wed, 22 Nov 2017 15:23:07 +0200 Subject: [Development] CMake & iOS Message-ID: Hi, Have anyone else tried out creating cmake project for iOS (with Qt 5.9.x and today announced Qt 5.9.3)? I have - also today with Qt 5.9.3 1. Create new application with Qt Creator with cmake 2. Select iOS as target 3. Compile —> it won’t compile for iOS (will do with macOS). 623 x warning coming out from each Qt lib: :-1: warning: URGENT: building for OSX, but linking in object file (.../Qt/5.9.3/ios/lib/libQt5Core_debug.a(qresource.o)) built for iOS. Note: This will be an error in the future. And failing in linking phase. That means the default cmake config for iOS is pointing macOS toolchain? Br, Ari Ari Salmi SnowGrains www.snowgrains.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sschilz at pasco.com Wed Nov 22 17:32:47 2017 From: sschilz at pasco.com (Steve Schilz) Date: Wed, 22 Nov 2017 16:32:47 +0000 Subject: [Development] Development Digest, Vol 74, Issue 21 In-Reply-To: References: Message-ID: Re: QT printing via CUPS (advanced printing dialog box missing) Andy - There was some conversation about that a while back: http://permalink.gmane.org/gmane.comp.lib.qt.user/18649 Maybe some of the links there are helpful? Steve Schilz PASCO scientific think science >> Message: 1 >> Date: Tue, 21 Nov 2017 05:19:04 +0000 >> From: Andy Shaw >> To: "development at qt-project.org" >> Subject: Re: [Development] QT printing via CUPS (advanced printing >> dalog box missing) >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >> >> I have been doing some work on the printing side of things lately, since this is quite a well voted for feature I?ll try and find time to investigate this further (assuming no one else beats me to it) over the next week or so. >> >> Andy From mariofutire at googlemail.com Wed Nov 22 21:59:28 2017 From: mariofutire at googlemail.com (andrea) Date: Wed, 22 Nov 2017 20:59:28 +0000 Subject: [Development] qt_message_fatal() in Linux In-Reply-To: <12190389.QeLzz60EeJ@tjmaciei-mobl1> References: <3715744.a39r8Be1iB@tjmaciei-mobl1> <12190389.QeLzz60EeJ@tjmaciei-mobl1> Message-ID: On 21/11/17 21:55, Thiago Macieira wrote: > On terça-feira, 21 de novembro de 2017 13:52:00 PST andrea via Development > wrote: >> if (Q_UNLIKELY(version != QObjectPrivateVersion)) >> qFatal("Cannot mix incompatible Qt library (version 0x%x) with this >> library (version 0x%x)", version, QObjectPrivateVersion); >> >> This eventually calls qt_message_fatal() with a message like the string >> above, but it is discarded. > > No, it isn't. > You are indeed right Cannot mix incompatible Qt library (version 0x50900) with this library (version 0x50902) Aborted (core dumped) I got so focused on the "core dumped" message, that I missed the rest... Cheers From alexander.blasche at qt.io Thu Nov 23 07:35:00 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 23 Nov 2017 06:35:00 +0000 Subject: [Development] Nominating Christoph Schleifenbaum for Approver In-Reply-To: <020b54da456dd56e2e43426b9fb666cf@kdab.com> References: <020b54da456dd56e2e43426b9fb666cf@kdab.com> Message-ID: Congratulations to Christoph. Approver rights have been granted. -- Alex ________________________________________ From: Development on behalf of Sergio Martins Sent: Thursday, 2 November 2017 1:46:24 PM To: development at qt-project.org Subject: [Development] Nominating Christoph Schleifenbaum for Approver Hi, I'd like to nominate Christoph Schleifenbaum for Approver. He's been with KDAB for 12 years and has done dozens of fixes for cocoa, widgets and item views. He' also one of the developers who worked on the Qt3DStudio port to Qt very recently. https://codereview.qt-project.org/#/q/owner:%22Christoph+Schleifenbaum%22,n,z 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 jani.heikkinen at qt.io Thu Nov 23 11:17:36 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 23 Nov 2017 10:17:36 +0000 Subject: [Development] CMake & iOS In-Reply-To: References: Message-ID: Hi Ari, Thanks for your feedback. Please write a bug report in the Jira about this issue br, Jani ________________________________________ From: Development on behalf of Ari Salmi Sent: Wednesday, November 22, 2017 3:23 PM To: development at qt-project.org Subject: [Development] CMake & iOS Hi, Have anyone else tried out creating cmake project for iOS (with Qt 5.9.x and today announced Qt 5.9.3)? I have - also today with Qt 5.9.3 1. Create new application with Qt Creator with cmake 2. Select iOS as target 3. Compile —> it won’t compile for iOS (will do with macOS). 623 x warning coming out from each Qt lib: :-1: warning: URGENT: building for OSX, but linking in object file (.../Qt/5.9.3/ios/lib/libQt5Core_debug.a(qresource.o)) built for iOS. Note: This will be an error in the future. And failing in linking phase. That means the default cmake config for iOS is pointing macOS toolchain? Br, Ari Ari Salmi SnowGrains www.snowgrains.com From ari.salmi at snowgrains.com Thu Nov 23 11:44:39 2017 From: ari.salmi at snowgrains.com (Ari Salmi) Date: Thu, 23 Nov 2017 12:44:39 +0200 Subject: [Development] CMake & iOS In-Reply-To: References: Message-ID: <01807554-A202-4F94-AA72-F1654010E89E@snowgrains.com> Hi, Done. https://bugreports.qt.io/browse/QTBUG-64711 I used Build System as component as did not find any cmake related - please move to right component. Thanks. Br, Ari > On 23 Nov 2017, at 12.17, Jani Heikkinen wrote: > > Hi Ari, > > Thanks for your feedback. Please write a bug report in the Jira about this issue > > br, > Jani > ________________________________________ > From: Development on behalf of Ari Salmi > Sent: Wednesday, November 22, 2017 3:23 PM > To: development at qt-project.org > Subject: [Development] CMake & iOS > > Hi, > > Have anyone else tried out creating cmake project for iOS (with Qt 5.9.x and today announced Qt 5.9.3)? > > I have - also today with Qt 5.9.3 > 1. Create new application with Qt Creator with cmake > 2. Select iOS as target > 3. Compile > > —> it won’t compile for iOS (will do with macOS). > > 623 x warning coming out from each Qt lib: > :-1: warning: URGENT: building for OSX, but linking in object file (.../Qt/5.9.3/ios/lib/libQt5Core_debug.a(qresource.o)) built for iOS. Note: This will be an error in the future. > > And failing in linking phase. > That means the default cmake config for iOS is pointing macOS toolchain? > > Br, Ari > > Ari Salmi > SnowGrains > www.snowgrains.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: From Marco.Bubke at qt.io Thu Nov 23 12:52:42 2017 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 23 Nov 2017 11:52:42 +0000 Subject: [Development] Nominating Ivan Donchevskii for approver Message-ID: I'd like to nominate Ivan Donchevskii for Approver. He is working since spring at the C++ support of Qt Creator. Since then his changes made a strong impact to the C++ support. He worked on the Clang integration for Qt Creator, Clang itself, improved the static analyses, polished the Windows experience of the C++ support and integrated Clazy and Clang Tidy. These are his contributions: https://codereview.qt-project.org/#/q/owner:%22Ivan+Donchevskii%22,n,z -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolai.kosjar at qt.io Thu Nov 23 13:11:48 2017 From: nikolai.kosjar at qt.io (Nikolai Kosjar) Date: Thu, 23 Nov 2017 13:11:48 +0100 Subject: [Development] Nominating Ivan Donchevskii for approver In-Reply-To: References: Message-ID: On 11/23/2017 12:52 PM, Marco Bubke wrote: > I'd like to nominate Ivan Donchevskii for Approver. > > > He is working since spring at the C++ support of Qt Creator. Since then > > his changes made a strong impact to the C++ support. He worked on the Clang > > integration for Qt Creator, Clang itself, improved the static analyses, > polished > > the Windows experience of the C++ support and integrated Clazy and Clang > Tidy. > > > These are his contributions: > > https://codereview.qt-project.org/#/q/owner:%22Ivan+Donchevskii%22,n,z +1 Especially his contributions to clang itself improved Qt Creator on Windows greatly! Nikolai From Eike.Ziller at qt.io Thu Nov 23 14:17:08 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Thu, 23 Nov 2017 13:17:08 +0000 Subject: [Development] Nominating Ivan Donchevskii for approver In-Reply-To: References: Message-ID: > On 23. Nov 2017, at 13:11, Nikolai Kosjar wrote: > > On 11/23/2017 12:52 PM, Marco Bubke wrote: >> I'd like to nominate Ivan Donchevskii for Approver. >> He is working since spring at the C++ support of Qt Creator. Since then >> his changes made a strong impact to the C++ support. He worked on the Clang >> integration for Qt Creator, Clang itself, improved the static analyses, polished >> the Windows experience of the C++ support and integrated Clazy and Clang Tidy. >> These are his contributions: >> https://codereview.qt-project.org/#/q/owner:%22Ivan+Donchevskii%22,n,z > > +1 > > Especially his contributions to clang itself improved Qt Creator on Windows greatly! + 1 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From bogdan.vatra at kdab.com Thu Nov 23 16:07:49 2017 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Thu, 23 Nov 2017 17:07:49 +0200 Subject: [Development] Nominating Kevin Funk for Maintainer qtbase/Build Systems/CMake In-Reply-To: <20171013193059.GA2628@klara.mpi.htwm.de> References: <20171013193059.GA2628@klara.mpi.htwm.de> Message-ID: <2491799.obia9CTTje@zmeu> On vineri, 13 octombrie 2017 21:30:59 EET André Pönitz wrote: > Hi all. > > I would like to nominate Kevin Funk for Maintainer of the > Build Systems/CMake area. > > Kevin is effectively doing the job today. > +1 from me! Cheers, BogDan. From lars.knoll at qt.io Fri Nov 24 08:32:14 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 24 Nov 2017 07:32:14 +0000 Subject: [Development] Nominating Kevin Funk for Maintainer qtbase/Build Systems/CMake In-Reply-To: <2491799.obia9CTTje@zmeu> References: <20171013193059.GA2628@klara.mpi.htwm.de> <2491799.obia9CTTje@zmeu> Message-ID: <81DF5BA2-3BAF-4EA7-B9DD-C2758E597796@qt.io> Congratulation to Kevin, and thanks for stepping up! Cheers, Lars > On 23 Nov 2017, at 16:07, Bogdan Vatra wrote: > > On vineri, 13 octombrie 2017 21:30:59 EET André Pönitz wrote: >> Hi all. >> >> I would like to nominate Kevin Funk for Maintainer of the >> Build Systems/CMake area. >> >> Kevin is effectively doing the job today. >> > > +1 from me! > > Cheers, > BogDan. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kfunk at kde.org Fri Nov 24 13:11:55 2017 From: kfunk at kde.org (Kevin Funk) Date: Fri, 24 Nov 2017 13:11:55 +0100 Subject: [Development] Nominating Kevin Funk for Maintainer qtbase/Build Systems/CMake In-Reply-To: <81DF5BA2-3BAF-4EA7-B9DD-C2758E597796@qt.io> References: <20171013193059.GA2628@klara.mpi.htwm.de> <2491799.obia9CTTje@zmeu> <81DF5BA2-3BAF-4EA7-B9DD-C2758E597796@qt.io> Message-ID: <2332220.Y4mrk2ADQk@kerberos> On Friday, 24 November 2017 08:32:14 CET Lars Knoll wrote: > Congratulation to Kevin, and thanks for stepping up! Thanks for the trust, guys! Cheers, Kevin > Cheers, > Lars > > > > On 23 Nov 2017, at 16:07, Bogdan Vatra wrote: > > > > On vineri, 13 octombrie 2017 21:30:59 EET André Pönitz wrote: > > > >> Hi all. > >> > >> I would like to nominate Kevin Funk for Maintainer of the > >> Build Systems/CMake area. > >> > >> Kevin is effectively doing the job today. > >> > > > > > > +1 from me! > > > > Cheers, > > BogDan. > > > > _______________________________________________ > > 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 -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: This is a digitally signed message part. URL: From alexander.blasche at qt.io Mon Nov 27 07:41:08 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 27 Nov 2017 06:41:08 +0000 Subject: [Development] Nominating Lorenz Haas for approver In-Reply-To: References: Message-ID: Congratulations to Lorenz. Approver rights have been granted. -- Alex ________________________________________ From: Development on behalf of André Hartmann Sent: Sunday, 5 November 2017 6:00:40 PM To: qt-creator at qt-project.org; development at qt-project.org Cc: Lorenz Haas Subject: [Development] Nominating Lorenz Haas for approver Hello all, I'd like to nominate Lorenz Haas for approver status. Lorenz has been contributing to Qt and Qt Creator since spring 2013. He has provided some high quality patches to Creators C++ Editor and is the author of Creators Beautifier plugin. He is actively reviewing patches in these areas, and recently started contributing to and reviewing others patches for Qt OPC UA and MQTT also. These are his own contributions: https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z and these are his reviews: https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z Best regards, André _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Mon Nov 27 11:01:26 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 27 Nov 2017 10:01:26 +0000 Subject: [Development] CI problems Message-ID: Hi, The CI system is currently experiencing severe network TCP connectivity problems (and has been for a few days), resulting in many failing integrations. We are painfully aware of the issue and are looking into it. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Mon Nov 27 14:14:56 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 27 Nov 2017 13:14:56 +0000 Subject: [Development] Qt 5.10.0 RC out Message-ID: Hi all, Qt 5.10.0 RC is released today. Delta to Beta4 as an attachment. We are targeting to get final Qt 5.10.0 out 30.11.2017 as planned so please test the packages now & report me immediately if you find something which should really block the release. But remember: We won't block the release without really good reasons. Qt 5.10.1 will be released quite quickly so if we can live with issue as known issue in Qt 5.10.0 we will. So please add those issues directly in known issues page (https://wiki.qt.io/Qt_5.10.0_Known_Issues). Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. br, Jani -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.10-beta4-delta-rc-commits Type: application/octet-stream Size: 37017 bytes Desc: qt5.10-beta4-delta-rc-commits URL: From announce at qt-project.org Mon Nov 27 14:15:56 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Mon, 27 Nov 2017 13:15:56 +0000 Subject: [Development] [Announce] Qt 5.10.0 RC out In-Reply-To: References: Message-ID: Hi all, Qt 5.10.0 RC is released today. We are targeting to get final Qt 5.10.0 out 30.11.2017 as planned so please test the packages now & report me immediately if you find something which should really block the release. But remember: We won't block the release without really good reasons. Qt 5.10.1 will be released quite quickly so if we can live with issue as known issue in Qt 5.10.0 we will. So please add those issues directly in known issues page (https://wiki.qt.io/Qt_5.10.0_Known_Issues). Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. br, Jani _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From kevin.funk at kdab.com Tue Nov 28 07:13:27 2017 From: kevin.funk at kdab.com (Kevin Funk) Date: Tue, 28 Nov 2017 07:13:27 +0100 Subject: [Development] Getting defines from pkg-config for Qt modules In-Reply-To: <1509049519.2696.10.camel@member.fsf.org> References: <1509037789.29174.27.camel@member.fsf.org> <1587449.h1q4tn0fkS@tjmaciei-mobl1> <1509049519.2696.10.camel@member.fsf.org> Message-ID: <1549529.eiVoBxU8NQ@kerberos> On Thursday, 26 October 2017 22:25:19 CET Jeandet Alexis wrote: > Hello Thiago, > > Le jeudi 26 octobre 2017 à 13:14 -0700, Thiago Macieira a écrit : > > On Thursday, 26 October 2017 10:09:49 PDT Jeandet Alexis wrote: > > > Hello, > > > > > > I already asked this on IRC but I got no answer. > > > On Fedora and Ubuntu I can say that "pkg-config --cflags Qt5[any > > > module]" does only provides include flags and no defines such as > > > -DQT_CORE_LIB or -DQT_GUI_LIB. > > > > > > As an example "pkg-config --cflags panelw" gives "-D_GNU_SOURCE > > > -D_DEFAULT_SOURCE " > > > > panelw.pc is buggy > > In fact I took the first one returning defines :) > > > However, we should have -DQT_CORE_LIB in Qt5Core.pc. Please file an > > issue for > > us. > > > > > So my questions are: > > > 1) Is this normal/expected? > > > 2) Why not providing this flags? > > > 3) Does a patch to provides this flags would be accepted? > > > > Yes, a patch adding QT_${uppercaselib}_LIB to each .pc would be > > accepted. > > Awesome, thank you. For the record, this patch is at: https://codereview.qt-project.org/209717 Regards, Kevin -- Kevin Funk | kevin.funk at kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5322 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Nov 28 20:56:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 28 Nov 2017 11:56:21 -0800 Subject: [Development] CI problems In-Reply-To: References: Message-ID: <1701182.jn2UmojZR3@tjmaciei-mobl1> On Monday, 27 November 2017 02:01:26 PST Simon Hausmann wrote: > Hi, > > > The CI system is currently experiencing severe network TCP connectivity > problems (and has been for a few days), resulting in many failing > integrations. We are painfully aware of the issue and are looking into it. Has this been solved? I see 5.9 and 5.10.0 integrations, but dev is still blocked. The DNS issue has been resolved. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Nov 29 08:17:31 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 29 Nov 2017 07:17:31 +0000 Subject: [Development] Qt 5.11 initial schedule In-Reply-To: References: Message-ID: Hi all, Now when Qt 5.10.0 is in its final steps it is time to start scheduling Qt 5.11. As usual we need to get it out before summer holiday period so let's target to get it out at the end of May as usual. Below is my proposal for Qt 5.11 initial schedule (based on realized schedules with Qt 5.9 and Qt 5.10): Soft Branching starts 24th January 2018 Feature Freeze & Finalize branching 31st January 2018 Alpha Release 21st February 2018 First Beta Release 21st March 2018 Release Candidate 17th May 2018 Final Release 31st May 2018 And note: This is just an initial schedule based on earlier experience & we will try to get release(s) out as soon as possible after feature freeze. br, Jani Heikkinen Release Manager From jc.fernandez.navarro.lists at gmail.com Wed Nov 29 17:02:30 2017 From: jc.fernandez.navarro.lists at gmail.com (Jose Fernandez Navarro) Date: Wed, 29 Nov 2017 17:02:30 +0100 Subject: [Development] [Bug] QOpenGLWidget::grab() not behaving properly Message-ID: <4A4A6834-9E03-497E-9847-CE1417837BBB@gmail.com> Hello, I have a QOpenGLWidget object where I draw using both OpenGL and QPainter. When I called grab() on the object prior 5.9.2 I would get a seg. fault. Now (5.9.2) I can grab the widget's image but the QPainter stuff is missing and actually it dissappears from the widget until I refresh it again by panning or zooming on it. This is how I do the grabbing: const QPixmap res = grab(QRect(0,0,width(),height())); return res.toImage(); Is this a known bug? or is it actually a bug? I believe it should be possible to grab the image from the widget even if I draw on it with both OpenGL and QPainter. I figured I would post it here before creating an issue. ps: I am using OSX (latest version, Sierra). Thanks in advance. Best, Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Wed Nov 29 17:03:09 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 29 Nov 2017 16:03:09 +0000 Subject: [Development] CI problems In-Reply-To: <1701182.jn2UmojZR3@tjmaciei-mobl1> References: , <1701182.jn2UmojZR3@tjmaciei-mobl1> Message-ID: Thanks for fixing the DNS issue. I don't know about the dev blocking in Gerrit. We were able to address the underlying infrastructure issue for a while, but the symptoms are back now :( Simon ________________________________ From: Thiago Macieira Sent: Tuesday, November 28, 2017 8:56:21 PM To: development at qt-project.org Cc: Simon Hausmann Subject: Re: [Development] CI problems On Monday, 27 November 2017 02:01:26 PST Simon Hausmann wrote: > Hi, > > > The CI system is currently experiencing severe network TCP connectivity > problems (and has been for a few days), resulting in many failing > integrations. We are painfully aware of the issue and are looking into it. Has this been solved? I see 5.9 and 5.10.0 integrations, but dev is still blocked. The DNS issue has been resolved. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Wed Nov 29 17:16:32 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Wed, 29 Nov 2017 16:16:32 +0000 Subject: [Development] [Bug] QOpenGLWidget::grab() not behaving properly In-Reply-To: <4A4A6834-9E03-497E-9847-CE1417837BBB@gmail.com> References: <4A4A6834-9E03-497E-9847-CE1417837BBB@gmail.com> Message-ID: On 2017-11-29 16:02, Jose Fernandez Navarro wrote: > Hello, > > I have a QOpenGLWidget object where I draw > using both OpenGL and QPainter. When I called > grab() on the object prior 5.9.2 I would get a seg. fault. > Now (5.9.2) I can grab the widget's image but > the QPainter stuff is missing and actually it dissappears > from the widget until I refresh it again by panning or zooming on it. Hi, Can you see if https://codereview.qt-project.org/#/c/197930/ helps ? 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 marc.mutz at kdab.com Thu Nov 30 15:02:19 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Nov 2017 15:02:19 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2662207.B6jXvkEcQG@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> Message-ID: <54ec2cfee28311c3aff2d05403175b6f@kdab.com> On 2017-10-10 14:49, Thiago Macieira wrote: [...] > * We think members are cleaner and we don't want to add these You have members where members are possible. But you can't add members to char16_t[]! > * However, we already have some of those! qStartsWith > ** Global namespace *and* documented > ** foo.startsWith(bar) vs qStartsWith(foo, bar) > ** Same conclusion, probably mark \internal, namespace them > *** But review the changes to see what our arguments were on making > them > public I have seen that you used my recent absence to sneak in a change to put these functions into the QtPrivate namespace - in a public header! It's good that you agree that there should be free functions for them, it's a pity that you think you need to hide them. No-one forces anyone to use them, but they are there for when you need them: for use in generic code, to have one syntax that works for every pair of arguments[1]. People are still free to use vec.begin(), and personally, I'll choose that every time over std::begin(vec), but std::begin() needs to be there, too. Same thing for qCompareStrings(). I will not restart work on QStringView before these are put back. So, please, restore them to the state they had[2], then I'll get approval for finishing the work on QStringView. If it's too late for 5.10, add them back as inline functions, calling the useless QtPrivate ones, please. Thanks, Marc [1] e.g., at some point, we should make operator==(string-like, string-like) templated and just call qCompareStrings. There's no reason to hold this API from the user. [2] incl., btw, the constexpr on QStringView(Char*), which is required for std::string_view compat: http://en.cppreference.com/w/cpp/string/basic_string_view/basic_string_view From annulen at yandex.ru Thu Nov 30 15:56:54 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 30 Nov 2017 17:56:54 +0300 Subject: [Development] [Offtopic] QtCS 2017 QtCore sessions In-Reply-To: <54ec2cfee28311c3aff2d05403175b6f@kdab.com> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <54ec2cfee28311c3aff2d05403175b6f@kdab.com> Message-ID: <330201512053814@web38g.yandex.ru> 30.11.2017, 17:05, "Marc Mutz" : > On 2017-10-10 14:49, Thiago Macieira wrote: > [...] >>  * We think members are cleaner and we don't want to add these > > You have members where members are possible. > But you can't add members to char16_t[]! Just in case somebody didn't see it yet, here is a funny writing describing Java as a kingdom on nouns http://steve-yegge.blogspot.ru/2006/03/execution-in-kingdom-of-nouns.html Fortunately C++ is not so restricted -- Regards, Konstantin From thiago.macieira at intel.com Thu Nov 30 17:13:22 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Nov 2017 08:13:22 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <54ec2cfee28311c3aff2d05403175b6f@kdab.com> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <54ec2cfee28311c3aff2d05403175b6f@kdab.com> Message-ID: <2372460.foxsk40T4i@tjmaciei-mobl1> On quinta-feira, 30 de novembro de 2017 06:02:19 PST Marc Mutz wrote: > On 2017-10-10 14:49, Thiago Macieira wrote: > [...] > > > * We think members are cleaner and we don't want to add these > > You have members where members are possible. > But you can't add members to char16_t[]! Why would we need to? > > * However, we already have some of those! qStartsWith > > ** Global namespace *and* documented > > ** foo.startsWith(bar) vs qStartsWith(foo, bar) > > ** Same conclusion, probably mark \internal, namespace them > > *** But review the changes to see what our arguments were on making > > them > > public > > I have seen that you used my recent absence to sneak in a change to put > these functions into the QtPrivate namespace - in a public header! It's > good that you agree that there should be free functions for them, it's a > pity that you think you need to hide them. I did not know you were absent when this was posted. Sorry, we cannot be held to blame for your employer deciding to suspend participation for a while. Qt development did not stop. You'll note I had agreed with you when those functions came in. It was during the QtCore session at QtCS that when I brought them up, people cringed and asked whether it was the Qt-way. The conclusion was it wasn't, so I posted here *and* in the API review that we were going to change. > No-one forces anyone to use them, but they are there for when you need > them: for use in generic code, to have one syntax that works for every > pair of arguments[1]. People are still free to use vec.begin(), and > personally, I'll choose that every time over std::begin(vec), but > std::begin() needs to be there, too. Same thing for qCompareStrings(). We just didn't want to make them officially part of the API. > I will not restart work on QStringView before these are put back. So, > please, restore them to the state they had[2], then I'll get approval > for finishing the work on QStringView. If it's too late for 5.10, add > them back as inline functions, calling the useless QtPrivate ones, > please. It's too late for 5.10, but we can add them as inline functions for 5.11, if there's strong reason. I don't believe there is. The reason is still the same: we don't want them in the API. > [1] e.g., at some point, we should make operator==(string-like, > string-like) templated and just call qCompareStrings. There's no reason > to hold this API from the user. What's wrong with str.compare()? > [2] incl., btw, the constexpr on QStringView(Char*), which is required > for std::string_view compat: > http://en.cppreference.com/w/cpp/string/basic_string_view/basic_string_view Pity. Performance is more important than constexpr. This stays until C++ allows us to overload constexpr and non-constexpr. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 30 18:47:13 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Nov 2017 09:47:13 -0800 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution Message-ID: <3717608.CIl6TGCH48@tjmaciei-mobl1> See https://bugreports.qt.io/browse/QTBUG-64820 and http://lists.qt-project.org/pipermail/interest/2017-November/028766.html The Qt 5.9.3 binaries were compiled by GCC 6, which is too new for the latest Ubuntu LTS (16.04). I urgently recommend: 1) find some older distro (possibly Ubuntu 16.04 LTS) to compile the 5.10 and further 5.9 binaries with. 2) recompile the 5.9.3 binaries and post them. No changes to the source code, just rebuild. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Thu Nov 30 19:29:40 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 30 Nov 2017 20:29:40 +0200 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: <3717608.CIl6TGCH48@tjmaciei-mobl1> References: <3717608.CIl6TGCH48@tjmaciei-mobl1> Message-ID: On 30 November 2017 at 19:47, Thiago Macieira wrote: > See https://bugreports.qt.io/browse/QTBUG-64820 and > http://lists.qt-project.org/pipermail/interest/2017-November/028766.html > > The Qt 5.9.3 binaries were compiled by GCC 6, which is too new for the latest > Ubuntu LTS (16.04). I urgently recommend: > > 1) find some older distro (possibly Ubuntu 16.04 LTS) to compile the 5.10 and > further 5.9 binaries with. > > 2) recompile the 5.9.3 binaries and post them. No changes to the source code, > just rebuild. +1, that seems like a reasonable suggestion to me. From probono at puredarwin.org Thu Nov 30 19:48:08 2017 From: probono at puredarwin.org (probono) Date: Thu, 30 Nov 2017 19:48:08 +0100 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> Message-ID: On Thu, Nov 30, 2017 at 7:29 PM, Ville Voutilainen wrote: > On 30 November 2017 at 19:47, Thiago Macieira wrote: >> See https://bugreports.qt.io/browse/QTBUG-64820 and >> http://lists.qt-project.org/pipermail/interest/2017-November/028766.html >> >> The Qt 5.9.3 binaries were compiled by GCC 6, which is too new for the latest >> Ubuntu LTS (16.04). Yes. Please _at least_ support the oldest still-supported LTS version, which is 14.04 at this time. CentOS 6 users might also still exist. Thanks! From annulen at yandex.ru Thu Nov 30 19:48:49 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 30 Nov 2017 21:48:49 +0300 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: <3717608.CIl6TGCH48@tjmaciei-mobl1> References: <3717608.CIl6TGCH48@tjmaciei-mobl1> Message-ID: <15831512067729@web14o.yandex.ru> 30.11.2017, 20:47, "Thiago Macieira" : > See https://bugreports.qt.io/browse/QTBUG-64820 and > http://lists.qt-project.org/pipermail/interest/2017-November/028766.html > > The Qt 5.9.3 binaries were compiled by GCC 6, which is too new for the latest > Ubuntu LTS (16.04). I urgently recommend: > >  1) find some older distro (possibly Ubuntu 16.04 LTS) to compile the 5.10 and > further 5.9 binaries with. > >  2) recompile the 5.9.3 binaries and post them. No changes to the source code, > just rebuild. It seems that when RHEL was updated from 7.2 to 7.4 [1], devtoolset-6 was installed instead of devtoolset-4 [2]. As we use artifacts from RHEL7 configuration as official binaries, they started to require GCC 6 [1] https://codereview.qt-project.org/#/c/204675/38 [2] One of patches integrated before that provisioning change: https://testresults.qt.io/coin/api/results/qt/qtbase/1e813c55a1e3d07549cfe2dd6fe3a927c3677c19/LinuxRHEL_7_2x86_64LinuxRHEL_7_2x86_64GCCqtci-linux-RHEL-7.2-x86_64-e1aea8Release_NoUseGoldLinker/2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/build_1508179165/log.txt.gz > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From marc.mutz at kdab.com Thu Nov 30 19:53:33 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Nov 2017 19:53:33 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2372460.foxsk40T4i@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <54ec2cfee28311c3aff2d05403175b6f@kdab.com> <2372460.foxsk40T4i@tjmaciei-mobl1> Message-ID: <227a5a46ea19565e272e83fd37a6e02e@kdab.com> On 2017-11-30 17:13, Thiago Macieira wrote: > On quinta-feira, 30 de novembro de 2017 06:02:19 PST Marc Mutz wrote: >> On 2017-10-10 14:49, Thiago Macieira wrote: >> [...] >> >> > * We think members are cleaner and we don't want to add these >> >> You have members where members are possible. >> But you can't add members to char16_t[]! > > Why would we need to? [...] >> [1] e.g., at some point, we should make operator==(string-like, >> string-like) templated and just call qCompareStrings. There's no >> reason >> to hold this API from the user. > > What's wrong with str.compare()? Do these two quotes somehow fit together? template bool operator==(const LHS &lhs, const RHS &rhs) { return qCompareStrings(lhs, rhs) == 0; } template bool operator==(const LHS &lhs, const RHS &rhs) { return lhs.compare(rhs) == 0; } if (u"Hello" == string) ~~~ > >> [2] incl., btw, the constexpr on QStringView(Char*), which is required >> for std::string_view compat: >> http://en.cppreference.com/w/cpp/string/basic_string_view/basic_string_view > > Pity. Performance is more important than constexpr. 1. There are so many more performance problems in Qt than this that it's almost funny :) 2. So ok, performance matters. But a flexible interface matters too. You might not use compile-time string manipulation, but people do. They write compile-time JSON parsers. Anyway, assuming you are right (and I don't think you are, here), where are your numbers that show that the frequency of calls to the QStringView(Char*) ctor multiplied with the performance increase of out-of-line SIMD code multiplied by the average length of strings is so large as to warrant dropping support for compile-time string manipulations and std compatibility? Show them, and then we'll discuss it again. IMNSHO, absent proof to the contrary, you are optimizing an edge case here, an edge case that people can easily fix by using auto s = QStringView{s, qustrlen(s)}; manually when they expect large strings. The missing constexpr is not so easily obtained than the SIMD length calculation. From thiago.macieira at intel.com Thu Nov 30 20:09:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Nov 2017 11:09:01 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <227a5a46ea19565e272e83fd37a6e02e@kdab.com> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2372460.foxsk40T4i@tjmaciei-mobl1> <227a5a46ea19565e272e83fd37a6e02e@kdab.com> Message-ID: <8356435.nI9tCjiaGg@tjmaciei-mobl1> On quinta-feira, 30 de novembro de 2017 10:53:33 PST Marc Mutz wrote: > What's wrong with str.compare()? > > Do these two quotes somehow fit together? > > template > bool operator==(const LHS &lhs, const RHS &rhs) > { return qCompareStrings(lhs, rhs) == 0; } > > template > bool operator==(const LHS &lhs, const RHS &rhs) > { return lhs.compare(rhs) == 0; } > > if (u"Hello" == string) ~~~ I don't see how this problem can't be solved. We don't need templates with StringLike concepts. Not to mention we can't really rely on them in Qt for the next 10 years, so if you want to write that last line of code, we'll need a solution without concepts. > 2. So ok, performance matters. But a flexible interface matters too. You > might not use compile-time string manipulation, but people do. They > write compile-time JSON parsers. Anyway, assuming you are right (and I > don't think you are, here), where are your numbers that show that the > frequency of calls to the QStringView(Char*) ctor multiplied with the > performance increase of out-of-line SIMD code multiplied by the average > length of strings is so large as to warrant dropping support for > compile-time string manipulations and std compatibility? Show them, and > then we'll discuss it again. > > IMNSHO, absent proof to the contrary, you are optimizing an edge case > here, an edge case that people can easily fix by using > > auto s = QStringView{s, qustrlen(s)}; > > manually when they expect large strings. The missing constexpr is not so > easily obtained than the SIMD length calculation. This was a judgement call. The C++ standard needs to be fixed, so I am doing what I think is the correct direction: performance first. API parallelism with the Standard Library is not required where the standard library makes mistakes. Requiring constexpr for calculating string lengths is one where I think it made a mistake. Therefore, I will not accept that as an argument. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 30 20:11:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Nov 2017 11:11:58 -0800 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> Message-ID: <1709159.xiL18mtMcK@tjmaciei-mobl1> On Thursday, 30 November 2017 10:48:08 PST probono wrote: > Yes. Please _at least_ support the oldest still-supported LTS version, > which is 14.04 at this time. CentOS 6 users might also still exist. > Thanks! Not necessarily. We need to support the latest LTS, at the very least. Support for oldest LTS is not a requirement if that comes with too old software. In this case, it's got GCC 4.8.2, so it's still acceptable. There's other software that needs to be evaluated for compatibility, especially those that have changed sonames recently, like the MySQL client library and some udev libs. [ICU is hopeless, so it doesn't count] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 30 20:23:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Nov 2017 11:23:47 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <8356435.nI9tCjiaGg@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <227a5a46ea19565e272e83fd37a6e02e@kdab.com> <8356435.nI9tCjiaGg@tjmaciei-mobl1> Message-ID: <9252745.oZKNKI4o4D@tjmaciei-mobl1> On Thursday, 30 November 2017 11:09:01 PST Thiago Macieira wrote: > API parallelism with the Standard Library is not required where the standard > library makes mistakes. Requiring constexpr for calculating string lengths > is one where I think it made a mistake. Therefore, I will not accept that > as an argument. >From libstdc++ std::char_traits static _GLIBCXX17_CONSTEXPR size_t length(const char_type* __s) { #if __cplusplus > 201402 if (__constant_string_p(__s)) return __gnu_cxx::char_traits::length(__s); else #endif return wcslen(__s); } They were added in revision 249137 by Pedro Alves. The fact that they needed to add that __constant_string_p hack indicates there's a design flaw. I'm not saying the change author agrees there's a defect, I'm saying change points to a design flaw. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Nov 30 21:08:45 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Nov 2017 21:08:45 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <8356435.nI9tCjiaGg@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2372460.foxsk40T4i@tjmaciei-mobl1> <227a5a46ea19565e272e83fd37a6e02e@kdab.com> <8356435.nI9tCjiaGg@tjmaciei-mobl1> Message-ID: On 2017-11-30 20:09, Thiago Macieira wrote: > On quinta-feira, 30 de novembro de 2017 10:53:33 PST Marc Mutz wrote: >> What's wrong with str.compare()? >> >> Do these two quotes somehow fit together? >> >> template >> bool operator==(const LHS &lhs, const RHS &rhs) >> { return qCompareStrings(lhs, rhs) == 0; } >> >> template >> bool operator==(const LHS &lhs, const RHS &rhs) >> { return lhs.compare(rhs) == 0; } >> >> if (u"Hello" == string) ~~~ > > I don't see how this problem can't be solved. We don't need templates > with > StringLike concepts. Not to mention we can't really rely on them in Qt > for the > next 10 years, so if you want to write that last line of code, we'll > need a > solution without concepts. Don't go off on a tangent here. I used concepts syntax to keep the example simple. I can post with std::enable_if, if you prefer :) Anyway, the point is the asymmetry of member functions. u"Hello".compare(string) does not compile in C++ (it does in Java), so everyone that wants to write a template like the op== above will have to re-invent qCompareStrings(). The Qt API rules stipulate that the common use case should be made simple (we do, we have member functions whereever we can add them), but make the rest possible. And that's where qCompareStrings() come in. It makes the remaining 5% (random number) possible. >> 2. So ok, performance matters. But a flexible interface matters too. >> You >> might not use compile-time string manipulation, but people do. They >> write compile-time JSON parsers. Anyway, assuming you are right (and I >> don't think you are, here), where are your numbers that show that the >> frequency of calls to the QStringView(Char*) ctor multiplied with the >> performance increase of out-of-line SIMD code multiplied by the >> average >> length of strings is so large as to warrant dropping support for >> compile-time string manipulations and std compatibility? Show them, >> and >> then we'll discuss it again. >> >> IMNSHO, absent proof to the contrary, you are optimizing an edge case >> here, an edge case that people can easily fix by using >> >> auto s = QStringView{s, qustrlen(s)}; >> >> manually when they expect large strings. The missing constexpr is not >> so >> easily obtained than the SIMD length calculation. > > This was a judgement call. The C++ standard needs to be fixed, so I am > doing > what I think is the correct direction: performance first. And I would interpret the Qt API design rules differently: like qCompareStrings(), constexpr QSV ctors enable the remaining 5% of use-cases. If the standard equivalent wasn't constexpr all-over, one could maintain that what people don't know they will not miss. But std::string_view _is_ all-constexpr, and therefore (some) people will miss it. That leaves the question whether long raw strings passed to QSV(Char*) without also passing the length are the common use-case or whether the common use-case is that the user doesn't care. And I think that it's the latter, because off the top of my head, I can think of no situation where I actually would need the length calculation in QSV's ctor. The situation is a bit different in std::string_view where this ctor also receives all C string literals. We have a separate ctor for that in QSV, so we don't depend so existentially on the (Char*) ctor to be constexpr, but we also don't have a performance problem, since the frequency of calls to that ctor is very, very low. And there's the work-around to enable the 10% (random number) of users that see a performance problem with that ctor to call qustrlen() manually. We should empower, not infantilise, the user. > API parallelism with the Standard Library is not required where the > standard > library makes mistakes. Requiring constexpr for calculating string > lengths is > one where I think it made a mistake. Therefore, I will not accept that > as an > argument. We all think we're smarter than the committee, yes. Maybe we are, but swarm intelligence suggests otherwise. Thanks, Marc From thiago.macieira at intel.com Thu Nov 30 22:13:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Nov 2017 13:13:38 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <8356435.nI9tCjiaGg@tjmaciei-mobl1> Message-ID: <2205331.XELMSDqlt1@tjmaciei-mobl1> On Thursday, 30 November 2017 12:08:45 PST Marc Mutz wrote: > Don't go off on a tangent here. I used concepts syntax to keep the > example simple. I can post with std::enable_if, if you prefer :) Fair enough, I had not considered that. > Anyway, the point is the asymmetry of member functions. > u"Hello".compare(string) does not compile in C++ (it does in Java), so > everyone that wants to write a template like the op== above will have to > re-invent qCompareStrings(). The Qt API rules stipulate that the common > use case should be made simple (we do, we have member functions > whereever we can add them), but make the rest possible. And that's where > qCompareStrings() come in. It makes the remaining 5% (random number) > possible. Why does anyone besides us need to write the op== like above? We have access to QtPrivate::qCompareStrings, so we can write the comparisons to our string objects. Once those operator<=> are there, what benefit is there in having the API public and documented? > >> IMNSHO, absent proof to the contrary, you are optimizing an edge case > >> here, an edge case that people can easily fix by using > >> > >> auto s = QStringView{s, qustrlen(s)}; > >> > >> manually when they expect large strings. The missing constexpr is not > >> so > >> easily obtained than the SIMD length calculation. > > > > This was a judgement call. The C++ standard needs to be fixed, so I am > > doing > > what I think is the correct direction: performance first. > > And I would interpret the Qt API design rules differently: like > qCompareStrings(), constexpr QSV ctors enable the remaining 5% of > use-cases. If the standard equivalent wasn't constexpr all-over, one > could maintain that what people don't know they will not miss. But > std::string_view _is_ all-constexpr, and therefore (some) people will > miss it. Again, flaw in the standard. I do not feel we need to agree with the standard when it's flawed. I'll happily add constexprness back when I'm allowed to have my cake and eat it too. > That leaves the question whether long raw strings passed to > QSV(Char*) without also passing the length are the common use-case or > whether the common use-case is that the user doesn't care. And I think > that it's the latter, because off the top of my head, I can think of no > situation where I actually would need the length calculation in QSV's > ctor. The situation is a bit different in std::string_view where this > ctor also receives all C string literals. We have a separate ctor for > that in QSV, so we don't depend so existentially on the (Char*) ctor to > be constexpr, but we also don't have a performance problem, since the > frequency of calls to that ctor is very, very low. And there's the > work-around to enable the 10% (random number) of users that see a > performance problem with that ctor to call qustrlen() manually. I'd say that calling qustrlen manually is even more surprising and no one would think of doing that. Not even after finding that there's a bit of performance they could gain. Everyone just expects the constructor to calculate the length by itself. > > API parallelism with the Standard Library is not required where the > > standard > > library makes mistakes. Requiring constexpr for calculating string > > lengths is > > one where I think it made a mistake. Therefore, I will not accept that > > as an > > argument. > > We all think we're smarter than the committee, yes. Maybe we are, but > swarm intelligence suggests otherwise. To be clear: there's nothing wrong with adding constexpr where we can. Constexpr string literals make a lot of sense. The flaw is in doing that in detriment to performance at runtime. EVERY SINGLE strlen function is SIMD-optimised, sometimes even multiple versions. There's even a dedicated instruction added to SSE4.2 to do that, plus the original 8086 way (rep scasb) which was slow for a long time and now is fast again. I don't have the benchmarks to prove it, but my gut feeling is that the SIMD code becomes worth it very quickly (despite the call overhead), sometime between 8 and 16 characters in the string. https://godbolt.org/g/gBMykD -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center